git problems

[Chuck Robey]

-----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
> <ports>/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-----