-----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-----
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
