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