Hi, hound should not need dmamem_unmap_anonymous. The playback buffer does not need to reside in DMA memory, that's driver's responsibility.
You're right though, that it leaks the shared memory, it's due to missing unmap call in release_buffer() (audio_device.c:375) Not sure how this ever worked, but generally there is around 200kB of available DMA memory, that limits sb16 to 3 allocations before it runs out of memory and hangs (waits endlessly in kernel). This forced me to include ugly solution to dma_unmap, that was included in the original merge. It fixed the problem of 3 playback limit, so I'm not sure what memory does the shared buffer occupy. I'll try to have a look at the other leaks, but probably won't have much time until spring break (and there is the EHCI hw fail that I need to squash too). My first guess would be that hound leaks client received data. regards, Jan On Mon, Feb 10, 2014 at 5:14 AM, Jakub Jermar <[email protected]> wrote: > Hello, > > there seems to be a memory leak in the HelenOS sound daemon (hound). > After fixing (sort of *) the missing dmamem_unmap_anonymous(), there > still appear to be at least two leaks in this server. The symptoms can > be seen by running e.g. top and playing a short .wav sample repeatedly > using wavplay. As the sample is played over and over again, the amount > of available memory will gradually decrease and the memory will not be > returned back to the system unless hound is killed. This is what I have > figured out so far: > > - hound for some reason does not destroy the shared anonymou DMA area, > which results in 16 leaked pages (64 KiB) for each iteration (at least > in the case of my .wav sample). > > - there must be yet another leak because each iteration consumes much > more memory than those 64 KiB leaked in DMA memory > > Jakub > > * Now there is dmamem_unmap_anonymous(), but there is also a newly > introduced race that makes it possible for the dmamem memory to leak in > rare circumstances. I am trying to figure out how to get rid of this race. > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
