From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Sat, 04 Mar 2017 19:49:23 GMT
Subject: Re: [PATCH v1] Travis: also test on 32-bit Linux
Message-ID: <af31ef46-bd0c-c3f2-5a1e-7d97da6ec9a0@oracle.com>
In-Reply-To: <f5f5886a-aaec-7426-ea33-f5d65516348b@oracle.com>

On 04/03/2017 19:08, Vegard Nossum wrote:
> On 04/03/2017 18:23, Lars Schneider wrote:
>> Did Travis find our first 32bit bug? I briefly looked into it
>> and the following new topic on pu seems to cause the issue:
>>
>> http://public-inbox.org/git/20170302172902.16850-1-allan.x.xavier@oracle.com/
>>
>> https://github.com/git/git/commit/aaae0bf787f09ba102f69c3cf85d37e6554ab9fd
>>
>>
>> The "git log" call in the new 4211 test fails with:
>> *** Error in `/usr/src/git/git': malloc: top chunk is corrupt:
>> 0x09ff4a78 ***
>>
>> More output here:
>> https://travis-ci.org/larsxschneider/git/builds/207715343
>
> It looks like it's hitting the bug the patch is supposed to fix.
>
> Are you quite sure it's running the "git" binary that was just built (as
> opposed to e.g. the system binary installed inside the container)?

Nevermind, I can reproduce it locally.

==10205== Invalid write of size 4
==10205==    at 0x4031ED2: memcpy (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==10205==    by 0x811C4B0: memcpy (string3.h:53)
==10205==    by 0x811C4B0: range_set_copy.isra.7 (line-log.c:46)
==10205==    by 0x811C51B: line_log_data_copy_one (line-log.c:628)
==10205==    by 0x811C55D: line_log_data_copy (line-log.c:642)
==10205==    by 0x811C5E3: add_line_range (line-log.c:708)
==10205==    by 0x811D767: line_log_init (line-log.c:745)
==10205==    by 0x808B1CD: cmd_log_init_finish (log.c:204)
==10205==    by 0x808C9C8: cmd_log_init (log.c:213)
==10205==    by 0x808C9C8: cmd_log (log.c:681)
==10205==    by 0x804CF14: run_builtin (git.c:373)
==10205==    by 0x804CF14: handle_builtin (git.c:574)
==10205==    by 0x804D264: run_argv (git.c:626)
==10205==    by 0x804D264: cmd_main (git.c:703)
==10205==    by 0x804C448: main (common-main.c:43)
==10205==  Address 0x4cde9c8 is 0 bytes after a block of size 1,600 alloc'd
==10205==    at 0x402D17C: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==10205==    by 0x402F370: realloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==10205==    by 0x819CC0F: xrealloc (wrapper.c:137)
==10205==    by 0x811C1C8: range_set_grow (line-log.c:21)
==10205==    by 0x811C499: range_set_init (line-log.c:32)
==10205==    by 0x811C499: range_set_copy.isra.7 (line-log.c:45)
==10205==    by 0x811C51B: line_log_data_copy_one (line-log.c:628)
==10205==    by 0x811C55D: line_log_data_copy (line-log.c:642)
==10205==    by 0x811C5E3: add_line_range (line-log.c:708)
==10205==    by 0x811D767: line_log_init (line-log.c:745)
==10205==    by 0x808B1CD: cmd_log_init_finish (log.c:204)
==10205==    by 0x808C9C8: cmd_log_init (log.c:213)
==10205==    by 0x808C9C8: cmd_log (log.c:681)
==10205==    by 0x804CF14: run_builtin (git.c:373)
==10205==    by 0x804CF14: handle_builtin (git.c:574)

At a glance, looks like range_set_copy() is using
sizeof(struct range_set) == 12, but
range_set_init/range_set_grow/ALLOC_GROW/REALLOC_ARRAY is using
sizeof(rs->range) == 8.


Vegard