[RTEMS Project] #3755: leak in realloc

[RTEMS trac]

#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:
 Blocking:                |
--------------------------+---------------------

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
 code?

 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 -
 info.Stats.lifetime_freed)
 }}}

--
Ticket URL: <http://devel.rtems.org/ticket/3755#comment:16>
RTEMS Project <http://www.rtems.org/>
RTEMS Project