Heap corruption [the thread formerly known as substitution]

[Peter Stephenson <p.stephenson@samsung.com>]

On Thu, 1 Oct 2015 09:41:40 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> > On Sep 30,  3:04pm, Peter Stephenson wrote:
> > } In some complex git completion --- reproducible only in one set up ---
> > } the heap allocation is apparently going out of bounds.

Some progress.  I've copied some heap info at the point the allocation
takes place --- this is a bespoke debug structure but it's pointing to
standard shell info:

(gdb) p copied_heap_info 
$1 = {heap = 0x2b98ac551000, arena = 0x2b98ac551028, size = 16344, 
  alloc = 0x2b98ac555000}
(gdb) p *copied_heap_info.heap
$2 = {next = 0x0, size = 16384, used = 16344, sp = 0x27a13b0, heap_id = 38650}

That "alloc" is what gdb, valgrind and the OS itself agree is out of
bounds.  Sure enough, the sums say the heap finishes at 0x2b98ac555000,
heap + 16384 or equivalently arena + 16344.  Likely this is the last
heap allocated.

All the addresses look consistent, no obvious of corruption unless it's
being very sneaky, so this is starting to look like a real heap problem
when you happen to get a chance address clash (remember this is a 64-bit
system, if that's relevant).

Bart, any immediate reaction before I dig further?

pws