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
next prev parent 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).