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

From: Jeff King <peff@peff.net>
Date: Jul 18, 2009, 15:31 UTC
Message-ID: <20090718153148.GA9367@sigill.intra.peff.net>
In-Reply-To: <20090718141658.GE16708@vidovic>

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

Show 5 quoted lines

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

Show 10 quoted lines

> ==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