Re: Memory corruption when rebasing with git version 1.8.1.5 on arch

From: Jeff King <peff@peff.net>
Date: Mar 19, 2013, 13:44 UTC
Message-ID: <20130319134452.GA6752@sigill.intra.peff.net>
In-Reply-To: <51484125.9000307@bernhard-posselt.com>

On Tue, Mar 19, 2013 at 11:42:45AM +0100, Bernhard Posselt wrote:

Show 11 quoted lines

> it seems that the memory corruption does not happen anymore when i change
> 
> [apply]
>         whitespace = fix
> 
> to
> 
> [apply]
>         #whitespace = fix
> 
> so fixing whitespaces may be the culprit

Thanks, I'm able to reproduce with the config you showed. The other key element seems to be using tab-in-indent. I am not too familiar with this code, but I was able to get a much smaller reproduction recipe:

-- >8 --
# make tabs more obvious by using "Q" instead
q_to_tab() {
  perl -lpe 's/Q/\t/g'
}

q_to_tab >preimage <<\EOF
QQa
QQb
QQc
                d
QQe
QQf
QQg
EOF

q_to_tab >patch <<\EOF

diff --git a/preimage b/preimage
--- a/preimage
+++ b/preimage
@@ -1,7 +1,6 @@ public static function store($filename) {
 QQa
 QQb
 QQc
-QQd
 QQe
 QQf
 QQg
EOF

valgrind \
git -c core.whitespace=tab-in-indent apply --whitespace=fix patch
-- 8< --

which yields:

==7112== Invalid write of size 2
==7112==    at 0x4C2C023: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7112==    by 0x40C365: update_pre_post_images (apply.c:2165)
==7112==    by 0x40CC52: match_fragment (apply.c:2402)
[...]
==7112==  Address 0x6e57a5e is 0 bytes after a block of size 94 alloc'd
==7112==    at 0x4C2A26B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7112==    by 0x4C2A51F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7112==    by 0x535193: xrealloc (wrapper.c:100)
==7112==    by 0x51C322: strbuf_grow (strbuf.c:74)
==7112==    by 0x51C10C: strbuf_init (strbuf.c:34)
==7112==    by 0x40D329: apply_one_fragment (apply.c:2602)
[...]

and so on. I haven't quite figured out what is going on. It looks like
we call update_pre_post_images with postlen==0, which causes it to just
write the fixed postimage into the existing buffer. But of course the
fixed version is bigger, because we are expanding the tabs into 8
spaces (but it _doesn't_ break if each line starts with only one tab,
which confuses me).

I'm not too familiar with this code. Maybe Junio can say more.

-Peff