[Freeswitch-dev] Newbie question on switch_event_dup() and memory alloc/free in general

[Steven Ayre]

memory free is sometimes used, but often not needed because of memory pools.

Sessions and channels have their own memory pool, anything creating memory
for one of them will not need freeing as when the session ends the entire
pool is destroyed. Similarly many modules have a pool which lasts for the
lifetime of the module.

There are other functions which will need freeing though... I suggest that
you use switch_safe_free() to be consistent with the rest of freeswitch.
It's just a wrapper on free which doesn't call it for a null pointer
(avoiding a segfault on some systems).

Some examples:
- switch_snprintf & switch_mprintf needs a free (is given no pool or object
with a pool)
- switch_core_session_sprintf does not need a free (it's given a session,
memory is allocated from its pool)
- switch_channel_expand_variables sometimes needs free, sometimes doesn't
(you give it a buffer, if it's large enough its used and returned otherwise
it creates a new one, so you should check the return value against the
buffer to avoid either freeing a const char or a buffer twice).

-Steve

On 29 June 2010 06:19, Paul Li <plite2012 at gmail.com> wrote:

> A lot of FreeSwitch core APIs, such as switch_event_dup(switch_event_t
> **event, switch_event_t *todup), returns a pointer to an allocated
> memory chunk, should the caller always releases that memory chunk by
> calling a proper API, such as switch_event_destroy(switch_event_t
> **event)?
>
> I could not find any documentation to detail the general rule
> regarding memory allocation/free when using the core APIs.
>
> Thank you for your attention!
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100629/2237eb35/attachment.html