Bug 90786 - Memory leak when running multiple X instances
Summary: Memory leak when running multiple X instances
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: clients (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-30 15:28 UTC by Tomas Pruzina
Modified: 2018-07-30 10:20 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg with oom killer message, not much info in there tho (9.72 KB, text/plain)
2015-05-30 15:28 UTC, Tomas Pruzina
Details
pulseaudio -vvvv log (487.83 KB, text/plain)
2015-05-30 17:20 UTC, Tomas Pruzina
Details

Description Tomas Pruzina 2015-05-30 15:28:46 UTC
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?
Comment 1 Tomas Pruzina 2015-05-30 17:20:16 UTC
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).
Comment 2 Tanu Kaskinen 2015-05-31 13:29:19 UTC
(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.
Comment 3 Tanu Kaskinen 2015-05-31 13:32:06 UTC
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.)
Comment 4 Arun Raghavan 2015-06-01 03:59:18 UTC
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>
Comment 5 GitLab Migration User 2018-07-30 10:20:01 UTC
-- 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.