<div dir="ltr"><div><div><div><div><div><div><br></div>   I have a strange problem showing up while trying to solve a memory leak elsewhere in my code. When I attach a memory tool it somehow messes timing or something and live555 begins to create BufferPacket structures of 68 bytes with a payload of 10K.  Somehow they are not released so the code to get a free one ends up allocating a new one.  (Reorder buffer in multiframedrtpsource)<br>
<br></div>   If I let the app run for over a day a slow growth of memory usage occurs. This is what I am trying to solve. When I connect the Memory Tool, there are no BufferPackets at all. After a few hours, there are a few hundred or a few thousand based on how many streams are connected.  We quickly get into over a gigabyte memory usage on a 32 bit process and it gets worse from there.<br>
<br></div>These are a live-leak or memory growth issue not a dead-leak. Running valgrind or IPP memory leak tools do not show a leak.  <br>The original leak problem is identical on linux and windows.<br></div>The version of live555 is not current, but i have been given reasons we cannot update at the moment. However, if this rings any bells and points to a specific fix in newer code, I can patch or at least prove the need to update!)<br>
<br></div>We have two versions of the code, one with the problem and one without. Swapping in the live555.dll from the version that does not show the issue into the version that does, does not solve the original problem. But the issue of BufferPacket growth when connecting the memory tool is hampering our efforts to find the real leak.  The memory tool in question only runs in windows.<br>
<br></div>Any suggestions would be greatly appreciated.<br></div>