rtems 4.6.0pre5: memory leak after deleting a task used printf
strauman at slac.stanford.edu
Wed Oct 20 04:20:21 UTC 2004
Joel Sherrill wrote:
> Valery Pykhtin wrote:
>> Hi all,
>> It seems there is a memory leak when deleting a task used printf.
>> I created the test:
>> 1. Calculating the amount of free/used blocks in c heap using
>> 2. Starting new task
>> 3. Task does printf and selfdeletes
>> 4. Calculating the amount of free/used blocks in c heap using
>> 5. Comparing values before starting a task with values after.
>> 6. Goto point 1
> If newlib is allocating the memory implicitly, then the
> thread-exit delete extension in cpukit/libcsupport/src/newlibc.c
> should be doing or calling something that frees it. Look at
> that code and see if it is missing something.
> This wouldn't be the first time that newlib allocated memory
> that it's clean up routines did not account for.
Well, we don't call their cleanup routines in the first place
__wrapup_reent() / __reclaim_reent() are commented out...
I did a similar test under rtems-4.6 (newlib 1.11.0) and
I observe a memory leak if a task uses more than 3 file
descriptors since excess '__sglue' memory (allocated in
__sfmoreglue) is not released.
Seems that our newlibc support routines are quite dependent
on newlib internals and have probably not been revised
thoroughly in a while...
>> After each iteration the number of used blocks is continously
>> increasing. To catch the bandit I created memory allocation tracer
>> wich logs every _Heap_Allocate and _Heap_Free and (log include stack
>> traces for each allocation) and marks those blocks that were not freed.
>> The stack trace of the bandit:
>> #0 __wrap__Heap_Allocate
>> #1 _Region_Allocate_segment
>> #2 rtems_region_get_segment
>> #3 malloc
>> #4 _malloc_r
>> #5 __smakebuf at newlib/libc/stdio/makebuf.c:81
>> #6 __swsetup at newlib/libc/stdio/wsetup.c:63
>> #7 _vfprintf_r at newlib/libc/stdio/vfprintf.c:519
>> #8 vfprintf at newlib/libc/stdio/vfprintf.c:367
>> #9 printf at newlib/libc/stdio/printf.c:62
>> #10 TestTask
>> where TestTask is my test task, __wrap__Heap_Allocate -
>> _Heap_Allocate wrapper.
>> I can send the test I've used, it contains the memory allocation
>> tracer and completly ready to run under debugger. My BSP is pc586.
>> Note that the test uses builtin GCC functions __builtin_frame_address
>> and __builtin_return_address.
>> Tommorow I'm going to repeat the test with RTEMS 4.6.2
More information about the users