Memory Leak with alsa driver

MR
MÅrîØ Raƒƒin
Fri, Jan 28, 2022 5:24 PM

Dear All,
I am debugging an application which exploit the pjsip stack.
I noticed a memory leak when using the alsa driver since each time I open and close the audio, pmap shows and increment on the user memory (4-12 KB each time).

Apparently this increment is in the heap region:

20608:  /home/root/easysip
Address  Kbytes    RSS  Dirty Mode  Mapping
00010000    1324    1324      28 r-x-- /home/root/easysip
0016a000      4      4      4 r---- /home/root/easysip
0016b000      20      20      16 rw--- /home/root/easysip
00170000    524    464    464 rw---  [ anon ]  <--------increment on this area
b09da000      4      0      0 -----  [ anon ]
b09db000    8192      8      8 rw---  [ anon ]
b39d8000      4      0      0 -----  [ anon ]
b39d9000    8192      16      16 rw---  [ anon ]
b41d9000      4      0      0 -----  [ anon ]
b41da000    8192      16      16 rw---  [ anon ]
b49da000      4      0      0 -----  [ anon ]
b49db000    8192      12      12 rw---  [ anon ]
....
b549b000    332    332      0 r-x-- /usr/lib/pulseaudio/libpulsecommon-12.2.so
b54ee000      64      0      0 ----- /usr/lib/pulseaudio/libpulsecommon-12.2.so
b54fe000      4      4      4 r---- /usr/lib/pulseaudio/libpulsecommon-12.2.so
b54ff000      4      4      4 rw--- /usr/lib/pulseaudio/libpulsecommon-12.2.so
b5500000    952    836    836 rw---  [ anon ] <--------then increment on this area
b55ee000      72      0      0 -----  [ anon ]
...

I have spent 10 day looking for a trouble in the code which manages the ALSA but everything looks fine.
In the code there aren't malloc or calloc, all the memory is managed by the pj_pool and the pools used during the audio stream are released.

I noticed that the first 5/6 times I open ond close the audio, the memory does not grow, then it starts to increase. This behaviour make me think to a memory pool which first uses its allocated space and then start allocating more space.

However, the pj_pool_factory_dump() shows that the pools size is stable and there are not pools growing. I use a single pool factory

The only functions which allocate ram outside the pj_pools are snd_pcm_open() which is followed by snd_pcm_close() and
snd_pcm_(hw|sw)params_malloc() which is always followed by the snd_pcm(hw|sw)_params_free()

The memory area where the pools are allocated is the same I see growing with pmap.
I wonder wether there is some wrong use of the memory pools which could cause this kind of problems (for instance, what happen if I create two time a pool with the same name? however I didn't found this in my code ).

Is it possible that when the memory of the pool is released, for some reason the system retain it?

Every idea that could help me to debug this issue will be very appreciated.

Thank you.
Best regards.
Mario

--

Mario Raffin
/Development Engineer/
Ermes Elettronica s.r.l.
via Treviso, 36
31020 San Vendemiano (TV) Italy
Mail: raffin@ermes-cctv.com

Dear All, I am debugging an application which exploit the pjsip stack. I noticed a memory leak when using the alsa driver since each time I open and close the audio, pmap shows and increment on the user memory (4-12 KB each time). Apparently this increment is in the heap region: 20608: /home/root/easysip Address Kbytes RSS Dirty Mode Mapping 00010000 1324 1324 28 r-x-- /home/root/easysip 0016a000 4 4 4 r---- /home/root/easysip 0016b000 20 20 16 rw--- /home/root/easysip 00170000 524 464 464 rw--- [ anon ] <--------increment on this area b09da000 4 0 0 ----- [ anon ] b09db000 8192 8 8 rw--- [ anon ] b39d8000 4 0 0 ----- [ anon ] b39d9000 8192 16 16 rw--- [ anon ] b41d9000 4 0 0 ----- [ anon ] b41da000 8192 16 16 rw--- [ anon ] b49da000 4 0 0 ----- [ anon ] b49db000 8192 12 12 rw--- [ anon ] .... b549b000 332 332 0 r-x-- /usr/lib/pulseaudio/libpulsecommon-12.2.so b54ee000 64 0 0 ----- /usr/lib/pulseaudio/libpulsecommon-12.2.so b54fe000 4 4 4 r---- /usr/lib/pulseaudio/libpulsecommon-12.2.so b54ff000 4 4 4 rw--- /usr/lib/pulseaudio/libpulsecommon-12.2.so b5500000 952 836 836 rw--- [ anon ] <--------then increment on this area b55ee000 72 0 0 ----- [ anon ] ... I have spent 10 day looking for a trouble in the code which manages the ALSA but everything looks fine. In the code there aren't malloc or calloc, all the memory is managed by the pj_pool and the pools used during the audio stream are released. I noticed that the first 5/6 times I open ond close the audio, the memory does not grow, then it starts to increase. This behaviour make me think to a memory pool which first uses its allocated space and then start allocating more space. However, the pj_pool_factory_dump() shows that the pools size is stable and there are not pools growing. I use a single pool factory The only functions which allocate ram outside the pj_pools are snd_pcm_open() which is followed by snd_pcm_close() and snd_pcm_(hw|sw)_params_malloc() which is always followed by the snd_pcm_(hw|sw)_params_free() The memory area where the pools are allocated is the same I see growing with pmap. I wonder wether there is some wrong use of the memory pools which could cause this kind of problems (for instance, what happen if I create two time a pool with the same name? however I didn't found this in my code ). Is it possible that when the memory of the pool is released, for some reason the system retain it? Every idea that could help me to debug this issue will be very appreciated. Thank you. Best regards. Mario -- *Mario Raffin* /Development Engineer/ Ermes Elettronica s.r.l. via Treviso, 36 31020 San Vendemiano (TV) Italy Mail: raffin@ermes-cctv.com
AW
Andreas Wehrmann
Fri, Jan 28, 2022 10:21 PM

