Also note that switch_event_fire() will internally free the event once the handlers have processed it.
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mr...@avgs.ca On 2010-06-29, at 3:00 PM, Anthony Minessale wrote: > This is mostly true > minor corrections below: > > most functions who return an opaque pointer with no sign of a session or pool > are expected to be destroyed. > The rule of thumb is if they take an double pointer or return a pointer to > something opaque or a string it's a safe assumption it needs to be destroyed > either by looking for a corresponding destroy function or regular > switch_safe_free on strings. > > > On Tue, Jun 29, 2010 at 8:36 AM, Steven Ayre <stevea...@gmail.com> wrote: > 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_snprintf does not need free it takes a buffer and memory size as > args like real snprintf > > - 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). > > switch_channel_expand_variables only uses dynamic memory if something was > expanded in the string. If it does not expand anything it returns the > original input pointer so you can tell if you need to free it if the output > != input string. > > > > > -Steve > > > On 29 June 2010 06:19, Paul Li <plite2...@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@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > > > > -- > Anthony Minessale II > > FreeSWITCH http://www.freeswitch.org/ > ClueCon http://www.cluecon.com/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_miness...@hotmail.com > GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:8...@conference.freeswitch.org > googletalk:conf+...@conference.freeswitch.org > pstn:+19193869900 > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
