git problems

[Peter Jeremy]

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);
	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).

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080604/90fd7db5/attachment.pgp