Am 28.01.2022 um 18:24 schrieb MÅrîØ Raƒƒin:

Dear All,
I am debugging an application which exploit the pjsip stack.
I noticed a memory leak when using the alsa driver since each time I open and close the audio, pmap shows and increment on the user memory (4-12 KB each time).

Apparently this increment is in the heap region:

20608:  /home/root/easysip
Address  Kbytes    RSS  Dirty Mode  Mapping
00010000    1324    1324      28 r-x-- /home/root/easysip
0016a000      4      4      4 r---- /home/root/easysip
0016b000      20      20      16 rw--- /home/root/easysip
00170000    524    464    464 rw---  [ anon ]  <--------increment on this area
b09da000      4      0      0 -----  [ anon ]
b09db000    8192      8      8 rw---  [ anon ]
b39d8000      4      0      0 -----  [ anon ]
b39d9000    8192      16      16 rw---  [ anon ]
b41d9000      4      0      0 -----  [ anon ]
b41da000    8192      16      16 rw---  [ anon ]
b49da000      4      0      0 -----  [ anon ]
b49db000    8192      12      12 rw---  [ anon ]
....
b549b000    332    332      0 r-x-- /usr/lib/pulseaudio/libpulsecommon-12.2.so
b54ee000      64      0      0 ----- /usr/lib/pulseaudio/libpulsecommon-12.2.so
b54fe000      4      4      4 r---- /usr/lib/pulseaudio/libpulsecommon-12.2.so
b54ff000      4      4      4 rw--- /usr/lib/pulseaudio/libpulsecommon-12.2.so
b5500000    952    836    836 rw---  [ anon ] <--------then increment on this area
b55ee000      72      0      0 -----  [ anon ]
...

I have spent 10 day looking for a trouble in the code which manages the ALSA but everything looks fine.
In the code there aren't malloc or calloc, all the memory is managed by the pj_pool and the pools used during the audio stream are released.

I noticed that the first 5/6 times I open ond close the audio, the memory does not grow, then it starts to increase. This behaviour make me think to a memory pool which first uses its allocated space and then start allocating more space.

However, the pj_pool_factory_dump() shows that the pools size is stable and there are not pools growing. I use a single pool factory

The only functions which allocate ram outside the pj_pools are snd_pcm_open() which is followed by snd_pcm_close() and
snd_pcm_(hw|sw)params_malloc() which is always followed by the snd_pcm(hw|sw)_params_free()

The memory area where the pools are allocated is the same I see growing with pmap.
I wonder wether there is some wrong use of the memory pools which could cause this kind of problems (for instance, what happen if I create two time a pool with the same name? however I didn't found this in my code ).

Is it possible that when the memory of the pool is released, for some reason the system retain it?

Every idea that could help me to debug this issue will be very appreciated.

Hey there,

last time I had problems with increasing memory usage, it was because of
memory fragmentation.
This can prevent the allocator from releasing chunks of memory back to
the OS.
I'm not sure whether you are dealing with the same issue here; when I
investigated the issue,
I added the number of blocks held by each pool to the output when
dumping the pools which confirmed
that even though the amount of memory allocated was low, a large
quantity of blocks was being held.

Take a look here, it may give you some ideas; it took me quite a long
time to figure out I was dealing with a fragmentation issue:
https://github.com/pjsip/pjproject/issues/2389

In the back of my head I remember valgrind giving me warnings about the
ALSA API,
but I think the "leaks" it reported only affected library init/deinit....

All the best,
Andreas

Am 28.01.2022 um 18:24 schrieb MÅrîØ Raƒƒin: > Dear All, > I am debugging an application which exploit the pjsip stack. > I noticed a memory leak when using the alsa driver since each time I open and close the audio, pmap shows and increment on the user memory (4-12 KB each time). > > Apparently this increment is in the heap region: > > 20608: /home/root/easysip > Address Kbytes RSS Dirty Mode Mapping > 00010000 1324 1324 28 r-x-- /home/root/easysip > 0016a000 4 4 4 r---- /home/root/easysip > 0016b000 20 20 16 rw--- /home/root/easysip > 00170000 524 464 464 rw--- [ anon ] <--------increment on this area > b09da000 4 0 0 ----- [ anon ] > b09db000 8192 8 8 rw--- [ anon ] > b39d8000 4 0 0 ----- [ anon ] > b39d9000 8192 16 16 rw--- [ anon ] > b41d9000 4 0 0 ----- [ anon ] > b41da000 8192 16 16 rw--- [ anon ] > b49da000 4 0 0 ----- [ anon ] > b49db000 8192 12 12 rw--- [ anon ] > .... > b549b000 332 332 0 r-x-- /usr/lib/pulseaudio/libpulsecommon-12.2.so > b54ee000 64 0 0 ----- /usr/lib/pulseaudio/libpulsecommon-12.2.so > b54fe000 4 4 4 r---- /usr/lib/pulseaudio/libpulsecommon-12.2.so > b54ff000 4 4 4 rw--- /usr/lib/pulseaudio/libpulsecommon-12.2.so > b5500000 952 836 836 rw--- [ anon ] <--------then increment on this area > b55ee000 72 0 0 ----- [ anon ] > ... > > I have spent 10 day looking for a trouble in the code which manages the ALSA but everything looks fine. > In the code there aren't malloc or calloc, all the memory is managed by the pj_pool and the pools used during the audio stream are released. > > I noticed that the first 5/6 times I open ond close the audio, the memory does not grow, then it starts to increase. This behaviour make me think to a memory pool which first uses its allocated space and then start allocating more space. > > However, the pj_pool_factory_dump() shows that the pools size is stable and there are not pools growing. I use a single pool factory > > The only functions which allocate ram outside the pj_pools are snd_pcm_open() which is followed by snd_pcm_close() and > snd_pcm_(hw|sw)_params_malloc() which is always followed by the snd_pcm_(hw|sw)_params_free() > > The memory area where the pools are allocated is the same I see growing with pmap. > I wonder wether there is some wrong use of the memory pools which could cause this kind of problems (for instance, what happen if I create two time a pool with the same name? however I didn't found this in my code ). > > Is it possible that when the memory of the pool is released, for some reason the system retain it? > > Every idea that could help me to debug this issue will be very appreciated. Hey there, last time I had problems with increasing memory usage, it was because of memory fragmentation. This can prevent the allocator from releasing chunks of memory back to the OS. I'm not sure whether you are dealing with the same issue here; when I investigated the issue, I added the number of blocks held by each pool to the output when dumping the pools which confirmed that even though the amount of memory allocated was low, a large quantity of blocks was being held. Take a look here, it may give you some ideas; it took me quite a long time to figure out I was dealing with a fragmentation issue: https://github.com/pjsip/pjproject/issues/2389 In the back of my head I remember valgrind giving me warnings about the ALSA API, but I think the "leaks" it reported only affected library init/deinit.... All the best, Andreas