GStreamer Memory Leak #511
Comments
|
Thanks. Have you tried to run the program using |
|
I have not used valgrind before. If you'll let me know what I need to do I would be happy to try. |
|
You can start with this: Let liquidsoap run for a while then hit |
|
Done. I've pasted the output below and here as well: https://pastebin.com/raw/FU4DV3k8 |
|
Thanks! You might need to run it a little longer, though, I only see initialization-related leaks here. You can also take the |
|
Will do. I saw this bit here: I will run it again with --error-limit=no for a few hours and post the results. Thank you. |
|
Doesn't seem to want to cycle thru my playlist when using valgrind (or let me watch the stream at all). It runs fine (minus the memory leak over time) when not using valgrind. Regardless, here's what I have from valgrind:
I've also pasted it here again: https://pastebin.com/raw/Qvzkfkms Here's the last few lines my liquidsoap log shows: The video being played is only 20 minutes long and I let liquidsoap run for an hour or so without any activity in the log. My apologies for the confusion. |
|
Hi,
|
|
Hi,
looking at htop on debian stretch, I see that things stay stable when the playlist is being played, but as soon as the fallback is being played (a short video of about 4 seconds), with each repetition the memory is being upped by 200 megs (plusminus the size of the video). This goes on until all memory is used and then LiquidSoap is killing itself. Takes about 10 minutes. Please let me know if I can help with this, I have a show coming up in three weeks... Best, Jeroen ps. opam installed version 1.3.3 |
|
Hi, Nope, it looks like there's something wrong with the |
|
Thanks for getting back. |
|
Is there any connection with this phenomenon in the log?? There is a lot of
warnings/errors. The log part below is from running a single file in fallback only, at the point where the fallback video is reloaded. Strangely enough, with a ten minute video, there is no memory leak in htop, stays fix around 500 megs after a couple of repetitions.
|
|
Any developments on this? |
|
No. I still don't like this bug. Will have another look at it shortly. |
|
I have the feeling I'm experiencing the same issue. |
|
Thanks. This bug has been eluding us for a while, unfortunately. |
|
So it seems that the LS playback never actually reaches the gstreamer output. At least I don't see any memory usage above ~500mb (where normally at the first output instance it is about ~1.3gb as I said). After about 2 minutes the process stops. Here is the log: |
|
So was this at all useful @toots ? |
|
Hey, Could you try with the latest |
|
Ah, you didn't change the version number. Not sure if opam is installing the new ocaml-gstreamer now .. |
|
So I tried an Maybe you have to up the version so opam picks it up? |
|
Ok I manually installed the package with Now LS uses 400MB memory and the threads are using almost no CPU. Seems your changes killed gstreamer intirely :( (don't push this to opam please, at least the prev. version sort of works ;) ) |
|
Ok, try again now? |
|
Ok it runs now, but still eats memory as I skip tracks in the playlist. |
|
Can you confirm a longer term trend? When I skip I see memory spiking but then it goes back down. |
|
Yes, left it running for a while and oomkiller came by to shoot it down :( |
|
Ok, thanks for trying. Would you mind trying again with the latest changes? |
|
Hmm, I just built and installed gstreamer |
|
You request probably cannot be resolved. Try using a I'm happy to report that with the latest code it seems that memory usage is under control now. Release is imminent to any quick testing and report would be gladly received! |
|
Is that with gstreamer btw I was missing a bunch of plugins and dependencies on my manual compile of Also when using playlists. |
|
(with latest current sources same result btw, except LS doesn't fully shut down and I have to |
|
What's your test script? |
|
This, which is like the minimum I want to be able to run (can of course make a more minimal version) So are you now testing with stock debian stable gstreamer, or on debian unstable with 1.14.2 ? |
|
Ok, I'm not trying (debian stable gstreamer) with your output stage (except with the rtmpsink) and it works! So the only difference is the The only thing is I cannot stop the thread with But then the process just keeps hanging. Have to |
|
You need to update Good news about the script. If I test yours it fails because there's no Can you let it run for a while and report? Memory usage was definitely stable here. |
|
Yes I have it running with my original playlists and queues. Will let in run for a while to see what happens to the memory :) What I can tell so far is that when running |
|
Can you try your test-script but with my videoconvert and audioconvert settings? that's: |
|
ok not sure what happened but I'm no longer getting output from LS. process is still running and using memory. no cpu usage whatsoever. can't do a |
|
Tried again and same result. After playing about 4 videos (maybe less than an hour total) LS becomes unresponsive. (no memory leaks though ;) ) |
|
Any logs? Make sure you set |
|
Ok, you might want to test again (I know!) with the latest code. I've made more changes to handle message bus differently. It still looks stable on my end (including with your code). |
|
Ok it's running (updated all repos and submodules). Lets see how long it lasts :D |
|
does this huge onset of latest development mean that we're also about to have a win32 build without a memory leak, long file skipping issues and with properly working terminal?!
cheers,
p
|
|
It means that we're working on fixing a particular problem right now. Hold your horses with your list of requests. There can be other reports on this. |
|
@toots same result btw. after some time LS just sits idle and unresponsive. Some log: And when I After which I have to |
|
Any more info with |
|
Ah yes sorry, will run again with this setting! |
|
Hmm, even though the on-screen logging is much more verbose, there is nothing written to file .. Also the LS process does still respond, I can connect over telnet! it then says that a client connects or disconnects. However running ie. |
|
Yeah that's what I'm thinking. I'd love to see those logs.. |
|
Well here's the tail of my LS output (don't feel like anonymizing the files :P) As I said LS is no longer writing logfiles, but to stdout now (before it was quiet on stdout but wrote the logfiles). Is this a new config thing? As you can see it responds to telnet clients, but none of the This is with default gstreamer from debian stable. |
|
Thanks! Would you mind sending me a Once I get this, I'll close this issue and open a new one with these info. |
|
Hmm, I get |
|
You prolly need to run it as |
|
Ok, coming up! |
|
Ok, awesome, thks! Gonna close this one and re-open. You might want to install the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related issues: #434 #318
I believe these GStreamer memory leaks are still occurring in the lastest build from the repo (installed using opam). Running four video streams starts at around 20% of my actual memory usage and slowly moves to 100% over the course of 4-5 hours.
My config:
Output of
liquidsoap --versionOutput of
opam listServer specs:
Please let me know if there's any additional info I can provide to solve this issue. I would post the --debug log here but I don't want to reveal any sensitive information. I would be happy to send it to you directly if you think it would help.
The text was updated successfully, but these errors were encountered: