Created attachment 116178 [details] dmesg with oom killer message, not much info in there tho I'm running separate secondary X server when I'm gaming (steam games, libsdl with pulse backend)and whenever I start some audio application on primary X (be it youtube tab in chrome, firefox or music in clementine player), after some while the music application runs wild and gets killed by oom killer. Only common denominator I can think of is pulseaudio so I thought I would report it here. I tried running pulseaudio -vvvv but I haven't seen anything suspicious, could anyone point me to some way to provide more info here?
Created attachment 116182 [details] pulseaudio -vvvv log Here is pulseaudio's verbose log, bug happened (marked by underruns halfway in the log) and chrome process with youtube tab got killed by oom (trashed entire page cache).
(In reply to Tomas Pruzina from comment #0) > could anyone point me to some way to provide more info here? Can you see in top or something that the application memory starts to grow fast? If yes, are you able to shut down the application cleanly before it gets forcibly killed? If yes, you could try running the application in Valgrind, and when the memory consumption starts to grow, shut down the application. If Valgrind shows that libpulse is leaking memory, then that would be something to work on.
Or another approach would be to give exact instructions for reproducing the bug. Maybe someone will then investigate it if they can reproduce the bug (I don't promise to do that myself, though, due to lack of time.)
If there's a leak on our side, it's not in the PulseAudio process itself, so logs won't help. Things to try: 1. You could watch the output of 'pactl stat' as the Chrome (or whatever) process memory balloons 2. Once Chrome/whatever memory is very high, you could also copy /proc/<pid of the process>/smaps somewhere and post it 3. As Tanu suggested, running Valgrind would be the most reliable option. Unfortunately, things will be really slow under Valgrind, so you might want to see if this problem occurs with a simpler command line tool (paplay --raw /dev/zero, or gst-launch-1.0 audiotestsrc wave=silence ! pulsesink). You'd need to run this with something like: valgrind --leak-check=full --show-reachable=yes --log-file=catchtheleak.log <the program and arguments>
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/351.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.