Summary:	ASTERISK-21046: res_xmpp refcount issue
Reporter:	Marcello Ceschia (marcelloceschia)	Labels:
Date Opened:	2013-02-07 05:03:27.000-0600	Date Closed:	2013-02-14 15:49:17.000-0600
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	Resources/res_xmpp
Versions:	11.2.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	i386 Linux	Attachments:	( 0) refs.tar.gz
Description:	xmpp_client_reconnect does not release obj reference
Comments:	By: Matt Jordan (mjordan) 2013-02-14 06:35:16.323-0600 Your ref count log shows a large number of (+1) references to the object, but you'll note that the overall ref count on the object never increases: {noformat} 0xa38281c +1   res_xmpp.c:3432:xmpp_client_reconnect () [@1] 0xa38281c +1   res_xmpp.c:3432:xmpp_client_reconnect () [@1] 0xa38281c +1   res_xmpp.c:3432:xmpp_client_reconnect () [@1] 0xa38281c +1   res_xmpp.c:3432:xmpp_client_reconnect () [@1] 0xa38281c +1   res_xmpp.c:3432:xmpp_client_reconnect () [@1] 0xa38281c +1   res_xmpp.c:3432:xmpp_client_reconnect () [@1] 0xa38281c +1   res_xmpp.c:3432:xmpp_client_reconnect () [@1] 0xa38281c +1   res_xmpp.c:3432:xmpp_client_reconnect () [@1] {noformat} That's because this particular variable is being managed by {{RAII_VAR}}, which will automatically call {{ao2_cleanup}} when the variable loses scope in {{xmpp_client_reconnect}}. {{ao2_cleanup}} is defined in {{astobj2.h}}, so you'll need to enable ref count debugging there in order to see the ref count drops. Your log shows that the ref count drops to 0 when the module is unloaded: {noformat} 0xa38281c -1   res_xmpp.c:4263:unload_module () [@1] {noformat} I previously had thought there was a memory leak here, but that's actually not the case either. Is there a particular problem you're noticing? By: Marcello Ceschia (marcelloceschia) 2013-02-14 06:49:16.264-0600 I added {noformat} #define REF_DEBUG 1 {noformat} in include/asterisk/astobj2.h so it should debug all refcounts, does it? Should I get a destroy in log file? By: Matt Jordan (mjordan) 2013-02-14 06:51:01.458-0600 Yup. That will be a lot of them :-) As I just amended my comments... there is no memory leak here. Joshua Colp pointed out that the checking of the filter being NULL before attempting to create it would prevent any memory leak. That's what I get for Triaging issues before 8 AM :-) By: Marcello Ceschia (marcelloceschia) 2013-02-14 07:03:07.599-0600 I added the refs log file from /tmp. As you can see {noformat} cat refs | grep "xmpp_client_reconnect" 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] cat refs | grep "0x19d4778" 0x19d4778 =1   res_xmpp.c:585:xmpp_config_alloc () 0x19d4778 +1   config_options.c:424:apply_config () [@1] 0x19d4778 +1   res_xmpp.c:645:xmpp_config_post_apply () [@2] 0x19d4778 -1   res_xmpp.c:645:_dtor_cfg (ao2_cleanup) [@3] 0x19d4778 -1   config_options.c:556:aco_process_config (ao2_cleanup) [@2] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 +1   res_xmpp.c:4084:xmpp_show_clients () [@2] 0x19d4778 -1   res_xmpp.c:4084:_dtor_cfg (ao2_cleanup) [@3] 0x19d4778 +1   res_xmpp.c:4160:xmpp_show_buddies () [@2] 0x19d4778 -1   res_xmpp.c:4160:_dtor_cfg (ao2_cleanup) [@3] 0x19d4778 +1   res_xmpp.c:3968:xmpp_cli_create_collection () [@2] 0x19d4778 -1   res_xmpp.c:3968:_dtor_cfg (ao2_cleanup) [@3] 0x19d4778 +1   res_xmpp.c:3800:xmpp_cli_list_pubsub_nodes () [@2] 0x19d4778 -1   res_xmpp.c:3800:_dtor_cfg (ao2_cleanup) [@3] 0x19d4778 +1   res_xmpp.c:4008:xmpp_cli_create_leafnode () [@2] 0x19d4778 -1   res_xmpp.c:4008:_dtor_cfg (ao2_cleanup) [@3] 0x19d4778 +1   res_xmpp.c:3931:xmpp_cli_delete_pubsub_node () [@2] 0x19d4778 -1   res_xmpp.c:3931:_dtor_cfg (ao2_cleanup) [@3] 0x19d4778 +1   res_xmpp.c:3886:xmpp_cli_purge_pubsub_nodes () [@2] 0x19d4778 -1   res_xmpp.c:3886:_dtor_cfg (ao2_cleanup) [@3] 0x19d4778 -1   res_xmpp.c:3407:_dtor_cfg (ao2_cleanup) [@2] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 -1   res_xmpp.c:3407:_dtor_cfg (ao2_cleanup) [@2] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 -1   res_xmpp.c:3407:_dtor_cfg (ao2_cleanup) [@2] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 -1   res_xmpp.c:3407:_dtor_cfg (ao2_cleanup) [@2] 0x19d4778 +1   res_xmpp.c:3407:xmpp_client_reconnect () [@1] 0x19d4778 -1   res_xmpp.c:3407:_dtor_cfg (ao2_cleanup) [@2] {noformat} 0x19d4778 does not reached 0. This log was created after applying the patch. By: Matt Jordan (mjordan) 2013-02-14 08:44:24.415-0600 So, the patch is bogus. I'd throw that away :-) I still don't think there's a real ref leak here. The client configuration objects are managed by a global container (globals), which is created on module load and disposed of on module unload (via {{ao2_global_obj_release(globals);}}). The destructor for the global container {{xmpp_config_destructor}} disposes of the client configuration objects container, which should individually remove the last reference on each of the objects. The fact that during operation, the reference count on the global container toggles between 1 and 2 indicates that the reference count is where it should be - it's 1 when nothing is trying to get the global container, and 2 when something has obtained it. It's possible that during shutdown the log file just doesn't display the reference going to 0 because the file was closed out during the unload operation. I'd try loading the module, letting it run, then explicitly unloading it. By: Marcello Ceschia (marcelloceschia) 2013-02-14 09:15:58.326-0600 If you think this is not a problem, we can close this issue.