[Openal] Leaking Buffer data.

[Adam D. Moss]

J. Valenzuela wrote:
> Weird. 

That's what I thought!

 > Obviously it would help if we had a teeny little tiny minimal
> test case.

Yeah.  It looks like that's going to have to be the case.  I've
been putting it off because some small changes to timing and magic
numbers can make the problem magically [dis]appear, but now that
a linux-based tester also sees the app leak on his mega-fast system
it looks like a minimal testcase might actually stand a chance of
showing the problem (which is good).

I was hoping that either:
1) I was doing something head-smackingly stupid that would become
obvious from my 1000th re-read of my code, or
2) I was running into a totally wacked bug specific to my libc's
threading/heap management, or
3) I was making some kind of obvious OpenAL mis-think that would be
obvious from the description in my emails, or
4) I could 'find the bug' myself by getting gory to the elbows
in the OpenAL source, and claim fame and fortune with a fix.

I've been concentrating on #4 without success but I'll give it the
rest of this afternoon before I switch effort over to a from-scratch test-case.

Thanks,
--adam

> On Feb 6, 2004, at 9:43 AM, Adam D. Moss wrote:
> 
>> Hi!
>>
>> In short, no.
>>
>> I only use bids generated by alGenBuffers(), which I generate
>> just before creating the buffer (which is then queued on a source;
>> buffers aren't shared between sources or queued multiple times).
>> When a buffers is taken off the queue its bid is immediately
>> alDeleteBuffers()'d.
>>
>> So, in theory a bid could implicitly be reused over the lifespan of
>> the program just because alGenBuffers() returns it again after it
>> having been created+used+deleted once already.
>>
>> But in practise I see the leak long before bids start to actually
>> be reused.
>>
>> Thanks,
>> --Adam
>>
>> J. Valenzuela wrote:
>>
>>> is alBufferData being called over and over again with the same bids?
>>> -- 
>>> jv
>>> On Feb 6, 2004, at 2:20 AM, Adam D. Moss wrote:
>>>
>>>> We're fairly massively leaking memory over time from our sound system
>>>> on Linux.  This only seems to occur on a sound (re-)start, whereupon
>>>> the data backing the FIRST new buffer in a source's queue may be kept
>>>> hanging around forever.
>>>>
>>>> ==29696== 15903590 bytes in 979 blocks are still reachable in loss 
>>>> record 204 of 204
>>>> ==29696==    at 0x40021F77: malloc (vg_replace_malloc.c:160)
>>>> ==29696==    by 0x4030D4E4: alBufferData (al_buffer.c:684)
>>>> ==29696==    by 0x80AB2FD: zas_queue_audiodata (al_audio.c:795)
>>>> ==29696==    by 0x80AB9C8: process_nonprocessing_zas (al_audio.c:936)
>>>> ==29696==    by 0x80ABA74: process_slotid (al_audio.c:960)
>>>> ==29696==    by 0x80ACC82: zal_process_activelist (al_audio.c:1335)
>>>> ==29696==    by 0x80A8311: zeit_process_audio (audio.c:455)
>>>> ==29696==    by 0x80507D9: doGameFrame (mainwork.c:173)
>>>> ==29696==    by 0x804EFB6: game_main_loop (main.c:887)
>>>> ==29696==    by 0x804F504: main (main.c:1079)
>>>>
>>>> Four wacky things:
>>>> * No testers can reproduce this on (Creative) win32 OpenAL
>>>> * Doesn't always occur on Linux depending on buffer sizes, buffer 
>>>> queue size,
>>>> and framerate(-> thus how empty the queue actually gets?)
>>>> * Instrumenting buffer creation and buffer deletion at the app level
>>>> shows that we really do (try to!) delete as many buffers as we create,
>>>> and the bIDs look good.
>>>> * Shutting down OpenAL does free this data, so it's not truly 'leaked'
>>>> (but this might just be a positive artifact of, say, a thread-local
>>>> heap being freed wholesale when OpenAL's internal mixing thread is
>>>> deleted).
>>>>
>>>> Any insight/suggestions/questions welcome!
>>>>
>>>> Thanks,
>>>> --Adam
>>>> _______________________________________________
>>>> openal mailing list
>>>> openal at opensource.creative.com
>>>> http://opensource.creative.com/mailman/listinfo/openal
>>>>
>>
>>
>> -- 
>> Adam D. Moss   . ,,^^   adam at gimp.org   http://www.foxbox.org/   co:3
>> "At this point the rocket becomes engorged with astronauts."
>> _______________________________________________
>> openal mailing list
>> openal at opensource.creative.com
>> http://opensource.creative.com/mailman/listinfo/openal
>>
> 
> 


-- 
Adam D. Moss   . ,,^^   adam at gimp.org   http://www.foxbox.org/   co:3
"At this point the rocket becomes engorged with astronauts."