ed at 80386.nl
Wed Jun 4 19:54:09 UTC 2008
* Peter Jeremy <peterjeremy at optushome.com.au> wrote:
> On 2008-Jun-04 11:26:02 -0400, Chuck Robey <chuckr at telenix.org> 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);
> 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
> 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 <ed at 80386.nl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080604/3f1ecb71/attachment.pgp
More information about the freebsd-hackers