More > JRiver Media Center 23 for Linux
Suspected Memory Leak in Linux Builds
mwillems:
So I've been struggling with my pi jriver builds lately, and after spending a few days troubleshooting, I think I've at least got a handle on what's happening, although I'm not sure why.
Here's the basic observed behavior: jriver starts on the pi and slowly adds memory until it sits at around 40% of the pis available memory at idle. Then if I play music, each track increases the total memory consumed by jriver, but previous track memory is not fully relinquished which leads to a gradually increasing memory footprint until jriver exhausts available memory at which point things start swapping leading to the OOM killer killing the MC process after a few minutes. I can reproduce this just by playing music to it for a half an hour or an hour; at times it can't even finish an album without crashing.
I'm not sure when this behavior started as I had been having pi hardware problems for a month or so (I replaced the defective hardware), but it was definitely not the case earlier in the MC 23 dev cycle. Stopping playback releases a little memory, but not all of it (i.e. it might go from 80% of system memory back down to 72%, but not back down to the baseline 40%). It doesn't seem to make a difference how playback is initiated: I see the same result starting playback on the GUI on the pi, using gizmo, or starting playback fromt the server. It also doesn't seem to make a difference whether the "buffer to disk" options are checked or unchecked as well.
Contextual info:
1) All thumbnails are built.
2) The pi is a client to a library server
3) This occurs with only the media server and the pi on the network.
4) The media server is running windows 10.
5) The DLNA Server and Controller options are unticked on the pi.
6) The only external hardware attached to the pi is a hifiberry amp+, but it uses the same board and driver interface as the Hifiberry DAC+, which I think has been pretty well-tested.
7) MC version is 23.0.102 (which I think is the latest arm version)
Let me know if logs would be helpful, or if anyone has seen anything similar you can offer tips on.
mwillems:
Ok, I did a bunch more differential testing, and I think I've found the culprit: if I untick the box labelled "Auto Sync with Server" under Media Network-->Client Options on the pi, the memory usage levels off and stays level. If I tick the box, I get the behavior I described above, as well as slowly increasing memory usage even when nothing is playing (which I hadn't spotted previously because it's slow). Looking at things in netstat it looks like there are tcp sockets that never close and just kind of keep accumulating, which might account for the increased memory usage?
Not sure why, but that setting appears to be the issue. I previously had that setting disabled, so the leak is not likely to be new (i.e. it may have existed indefinitely, I would have never seen it). I can actually reproduce this on the amd64 build too now on my Arch Linux machine, so I think that setting may just cause a memory leak (at least when a linux client connects to windows server).
bob:
--- Quote from: mwillems on March 30, 2018, 03:39:16 pm ---Ok, I did a bunch more differential testing, and I think I've found the culprit: if I untick the box labelled "Auto Sync with Server" under Media Network-->Client Options on the pi, the memory usage levels off and stays level. If I tick the box, I get the behavior I described above, as well as slowly increasing memory usage even when nothing is playing (which I hadn't spotted previously because it's slow). Looking at things in netstat it looks like there are tcp sockets that never close and just kind of keep accumulating, which might account for the increased memory usage?
Not sure why, but that setting appears to be the issue. I previously had that setting disabled, so the leak is not likely to be new (i.e. it may have existed indefinitely, I would have never seen it). I can actually reproduce this on the amd64 build too now on my Arch Linux machine, so I think that setting may just cause a memory leak (at least when a linux client connects to windows server).
--- End quote ---
Interesting.
I wonder if it's an issue in the Mac and Windows builds as well.
mwillems:
If it exists on windows its either newish or very slow as I had windows clients with that setting enabled running for literally months about a year ago (before I migrated my jriver server back to windows). I had noticed weird leaky behavior on my amd64 Arch machine for more than a year, but I don't always use that machine as a client, so I could never pin it down. It's nice to at least get a differential diagnosis going :-)
If you can't repro it let me know, and I can try to provide more info.
bob:
--- Quote from: mwillems on April 03, 2018, 05:27:27 pm ---If it exists on windows its either newish or very slow as I had windows clients with that setting enabled running for literally months about a year ago (before I migrated my jriver server back to windows). I had noticed weird leaky behavior on my amd64 Arch machine for more than a year, but I don't always use that machine as a client, so I could never pin it down. It's nice to at least get a differential diagnosis going :-)
If you can't repro it let me know, and I can try to provide more info.
--- End quote ---
Trying to repro it.
Did you use lsof to check for the hung sockets?
Are you using any of the other client options like audio transcoding?
Navigation
[0] Message Index
[#] Next page
Go to full version