[U-Boot] debugging malloc heap corruption on 2015.04
Chris Packham
judge.packham at gmail.com
Tue Aug 11 01:56:58 CEST 2015
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
More information about the U-Boot
mailing list