When newlib is configured with --enable-newlib-reent-check-verify,
the assert macro is already defined in the nano-mallocr.c compile unit.
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
The only reason why it is tough for us to use nano malloc
is because of the small shortcoming where nano_malloc()
splits a bigger chunk from the free list into two pieces
while handing back the second one (the tail) to the user.
This is error prone and especially bad for smaller heaps,
where nano malloc is supposed to be superior. The normal
malloc doesn't have this issue and we need to use it even
though it costs us ~2k bytes compared to nano-malloc.
The problem arise especially after giving back _every_
malloced memory to the heap and then starting to exercise
the heap again by allocating something small. This small
item might split the whole heap in two equally big parts
depending on how the heap has been exercised before.
I have uploaded the smallest possible application
(only tested on ST and Nordic devices) to show the issue
while the real customer applications are far more complicated:
https://drive.google.com/file/d/1kfSC2KOm3Os3mI7EBd-U0j63qVs8xMbt/view?usp=sharing
The application works like the following pseudo code,
where we assume a heap of 100 bytes
(I haven't taken padding and other nitty and gritty
details into account. Everything to simplify understanding):
void *ptr = malloc(52); // We get 52 bytes and we have
// 48 bytes to use.
free(ptr); // Hand back the 52 bytes to nano_malloc
// This is the magic line that shows the issue of
// nano_malloc
ptr = malloc(1); // Nano malloc will split the 52 bytes
// in the free list and hand you a pointer
// somewhere in the
// middle of the heap.
ptr2 = malloc(52); // Out of memory...
I have done a fix which hands back the first part of the
splitted chunk. Once this is fixed we obviously
have the 1 byte placed in position 0 of the heap instead
of somewhere in the middle.
However, this won't let us malloc 52 new bytes even though
we potentially have 99 bytes left to use in the heap. The
reason is that when we try to do the allocation,
nano-malloc looks into the free list and sees a 51 byte
chunk to be used.
This is not big enough so nano-malloc decides to call
sbrk for _another_ 52 bytes which is not possible since
there is only 48 bytes left to ask for.
The solution for this problem is to check if the last
item in the free list is adjacent to sbrk(0). If it is,
as it is in this case, we can just ask sbrk for the
remainder of what is needed. In this case 1 byte.
NB! I have only tested the solution on our ST device.
The overflow check in mEMALIGn erroneously checks for INT_MAX,
albeit the input parameter is size_t. Fix this to check for
__SIZE_MAX__ instead. Also, it misses to check the req against
adding the alignment before calling mALLOc.
While at it, add out-of-bounds checks to pvALLOc, nano_memalign,
nano_valloc, and Cygwin's (unused) dlpvalloc.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The MSP430 target supports both 16-bit and 20-bit size_t and intptr_t.
Some implicit casts in Newlib expect these types to be
"long", (a 32-bit type on MSP430) which causes warnings during
compilation such as:
"cast from pointer to integer of different size"
commit 588a5e1dde added a non-reentrant
call to nano_malloc which causes a build failure if INTERNAL_NEWLIB is
defined.
Here is a snippet of the error:
In file included from .../newlib/newlib/libc/stdlib/nano-mallocr.c:38:
.../newlib/newlib/libc/include/malloc.h:42:25: note: expected 'struct _reent *' but argument is of type 'ptrdiff_t' {aka 'int'}
42 | extern void *_malloc_r (struct _reent *, size_t);
| ^~~~~~~~~~~~~~~
.../newlib/newlib/libc/stdlib/nano-mallocr.c:67:22: error: too few arguments to function '_malloc_r'
67 | #define nano_malloc _malloc_r
| ^~~~~~~~~
.../newlib/newlib/libc/stdlib/nano-mallocr.c:456:11: note: in expansion of macro 'nano_malloc'
456 | mem = nano_malloc(bytes);
| ^~~~~~~~~~~
In file included from .../newlib/newlib/libc/stdlib/nano-mallocr.c:38:
.../newlib/newlib/libc/include/malloc.h:42:14: note: declared here
42 | extern void *_malloc_r (struct _reent *, size_t);
| ^~~~~~~~~
.../newlib/newlib/libc/stdlib/nano-mallocr.c:43: warning: "assert" redefined
43 | #define assert(x) ((void)0)
|
This patch adds a missing RCALL to the args when calling nano_malloc
from nano_calloc, so that if the call is reentrant, reent_ptr is passed
as the first argument.
The variable `bytes` (also added in 588a5e1d) has been changed from a
`ptrdiff_t` to `malloc_size_t` as it does not need to be signed. It is
used to store the product of two unsigned malloc_size_t variables and
then iff there was no overflow is it passed to malloc and memset which
both expect size_t which is unsigned.
Signed-off-by: Craig Blackmore <craig.blackmore@embecosm.com>
This built-in function (available in both gcc and clang) is more
efficient and generates shorter code than open-coding the test.
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch adds further comments to nano-mallocr.c, to more comprehensively
explain how padding works in the malloc_chunk structure.
It was originally discussed in the following thread:
https://sourceware.org/ml/newlib/2017/msg00031.html
2017-01-13 Joe Seymour <joe.s@somniumtech.com>
newlib/
* libc/stdlib/nano-mallocr.c (malloc_chunk, get_chunk_from_ptr)
(nano_malloc): Add comments.
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.
Thanks,
2017-01-XX Joe Seymour <joe.s@somniumtech.com>
newlib/
* libc/stdlib/nano-mallocr.c (nano_malloc): Fix incorrect cast.
(nano_memalign): Likewise.
Non-reentrant system calls version implies both MISSING_SYSCALL_NAMES
and REENTRANT_SYSCALL_PROVIDED macros to be defined.
Being coupled with --enable-newlib-nano-malloc knob it breaks the build:
bash-4.3$ ../newlib-2.3.0.20160104/configure CC_FOR_TARGET=gcc
AR_FOR_TARGET=ar RANLIB_FOR_TARGET=ranlib CFLAGS_FOR_TARGET="-m32
-DMISSING_SYSCALL_NAMES -DREENTRANT_SYSCALLS_PROVIDED"
--target=i386-elf --enable-newlib-nano-malloc && make
<...omitted output...>
../../../../../../newlib-2.3.0.20160104/newlib/libc/stdlib/nano-mallocr.c:
In function ‘_mallinfo_r’:
../../../../../../newlib-2.3.0.20160104/newlib/libc/stdlib/nano-mallocr.c:489:35:
error: macro "_sbrk_r" requires 2 arguments, but only 1 given
sbrk_now = _sbrk_r(RCALL 0);
^
../../../../../../newlib-2.3.0.20160104/newlib/libc/stdlib/nano-mallocr.c:489:20:
error: ‘_sbrk_r’ undeclared (first use in this function)
sbrk_now = _sbrk_r(RCALL 0);
^
../../../../../../newlib-2.3.0.20160104/newlib/libc/stdlib/nano-mallocr.c:489:20:
note: each undeclared identifier is reported only once for each
function it appears in
Makefile:1512: recipe for target 'lib_a-nano-mallinfor.o' failed
make[8]: *** [lib_a-nano-mallinfor.o] Error 1
In case of non-reentrant system calls _sbrk_r became a macro with TWO
args (defined in reent.h):
#define _sbrk_r(__reent, __incr) sbrk(__incr)
But in our case only one argument is present. (RCALL 0) is considered
as a single argument despite RCALL itself is a macro:)
So intermediate one-arg macro will be enough to expand args before
final _sbrk_r expansion:
#define _SBRK_R(X) _sbrk_r(X)
Here is a patch:
* libc/stdlib/nano-mallocr.c (RONECALL): New parameter macro.
(sbrk_start): New variable.
(current_mallinfo, free_list): Forward declaration of data.
(chunk): Define size as long type.
(mallinfo): Synchronize with latest malloc.h.
(nano_*): Forward declaration of functions.
(get_chunk_from_ptr): Defined to static inline.
(nano_mallinfo): Implement this function.
(nano_malloc_stats): Implement this function.
Torbjorn SVENSSON via Newlib
Ola Olsson
Corinna Vinschen
Jozef Lawrynowicz
Craig Blackmore
Jaap de Wolff
Joe Seymour
Andre Vieira (lists)
Игорь Веневцев
DJ Delorie
Corinna Vinschen
Jeff Johnston