* Peter Jeremy <[EMAIL PROTECTED]> wrote: > On 2008-Jun-04 11:26:02 -0400, Chuck Robey <[EMAIL PROTECTED]> wrote: > >#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 > > __cxa_finalise() is part of the atexit() processing - the source comments > imply it handles shared object destructors. > > >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. > > There's no fork involved. It's just shorthand for: > return_code = run_command(p, argc, argv); > exit(return_code); > By the time exit() is invoked, run_command() has completed. > > > Second, the second argument to handle_internal_command seems to > >have been a argv=0xffffffff, which is very obviously a bad string > >pointer > > Note that argv in main is also corrupt. I suspect gdb is confused by > the level of optimisation being done by gcc. > > In a later posting, you indicate that there's a double-free bug. > Possibly unlock_pack() is being registered as a destructor (or > similar) _and_ is being explicitly called. Without studying the > code, the solution is probably to either skip the explicit cleanup > (leaving just the destructor processing) and/or flag freed data (ie > NULL pointers after freeing them).
I just solved this on my systems by removing the call to free(). I know, it's awful, but it was good enough for me to live with on short term. -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://80386.nl/
pgpMvsLv69Vm5.pgp
Description: PGP signature
