[PATCH 1/2] Fix incorrect cast in nano malloc

Corinna Vinschen vinschen@redhat.com
Mon Jan 9 15:22:00 GMT 2017


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20170109/5ce4ffbf/attachment.sig>


More information about the Newlib mailing list