Jeremy A wrote:
> Hello,
>
> The simplest workaround is simply to always code:
>
> sipxCallAudioPlayFileStop ( _hCall ); // Somehow required for
> correct operation
> if (sipxCallAudioPlayFileStart( _hCall, _szFile, loop, local, remote )
> == SIPX_RESULT_SUCCESS)
> {
> ...
Just use this hack until it's really fixed.
>
> Is this a (new) bug?
>
> I have also run valgrind on my application and so there seem to be a
> number of memory management problems within the api.
>
> What is the memory safety of the present release of the API?
>
There are some dynamic singletons that might be detected as memory leaks
by valgrind. And there are also some real memory leaks, but many have
already been fixed. I'm rewriting sipXtapi, and when it's finished, I
hope there will be no memory leaks in it at all. That doesn't include
other libraries like calllib, medialib or tacklib. I will fix the
remaining leaks after I'm done with sipXtapi. I hope that Alexander will
find time to get rid of dynamic singletons in medialib at some point
(either via the safe static init method or by moving them to class).
Jaro
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
