On Jan 3 14:50, Joe Seymour wrote: > As described in nano-mallocr.c, chunks of heap are represented in memory > as a size (of type long), followed by some optional padding containing a > negative offset to size, followed by the data area. > > get_chunk_from_ptr is responsible for taking a pointer to the data area > (as returned by malloc) and finding the start of the chunk. It does this > by assuming there is no padding and trying to read the size, if the size > is negative then it uses that as an offset to find the true size. > Crucially, it reads the padding area as a long. > > nano_malloc is responsible for populating the optional padding area. It > does so by casting a pointer to an (int *) and writing the negative > offset into it. > > This means that padding is being written as an int but read as a long. > > On msp430 an int is 2 bytes, while a long is 4 bytes. This means that 2 > bytes are written to the padding, but 4 bytes are read from it: it has > only been partially initialised. > > nano_malloc is the default malloc implementation for msp430. > > This patch changes the cast from (int *) to (long *). The change to > nano_malloc has has been observed to fix a TI Energia project that > had been malfunctioning because malloc was returning invalid addresses. > The change to nano_memalign is based entirely on code inspection. > > I've built and tested as follows: > Configured (gcc+newlib) with: --target=msp430-elf --enable-languages=c > gcc testsuite variations: > msp430-sim/-mcpu=msp430 > msp430-sim/-mcpu=msp430x > msp430-sim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either > msp430-sim/-mhwmult=none > msp430-sim/-mhwmult=f5series > My testing has shown no regressions, however I don't know if the gcc > testsuite provides sufficient coverage for this patch? > > I don't have write access, so if this patch is acceptable after review, > I would appreciate it if someone would commit it for me. Applied. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat