memory leaks

memory leaks

[Lee Revell]

WHen reloading ALSA modules I got this message:

ALSA sound/core/memory.c:71: Not freed snd_alloc_kmalloc = 1728
ALSA sound/core/memory.c:80: kmalloc(164) from dc8506f9 not freed
ALSA sound/core/memory.c:80: kmalloc(268) from dc850606 not freed
ALSA sound/core/memory.c:80: kmalloc(164) from dc8506f9 not freed
ALSA sound/core/memory.c:80: kmalloc(268) from dc850606 not freed
ALSA sound/core/memory.c:80: kmalloc(164) from dc8506f9 not freed
ALSA sound/core/memory.c:80: kmalloc(268) from dc850606 not freed
ALSA sound/core/memory.c:80: kmalloc(164) from dc8506f9 not freed
ALSA sound/core/memory.c:80: kmalloc(268) from dc850606 not freed

These are the closest symbols:

dc850590 t snd_hwdep_ioctl      [snd_hwdep]
dc850630 t snd_hwdep_mmap       [snd_hwdep]
dc850660 t snd_hwdep_control_ioctl      [snd_hwdep]

AFAICT this means the leaks are in snd_hwdep_ioctl and control_ioctl.

Lee




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: memory leaks

[Clemens Ladisch]

Lee Revell wrote:
> WHen reloading ALSA modules I got this message:
> ALSA sound/core/memory.c:80: kmalloc(164) from dc8506f9 not freed
> ALSA sound/core/memory.c:80: kmalloc(268) from dc850606 not freed
>
> These are the closest symbols:
>
> dc850590 t snd_hwdep_ioctl      [snd_hwdep]
> dc850630 t snd_hwdep_mmap       [snd_hwdep]
> dc850660 t snd_hwdep_control_ioctl      [snd_hwdep]
>
> AFAICT this means the leaks are in snd_hwdep_ioctl and control_ioctl.

These functions don't directly allocate memory, the leak is probably
in some driver function.  What hwdep device is this?


HTH
Clemens



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: memory leaks

[Lee Revell]

On Wed, 2005-07-06 at 10:06 +0200, Clemens Ladisch wrote:
> Lee Revell wrote:
> > WHen reloading ALSA modules I got this message:
> > ALSA sound/core/memory.c:80: kmalloc(164) from dc8506f9 not freed
> > ALSA sound/core/memory.c:80: kmalloc(268) from dc850606 not freed
> >
> > These are the closest symbols:
> >
> > dc850590 t snd_hwdep_ioctl      [snd_hwdep]
> > dc850630 t snd_hwdep_mmap       [snd_hwdep]
> > dc850660 t snd_hwdep_control_ioctl      [snd_hwdep]
> >
> > AFAICT this means the leaks are in snd_hwdep_ioctl and control_ioctl.
> 
> These functions don't directly allocate memory, the leak is probably
> in some driver function.  What hwdep device is this?

snd_emu10k1_synth I think.

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Memory leaks

[Ivan Gyurdiev]

Here's a couple of memory leaks, if anyone wants to investigate. If not, 
I'll take a look at them eventually. The first one is my fault. The 
second one isn't. The main binary I used doesn't bother freeing things, 
but I think valgrind is smart enough to recognize that, and those are 
real leaks.

==10639== 8 bytes in 2 blocks are definitely lost in loss record 4 of 74
==10639==    at 0x1B9017F2: malloc (vg_replace_malloc.c:149)
==10639==    by 0x805313F: sepol_user_get_roles (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)
==10639==    by 0x80493D9: main (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)
==10639==
==10639==
==10639== 64 (32 direct, 32 indirect) bytes in 2 blocks are definitely 
lost in loss record 21 of 74
==10639==    at 0x1B9017F2: malloc (vg_replace_malloc.c:149)
==10639==    by 0x805C46A: ebitmap_read (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)
==10639==    by 0x804EA64: mls_read_range_helper (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)
==10639==    by 0x805044D: user_read (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)
==10639==    by 0x8051923: policydb_read (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)
==10639==    by 0x8051F50: policydb_from_image (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)
==10639==    by 0x804AFE9: sepol_genusers (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)
==10639==    by 0x8049291: main (in 
/home/phantom/rpmbuild/BUILD/test.mls/test)




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Memory leaks

[Ivan Gyurdiev]

Ivan Gyurdiev wrote:

> Here's a couple of memory leaks, if anyone wants to investigate. If 
> not, I'll take a look at them eventually. The first one is my fault. 
> The second one isn't. The main binary I used doesn't bother freeing 
> things, but I think valgrind is smart enough to recognize that, and 
> those are real leaks.
>
Disregard this, I am giving valgrind too much credit....adding free() in 
main where appropriate fixes those non-leaks.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.