[U-Boot] debugging malloc heap corruption on 2015.04

[Chris Packham]

On Tue, Aug 11, 2015 at 11:56 AM, Chris Packham <judge.packham at gmail.com> wrote:
> Hi All,
>
> I've migrate a custom armv7 board from v2015.01 to v2015.04. One issue
> I've just started seeing is an odd hang _sometimes_ when booting
> automatically. The issue doesn't (seem to) happen when the boot
> process is interrupted and I run the "boot" command. I can also make
> the problem appear or go away by adding a few arbitrary environment
> variables.
>
> The actual hang is in memcpy() invoked via realloc(). memcpy is going
> off into the weeds because it was asked to copy an impossibly large
> number of bytes which no doubt comes from realloc thinking that the
> old pointer had 0 size and subtracting SIZE_SZ from it. realloc() is
> getting this size because it's being asked to realloc something that
> wasn't allocated by it. In this case the pointer it's being asked to
> realloc is 0x8 (0x0 is valid and handled correctly as an alias for
> malloc()).
>
> I've tracked this down as far as done_command() it appears that
> pi->progs has the value 0x8 and triggers this problem when
> xrealloc()'d.
>
> As for why pi->progs ends up with this value I'm unsure. All the code
> handling it seems to be OK and given the fact that it only happens
> under certain conditions I'm suspecting it's probably heap corruption
> or possibly a rouge cache invalidation causing the value to change
> under the hood.
>
> I'm not sure that this problem wasn't occurring earlier if it is heap
> corruption the behaviour would depend on what's getting corrupted.
> I've taken a quick look at v2015.07 there doesn't appear to be any
> obvious fix for this issue.
>
> Does this ring any bells for anyone? Are there any poisoning or guard
> options for dlmalloc that I should try out?
>
> Thanks,
> Chris

A little bit more info. 0x8 appears to be coming from a previous call
to malloc() somehow it's getting victim = 0x0 and chunk2mem(0x0) gives
us 0x8.

Now the question is where is 0 coming from. It doesn't appear to be
coming from a bad free(). It looks like the dlmalloc implementation
should catch out of memory errors and return NULL so I don't think
I've exhausted the malloc pool. I'm still thinking something is
wandering off the end of allocated memory and corrupting the fd, bk
pointers.