WenKui Liang wrote:
> Hello Steve,
> for iax_send() / iax_frame_free() --- Yes, I'd tested for several
> and it look better than before when application running
> iaxc_refresh_registrations() only.
> but program still leaking memory in call session establishment.
> for iax_event_free() --- just changing one place.
> iax_event_new / iax_event_free() pair with something like
> could be great help on memory leaking detection.
> about add-in iaxc_register_cancel() with same parameter as
> to remove specific registration session from registrations.
> any comment?
Yes, it seems like a good idea. I don't use registrations, but I
imagine that unregistering them would be a good idea. If someone wants
to write it, I'd make tha API similar to
iaxc_play_sound/iaxc_stop_sound, where the library returns a
"registration ID" when you start a registration, and you can use that to
cancel/unregister/stop registering (or whatever you call it).
So, you'd change iaxc_register to return the ID (int), and then make int
iaxc_unregister(int) cancel the registration.
> wkliang @ taipei.
> ----- Original Message ----- From: "Steve Kann" <stevek@...>
> To: "WenKui Liang" <wenkui.liang@...>
> Cc: "Iaxclient-Devel" <iaxclient-devel@...>
> Sent: Tuesday, April 26, 2005 3:29 AM
> Subject: Re: A patch for libiax2/src/iax.c memory leak
>> WenKui Liang wrote:
>>> Hello Steve,
>>> Please examine attachment for a patch to solve memory leak occur
>>> in libiax2/src/iax.c
>>> mainly in iax_send() didn't call iax_frame_free() while now flag
>>> on ( not use stack as buffer )
>> This is the part of the patch you're talking about:
>> --- iax.c-orig 2005-04-13 07:36:26.000000000 +0800
>> +++ iax.c 2005-04-24 14:42:14.000000000 +0800
>> @@ -1038,6 +1038,8 @@
>> fr->retries = -1;
>> res = iax_xmit_frame(fr);
>> + if( !now && fr!=NULL )
>> + iax_frame_free( fr );
>> return res;
>> It seems that this is OK, because the frame is duplicated, and then
>> iax_reliable_xmit() is called on it, which seems to duplicate the
>> frame itself..
>> Have you thoroughly tested this change?
>> @@ -2465,7 +2467,7 @@
>> case IAX_COMMAND_REGAUTH:
>> session->secret, e->ies.challenge, e->ies.authmethods);
>> - free(e);
>> + iax_event_free(e);
>> e = NULL;
>> case IAX_COMMAND_REGREJ:
>> This is fine, because iax_event_free == free, really, so it's just a
>> style change, but the rest of this function calls iax_event_free()
>>> IMO, iax.c need some re-structuring to avoid error prone condition.
>> Yes, it's pretty messy. But, it's not really my code: It's just a
>> copy of digium's libiax2. I would want any changes we make to this
>> to periodically get re-merged back upstream to digium; This means we
>> must avoid breaking the API in any way, and it also means any
>> copyrightable (i.e. anything non-trivial like typo-fixes), needs to
>> be disclaimed.
>> I would like to see a clean re-implementation of libiax2 someday (as
>> would, perhaps, phone vendors and such). Also, there's several IAX2
>> features that are in chan_iax2 on the asterisk side, which are not yet
> in libiax2:
>> 1) Trunk mode. (this is even somewhat useful for clients, so you can
>> send interleaved frames, etc.)
>> 2) The new codec negotiation stuff.