On Wed, 2014-01-29 at 21:23 +0200, Tanu Kaskinen wrote: > On Wed, 2014-01-29 at 09:28 +0530, Arun Raghavan wrote: > > On Wed, 2014-01-29 at 00:34 +0100, Thomas Meyer wrote: > > > Hi, > > > > > > should pulseaudio actually use that much memory? > > > > > > $ cat status > > > Name: pulseaudio > > > State: S (sleeping) > > > Tgid: 1972 > > > Ngid: 0 > > > Pid: 1972 > > > PPid: 1 > > > TracerPid: 0 > > > Uid: 1000 1000 1000 1000 > > > Gid: 500 500 500 500 > > > FDSize: 64 > > > Groups: 4 6 10 11 36 63 464 468 469 500 > > > VmPeak: 2326912 kB > > > VmSize: 2326912 kB > > > VmLck: 0 kB > > > VmPin: 0 kB > > > VmHWM: 1843468 kB > > > VmRSS: 1843468 kB > > > VmData: 1987020 kB > > > VmStk: 136 kB > > > VmExe: 80 kB > > > VmLib: 15592 kB > > > VmPTE: 4164 kB > > > VmSwap: 524 kB > > > Threads: 3 > > > SigQ: 0/62970 > > > SigPnd: 0000000000000000 > > > ShdPnd: 0000000000000000 > > > SigBlk: 0000000000000000 > > > SigIgn: 0000000000381000 > > > SigCgt: 0000000180004a43 > > > CapInh: 0000000000000000 > > > CapPrm: 0000000000000000 > > > CapEff: 0000000000000000 > > > CapBnd: 0000001fffffffff > > > Seccomp: 0 > > > Cpus_allowed: 1 > > > Cpus_allowed_list: 0 > > > Mems_allowed: 1 > > > Mems_allowed_list: 0 > > > voluntary_ctxt_switches: 12348713 > > > nonvoluntary_ctxt_switches: 4858656 > > > > Have you tried interpreting what those numbers actually mean? This might > > help: http://elinux.org/Runtime_Memory_Measurement > > > > Note that our SHM usage can cause virtual memory size look large, and > > this is a red herring. > > I don't know if I read the output correctly, it looks like PulseAudio > consumes nearly 2 gigs of memory? Can SHM alone cause that? Jeez, that is totally my bad for missing that. > Thomas, you could try running pulseaudio in valgrind. The command to do > that: > > valgrind --leak-check=full pulseaudio --realtime=no > > To get a leak report, quit pulseaudio with "pactl exit". > > --realtime=no is there because otherwise, at least on my machine, > pulseaudio gets easily killed due to excessive cpu use in realtime mode. > (That sounds like a bug, btw - shouldn't rtkit just demote the > scheduling mode back to normal, not outright kill pulseaudio?) > > Getting useful reports probably requires installing debug symbols for > pulseaudio first. > > I tried valgrind today myself (which I do way too seldomly), and I found > one memory leak in module-card-restore, which gets triggered when > changing card profiles. I pushed a fix for that to master. There's still > one memory leak in alsa-lib, which I expect to be triggered once per > loaded instance of module-alsa-card, so it's not very serious. I didn't > bother tracking down the bug in alsa-lib. If you have the it handy, can you dump the trace somewhere on bugzilla so we don't lose track? -- Arun
