[Tremor] Question to memory leaks in Tremor

[Frédéric Bastien]

Hi,

I haven't tested the case of playing multiple file one after the other. 
So I didn't "hit" very strongly this difficulty.

One thing I remember from other past email or reading about tremor, is
that the implementation of the memory function of some compiler are not
working properly or not as supported for the tremor code. Also, their is
many variant of malloc and not all compiler support all of them. Did you
change the version of the malloc? Did your compiler complained about
nonexistent function that you changed?

One of them allocate space (on the stack I think) and release it
automatically when the function that made the allocation return. But your
leak is in the heap and not the stack. So if you changed those function, 
you must release this memory yourself.

So do you changed some function or the compiler complained about
nonexistent function?

Frédéric Bastien



> Hello Frédéric,
>
> I tried out your patch in the Tremor code version I am working with.
> Things have improved a little bit. But the heap still isn't cleared
> completely after having finsihed playback of one file. So in my Code
> Version there seem to be other allocated memory segmnets, which are not
> freed correctly.
> I have overcome my problem by using a separate heap for each OggVorbis
> Channel. That is possible on the Blackfin DSP I am working with. And
> luckily I have enough memory space on the platform I am working with.
> After playback I clear the channel specific heap by a special function of
> that DSP to avoid heap overflows.
>
> Thanks for your help and best regards,
> Markus
>
> -----Ursprüngliche Nachricht-----
> Von: Frédéric Bastien [mailto:nouiz at nouiz.org]
> Gesendet: Mittwoch, 20. September 2006 17:01
> An: Lorber, Markus
> Betreff: Re: AW: [Tremor] Question to memory leaks in Tremor
>
> Does anybody know who can commit to the svn, so that the patch is
> present for everybody?
>
> thanks
>
> Frédéric Bastien
>
> Lorber, Markus wrote:
>> Hello Frèdèric,
>>
>> As I am working with the lowmem branch, I could try out your patch!
>> Thanks a lot for your information!
>>
>> Best,
>> Markus
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Frédéric Bastien [mailto:nouiz at nouiz.org]
>> Gesendet: Mittwoch, 20. September 2006 16:35
>> An: Lorber, Markus
>> Betreff: Re: [Tremor] Question to memory leaks in Tremor
>>
>> Hi,
>>
>> I have send a patch to the mailling list to solve the memory leak. I'm
>> not sur it was for witch branch of Tremor, but I think it was for
>> lowmem. You could use it to make the appropriate correction or if you
>> use another branch to help you find out. I don't know if somebody made a
>> commit of my patch as I can't do a commit.
>>
>> The email for the patch is here:
>> http://lists.xiph.org/pipermail/tremor/2004-October/001112.html
>>
>> Frédéric Bastien
>>
>> Lorber, Markus wrote:
>>> Hello,
>>>
>>> I am working with Tremor (codec source as of date 2002 09 02, version
>>> 1.0.0) on a Blackfin DSP. Basically my implementaion works but there
>>> remains a problem with memory leaks. If I playback an OggVorbis File
>>> several times (were I always call ov_open_callbacks(),..., ov_read(),
>>> ov_clear() similar to the example code), it ends up in a DSP-exception
>>> because of a heap overflow.
>>>
>>> I found some hints in the Tremor forum that there exists a memory leak
>>> problem. Is that correct or could it be that I do a wrong usage of
>>> the API-functions (e.g. ov_clear())?
>>>
>>> I am planing to do a work-around by implementing a list, were each
>>> pointer allocated by malloc(), calloc(), realloc() is written to. Every
>>> free() (and if neccessary every realloc() ) would clear the
>>> corresponding pointer in the list. Finally after having finished an
>>> OggVorbis stream, I would do a free() on each pointer remaining after
>>> ov_clear() to clean up the heap.
>>>
>>> My question now is: Does enyone have suggestions for a better
>>> work-around or does a newer version of Tremor exist, which overcomes
>>> the memory leak problem?
>>>
>>> Thank you and best regards,
>>> Markus
>>>