Newbie question on switch_event_dup() and memory alloc/free in general
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!
Yes, you must call destroy on the object if it has it. On Tue, Jun 29, 2010 at 12:19 AM, Paul Li <plite2012@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
-- -Rupa
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@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
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 <steveayre@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 <plite2012@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_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
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 mrene@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 <steveayre@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 <plite2012@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_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@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
yes any functions that take pointers to pointers and leave you with null will indicate you don't have to do anything. On Tue, Jun 29, 2010 at 2:23 PM, Mathieu Rene <mrene_lists@avgs.ca> wrote:
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 mrene@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 <steveayre@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 <plite2012@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_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
participants (5)
-
Anthony Minessale
-
Mathieu Rene
-
Paul Li
-
Rupa Schomaker
-
Steven Ayre