Hi Takashi,

Thanks for your replay.

2011/8/2 Takashi Iwai tiwai@suse.de:

At Sat, 30 Jul 2011 11:15:41 +0800, Scott Jiang wrote:

...

Hi all,

I found there is a memory leak about 128K every time in linux-2.6.34, but it doesn't exist in linux-3.0.

What does "every time" mean, and how did you detect it?

That means using aplay command every time. Actually the customer told us if you didn't close the handle(in your app), there was no memory leak. If you didn't write data, only opened and closed the handle, there was no memory leak.

...

If I use mmap ops in driver the bug will come out, while use copy ops no memory leak. This driver is based on asoc. I tested with aplay to play a wav file. Because there is a lot of changes in ALSA between 2.6.34 and 3.0, so can anyone who familiar with the change history tell me which patch has solved this bug?

I don't remember such a bug fix, so wonder whether it's the ALSA core part or a driver-specific issue.  You can try other driver (e.g. snd-dummy) to see whether the problem happens.

My driver based on asoc, I am not sure it is caused by asoc or alsa core. I have tried to search the change log to find something but nobody mentioned this just as your reply. I tested these drivers on blackfin bf537 and I am sure I didn't modify audio driver and the bug disappears with the alsa update. Then I modified drivers using mmap ops to copy ops, they works fine, no memory leak. But dmix plug can't be used. One more thing, 128K is a big buffer and audio device driver only allocate dma at such size. But dma size can't be seen by free command on blackfin. So I think the framework allocate the buffer using kmalloc or get_free_pages but forget to release. If codec only has one channel such as ad73311, the memory leak size is 64K.

Scott