git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Bill Yoder <byoder@cs.utexas.edu>
Cc: git@vger.kernel.org, Wolfgang Denk <wd@denx.de>
Subject: Re: 1.3.2 git-clone segfaults
Date: Wed, 17 May 2006 19:52:00 -0400	[thread overview]
Message-ID: <1147909920.32050.29.camel@dv> (raw)
In-Reply-To: <1147894165.16654.10.camel@dv>

On Wed, 2006-05-17 at 15:29 -0400, Pavel Roskin wrote:
> On Wed, 2006-05-17 at 13:32 -0500, Bill Yoder wrote:
> > /usr/local/downloads/git-1.3.2/git-clone: line 323: 25972  
> > Segmentation fault      git-http-fetch -v -a -w "$tname" "$name" "$1/"
> 
> I've seen git-http-fetch segfaults many times when cloning qgit, but
> it's hard to reproduce on demand.
> 
> I think you should compile git without optimizations and allow coredumps
> (ulimit -c  unlimited), then load git-http-fetch in gdb with the core
> (gdb --core=core git-http-fetch) and run bt to see the backtrace.

Also comment out both "trap" invocations in git-clone, or the coredump
will be deleted.

That's what I've got on Fedora Core 5 x86_64 with glibc and curl debug
info installed:

#0  __strncasecmp (s1=Variable "s1" is not available.
) at strncase.c:68
68        while ((result = TOLOWER (*p1) - TOLOWER (*p2++)) == 0)
(gdb) where
#0  __strncasecmp (s1=Variable "s1" is not available.
) at strncase.c:68
#1  0x00000031f3e26c09 in curl_strnequal (first=Variable "first" is not available.
) at strequal.c:60
#2  0x00000031f3e0f43a in checkheaders (data=Variable "data" is not available.
) at http.c:119
#3  0x00000031f3e10cf9 in Curl_http (conn=0x1c421c0, done=Variable "done" is not available.
) at http.c:1580
#4  0x00000031f3e1a858 in Curl_do (connp=0x83af88, done=0x7fff29c97ebb "\001\001")
    at url.c:3841
#5  0x00000031f3e28f22 in curl_multi_perform (multi_handle=0x53b590, 
    running_handles=0x7fff29c97ef8) at multi.c:526
#6  0x00000000004040c0 in step_active_slots () at http.c:376
#7  0x000000000040412c in run_active_slot (slot=0x546690) at http.c:400
#8  0x0000000000403e44 in http_cleanup () at http.c:275
#9  0x00000000004077d7 in main (argc=7, argv=0x7fff29c98258) at http-fetch.c:1274
(gdb) p p1
$1 = (const unsigned char *) 0x0
(gdb) p p2
$2 = (const unsigned char *) 0x31f3e2e817 "User-Agent:"
(gdb)

Looks like a curl bug to me.  curl 7.15.1, glibc 2.4, git master branch.

-- 
Regards,
Pavel Roskin

  reply	other threads:[~2006-05-17 23:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-17 18:32 1.3.2 git-clone segfaults Bill Yoder
2006-05-17 18:41 ` Fernando J. Pereda
2006-05-17 18:46 ` Junio C Hamano
2006-05-17 19:27   ` Bill Yoder
2006-05-17 19:29 ` Pavel Roskin
2006-05-17 23:52   ` Pavel Roskin [this message]
2006-05-18  0:54     ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1147909920.32050.29.camel@dv \
    --to=proski@gnu.org \
    --cc=byoder@cs.utexas.edu \
    --cc=git@vger.kernel.org \
    --cc=wd@denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).