Date: Wed, 04 Jun 2008 11:26:02 -0400 From: Chuck Robey <chuckr@telenix.org> To: Eygene Ryabinkin <rea-fbsd@codelabs.ru> Cc: FreeBSD-Hackers <freebsd-hackers@freebsd.org> Subject: Re: git problems Message-ID: <4846B40A.4010309@telenix.org> In-Reply-To: <L4F%2B2AmHcL4Uix8Rch4QiSpqQwc@RzJPyOBFuChtvuf1tf1krA3%2BwkI> References: <4845AC84.6040407@telenix.org> <TbQi51CAu4j4cFDkKULTI53ON0k@8ZdGo3QYE5K669Y/W2Z6ZKf2XtY> <4846A77B.9060603@telenix.org> <L4F%2B2AmHcL4Uix8Rch4QiSpqQwc@RzJPyOBFuChtvuf1tf1krA3%2BwkI>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4846B40A.4010309>