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@xxxxxxxxxx/
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)