[RTEMS Project] #3755: leak in realloc
trac at rtems.org
Fri Aug 2 00:47:20 UTC 2019
#3755: leak in realloc
Reporter: Jeffrey Hill | Owner: (none)
Type: defect | Status: new
Priority: normal | Milestone:
Component: score | Version: 4.11
Severity: normal | Resolution:
Keywords: realloc leak | Blocked By:
Comment (by Jeffrey Hill):
> If so, what's difference between the two?
A very short experiment today, returning to the default Lua allocator
based on realloc, resulted in a much smaller largest-free-block. I didn't
try this experiment returning to the default Lua allocator more than once.
During this test the system's free memory appeared to drop to a plateau of
about 95 MB free in a 125MB RAM with the default Lua allocator. We see
about the same result with our replacement Lua allocator.
We continue to produce a robust system using a replacement Lua allocator
that uses a 64 byte free list for small blocks, and falling back on RTEMS
to ordinary malloc and free for the larger blocks. I have heard that other
code bases use the LOKI small block allocator for this purpose, but we
haven't gone there. Our largest free block is stable at 9797512 bytes on a
125MB RAM during testing today on the replacement Lua allocator, which
isn't optimal, but the systems in question are solid. Our largest free
block was stable at about 3MB bytes on a 125MB RAM using the default Lua
allocator, which is definitely scary.
We isolated and fixed several leaks in the EPICS save/restore component,
and this appears to have been the root problem. This was somewhat of a
surprise because the EPICS save/restore component is used ubiquitously in
our community. Memory leaks can be hard to find, especially in modal
systems. It turns out that on this particular system a PID loop parameter
was inadvertently in the variable list to save, and so the leak rate was
dramatically increased, and we didn't see the issue initially on the host
development platforms with Valgrind / Intel Tools because of the
modalities. I am still running long term tests to see if any leaks remain.
> Also is there a bug to be fixed in the protected heap instrumentation
Initially there was a strong signature of a leak when we were using the
following code for answering the "how much memory is left" question, and I
recall confirming that there was a behavior change before and after
switching the allocator when I submitted this entry. I have not tried
returning to this computation, and instead we are now using simply
"Free.total". I was peeking at score, and a very quick check indicated
that the score version of realloc maybe isn't recalculating the
lifetime_allocated and lifetime_freed statistics. Probably, this happens
only indirectly when the score version of realloc calls the score version
of malloc and free. But I didn't look at this too long and could be wrong.
So ... I don't know for certain that there is an issue with
lifetime_allocated and lifetime_freed when making heavy use of realloc,
but I have some suspicions.
info.Stats.size - (unsigned long)(info.Stats.lifetime_allocated -
Ticket URL: <http://devel.rtems.org/ticket/3755#comment:16>
RTEMS Project <http://www.rtems.org/>
More information about the bugs