On Tue, Aug 11, 2015 at 11:56 AM, Chris Packham <judge.pack...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot