Re: [test failure] Re: t4114 binary file becomes symlink

[Jeff King <peff@peff.net>]

On Sat, Jul 18, 2009 at 04:16:58PM +0200, Nicolas Sebrecht wrote:

> It fails on:
>   - next
>   - v1.6.3
>   - b67b9612e1a90ae093445abeaeff930e9f4cf936
>   - (other I don't remember, but does it really matter?)

Hmm. So it is clearly reproducible on your system, but not on mine. I
wonder what the difference could be.

Are you compiling with any special options? I usually compile with just
"-g -Wall -Werror", but I also tried with "-O2" and couldn't reproduce.
Maybe compiler version? I'm using gcc 4.3.3.

> ==10807== Invalid read of size 1
> ==10807==    at 0x4C22349: strlen (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==10807==    by 0x5616ED6: vfprintf (in /lib64/libc-2.8.so)
> ==10807==    by 0x563C159: vsnprintf (in /lib64/libc-2.8.so)
> ==10807==    by 0x495E90: git_vsnprintf (snprintf.c:38)
> ==10807==    by 0x48917B: strbuf_addf (strbuf.c:203)
> ==10807==    by 0x412AA0: cmd_checkout (builtin-checkout.c:364)
> ==10807==    by 0x404222: handle_internal_command (git.c:243)
> ==10807==    by 0x404466: main (git.c:483)
> ==10807==  Address 0x1 is not stack'd, malloc'd or (recently) free'd

Looking at that strbuf_addf call, we presumably have a bogus pointer
either in old->name or new->name. Which is odd, since reading the code,
both get memset() to zero, and then assigned from something which should
be sane.

At this point, I would try either running it under gdb or putting in
some debugging printfs into update_refs_for_switch to try to isolate
where the bogus value is coming from (valgrind sees it as cmd_checkout,
but presumably that is because it inlines the static
update_refs_for_switch).

Can you try that? Otherwise, I'm not sure how to proceed because I can't
reproduce it on my box.

-Peff