Re: [PATCH v1] Travis: also test on 32-bit Linux
- From
Vegard Nossum <vegard.nossum@oracle.com>
- Date
- Mar 4, 2017, 20:08 UTC
- Message-ID
- <282895e1-d9eb-2368-a8e7-8085ad9b17ed@oracle.com>
- In-Reply-To
- <af31ef46-bd0c-c3f2-5a1e-7d97da6ec9a0@oracle.com>
On 04/03/2017 20:49, Vegard Nossum wrote:
Show 18 quoted lines
> 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
[...]
> 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.
Attached patch seems to fix it -- basically, range_set_copy() is trying to copy more than it should. It was uncovered with the test case from Allan's commit because it's creating enough ranges to overflow the initial allocation on 32-bit.
Vegard
diff --git a/line-log.c b/line-log.c index 951029665..cb0dc1110 100644 --- a/line-log.c +++ b/line-log.c @@ -43,7 +43,7 @@ void range_set_release(struct range_set *rs) static void range_set_copy(struct range_set *dst, struct range_set *src) { range_set_init(dst, src->nr); - memcpy(dst->ranges, src->ranges, src->nr*sizeof(struct range_set)); + memcpy(dst->ranges, src->ranges, src->nr*sizeof(struct range)); dst->nr = src->nr; } static void range_set_move(struct range_set *dst, struct range_set *src)