Re: [PATCH v1] Travis: also test on 32-bit Linux

[Vegard Nossum <vegard.nossum@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

On 04/03/2017 20:49, Vegard Nossum wrote:
> 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

[-- Attachment #2: range_set_copy.patch --]
[-- Type: text/x-patch, Size: 511 bytes --]

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)