Re: [PATCH v1] Travis: also test on 32-bit Linux
- From
Vegard Nossum <vegard.nossum@oracle.com>
- Date
- Mar 4, 2017, 19:49 UTC
- 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:
Show 20 quoted lines
> 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