From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 15:35:31 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C1891065674 for ; Wed, 4 Jun 2008 15:35:31 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 010C78FC13 for ; Wed, 4 Jun 2008 15:35:30 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 19416 invoked from network); 4 Jun 2008 15:35:30 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 Jun 2008 15:35:29 -0000 Message-ID: <4846B40A.4010309@telenix.org> Date: Wed, 04 Jun 2008 11:26:02 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Eygene Ryabinkin References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> In-Reply-To: X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: FreeBSD-Hackers Subject: Re: git problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 15:35:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, > > Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote: >>> Any possibility of using ElectricFence (devel/ElectricFence) >>> for chasing memory-related troubles? >> Now that I have gdb working with me again, I am checking the git-fetch image to >> see where it got lost. If I must bring a tool such as ElectricFence I, I guess >> I must, just I'm a bit irritated that the git build has one of those make >> "improvements" (NOT) that instead of telling you the buid line, just gives you >> "CC sourcename.c" which for anyone who knows code is just irritating, not any >> sort of help at all. > > No problems, just issue 'make V=1' instead of just 'make' in the > /devel/git -- it will give you all flags and will eliminate > the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized > binary with debug symbols that can be directly traced by gdb with > all symbols and right (unoptimized, as in the sources) code paths. > > For the ElectricFence -- it dumps core just after startup, I don't > know why. So it is not very much usable now, at least for me. > > Thank you. I think I have it narrowed down to either a problemm in process creation (I don't believe this one) or, more likely, a problem in managing the crt0 stuff in managing a process's startup bars. Take a look below and tell me if you agree. Here's the stack dump: #0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7 #1 0x28437067 in free () from /lib/libc.so.7 #2 0x080d5dd4 in transport_unlock_pack (transport=0x284c1c98) at transport.c:811 #3 0x08066467 in unlock_pack () at builtin-fetch.c:56 #4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 #5 0x2843b1aa in exit () from /lib/libc.so.7 #6 0x0804b0e3 in handle_internal_command (argc=2, argv=0xffffffff) at git.c:379 #7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12 ) at git.c:414 and here's the lines from git.c, the loop where handle_internal_command gets called: /* Turn "git cmd --help" into "git help cmd" */ 370 if (argc > 1 && !strcmp(argv[1], "--help")) { 371 argv[1] = argv[0]; 372 argv[0] = cmd = "help"; 373 } 374 375 for (i = 0; i < ARRAY_SIZE(commands); i++) { 376 struct cmd_struct *p = commands+i; 377 if (strcmp(p->cmd, cmd)) 378 continue; 379 exit(run_command(p, argc, argv)); 380 } First I want to comment on that weird line 379, because while it might work, it sure seems to me to be a very strange and wasteful way to do a fork. I bet that's some sort of portability hack. Second, the second argument to handle_internal_command seems to have been a argv=0xffffffff, which is very obviously a bad string pointer Looking at the top stack frame (main), that frame and the next are deeply involved in inspecting argv 0 thru 2, and since it's full of garbage, that's what breaks things. That's NOT malloc, that seems to be either a problem in process creation or (I think more likely) a problem in the creation of a process's environment, the crt0 stuff. I'm getting out of my depth, here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRrQKz62J6PPcoOkRAnwFAJ9XXb0cy/Rowt+X2uLx1uaYWJdHdACglAe6 dThwRYHJ9f95Qyua/syFsV4= =yFZR -----END PGP SIGNATURE-----