[Live-devel] Memoryleak only when connecting memory tool
Jeff Shanab
jshanab at jfs-tech.com
Tue Jan 28 15:09:22 PST 2014
Because of this suspicion, I ran without the tool at very low resolutions
and used windows' right-click mini-dump feature. I then post processed
these dumps and found the same exact objects, the 68 byte BufferPacket
structure and the 10k BufferPackets growing. Surprisingly they are not in
lock step, the number of structs and buffers are not the same. I ran this
test on 2 windows 7 machines and have the same leak on Linux. During the
test one one machine I am using a total of 2% CPU. 5 of the 8 cores are
idle and the 64bit OS is at around 5/12 GB. The process is 32 bit and these
tests are discontinued when memory usage approaches 1GB.
It does seems to be timing sensitive, like we do not return soon enough so
it creates a BufferPacket. The problem is it isn't releaseing them Almost
like there are more buffer packets than there are scheduled or direct
afterGetting calls. Not a Performance issue, just somehow missed consumer
tasks.
The more streams or the attachment of the memory validator tool does
increase the frequency of the allocations.
Because this software usually runs 50+ high res streams on lesser hardware,
there is during this test, a surplus of consumer capability.
Tests of the newest version of live555 are scheduled. a bit of migration
may be needed. Our code goes on windows, linux and embedded targets, so
getting all architecture builds is not trivial. I did compare the current
live555 MultiFramedRtpSource with ours and there have been a few changes.
Thanks
On Tue, Jan 28, 2014 at 4:35 PM, Ross Finlayson <finlayson at live555.com>wrote:
> 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.
>
>
> If this is happening, it must be because the incoming data is being
> consumed at a slower rate than the rate at which it is arriving. I.e.,
> your 'Memory Tool' is causing your system to slow down so much that it
> can't keep up with processing the incoming streams. To avoid this, you'll
> need to reduce the number and/or bitrate of your incoming streams.
>
>
> The version of live555 is not current
>
>
> We support only the current release of the code!
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140128/3895d40e/attachment.html>
More information about the live-devel
mailing list