[asterisk-dev] [Code Review]: Fix a variety of memory leaks

Matt Jordan reviewboard at asterisk.org
Fri May 18 10:24:33 CDT 2012 


> On May 18, 2012, 9 a.m., opticron wrote:
> > /branches/1.8/channels/chan_dahdi.c, line 9223
> > <https://reviewboard.asterisk.org/r/1922/diff/2/?file=27986#file27986line9223>
> >
> >     There is one more of these to watch out for when forward porting to trunk (and probably 10 as well).

Found it in trunk, will fix it in a subsequent patch.


> On May 18, 2012, 9 a.m., opticron wrote:
> > /branches/1.8/channels/chan_sip.c, line 7428
> > <https://reviewboard.asterisk.org/r/1922/diff/2/?file=27988#file27988line7428>
> >
> >     Since we're in this area of code and fixing this type of problem, this probably needs a ast_frfree.

Hm.  It might, although that wasn't caught by the tool.  The static analysis tool caught the fact that ast_dsp_process can create a new frame and that we weren't disposing of it properly.

Since calling ast_frfree shouldn't cause any harm if we are indeed done with the frame, I'll go ahead and add that to sip_rtp_read in those cases where we return an explicit null frame and ignore the frame pointed to by f. 


> On May 18, 2012, 9 a.m., opticron wrote:
> > /branches/1.8/channels/chan_sip.c, line 7439
> > <https://reviewboard.asterisk.org/r/1922/diff/2/?file=27988#file27988line7439>
> >
> >     Ditto.

Fixed


> On May 18, 2012, 9 a.m., opticron wrote:
> > /branches/1.8/channels/chan_sip.c, line 7466
> > <https://reviewboard.asterisk.org/r/1922/diff/2/?file=27988#file27988line7466>
> >
> >     Random whitespace change?

I wouldn't say random.


> On May 18, 2012, 9 a.m., opticron wrote:
> > /branches/1.8/main/cli.c, line 2354
> > <https://reviewboard.asterisk.org/r/1922/diff/2/?file=27992#file27992line2354>
> >
> >     retstr needs to be freed here.

Good catch, done.


> On May 18, 2012, 9 a.m., opticron wrote:
> > /branches/1.8/funcs/func_odbc.c, line 691
> > <https://reviewboard.asterisk.org/r/1922/diff/2/?file=27991#file27991line691>
> >
> >     This needs to be freed at the end of the function.

I don't think so.  If row is allocated, it gets added to the end of the resultset's list, so we don't want to free it - resultset gets put into the channel's datastore and is used later.

However, this does raise a problem: we can't just free resultset directly.  Once rows are assigned to a resultset we have to use the destructor function odbc_datastore_free, otherwise we will leave the memory allocated for the rows orphaned.

Note that there is a code path where we may want to dispose of a resultset and it may be NULL.  If OPT_MULTIROW is not set on the query, and the rowlimit is equal to or less then 1, a resultset object will not be created.  In that case, if a query fails, we may try to dispose of a resultset that is still NULL - so rather then add a bunch of checks throughout acf_odbc_read, the destructor function now simply returns if the pointer passed to it is NULL.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1922/#review6255
-----------------------------------------------------------


On May 18, 2012, 8:41 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1922/
> -----------------------------------------------------------
> 
> (Updated May 18, 2012, 8:41 a.m.)
> 
> 
> Review request for Asterisk Developers, otherwiseguy, rmudgett, and opticron.
> 
> 
> Summary
> -------
> 
> This fixes a number of memory leaks in core modules (and a few modules that are extended support, but were easy to fix) that were found by a static analysis tool.  A brief summary of the changes:
> 
> * app_minivm: free ast_str objects on off nominal paths
> * app_page: free the ast_dial object if the requested channel technology cannot be appended to the dialing structure
> * app_queue: if a penalty rule failed to match any existing rule list names, the created rule would not be inserted and its memory would be leaked
> * app_read: dispose of the created silence detector in the presence of off nominal circumstances
> * app_voicemail: dispose of an allocated unique ID field for MWI event un-subscribe requests in off nominal paths; dispose of configuration objects when using the secret.conf option
> * chan_dahdi: dispose of the allocated frame produced by ast_dsp_process
> * chan_iax2: properly unref peer in CLI command "iax2 unregister"
> * chan_sip: dispose of the allocated frame produced by sip_rtp_read's call of ast_dsp_process; free memory in parse unit tests
> * func_dialgroup: properly deref ao2 object grhead in nominal path of dialgroup_read
> * func_odbc: free resultset in off nominal paths of odbc_read
> * cli: free match_list in off nominal paths of CLI match completion
> * config: free comment_buffer/list_buffer when configuration file load is unchanged; free the same buffers any time they were created and config files were processed
> * data: free XML nodes in various places
> * enum: free context buffer in off nominal paths
> * features: free ast_call_feature in off nominal paths of applicationmap config processing
> * netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct that is allocated by the method.  Failures in ast_sockaddr_resolve could result in the users of the method not knowing whether or not the buffer was allocated.  The method will now not allocate the ast_sockaddr struct if it will return failure.
> * pbx: cleanup hash table traversals in off nominal paths; free ignore pattern buffer if it already exists for the specified context
> * xmldoc: cleanup various nodes when we no longer need them
> * main/editline: various cleanup of pointers not being freed before being assigned to other memory, cleanup along off nominal paths
> * menuselect/mxml: cleanup of value buffer for an attribute when that attribute did not specify a value
> * res_calendar*: responses are allocated via the various *_request method returns and should not be allocated in the various write_event methods; ensure attendee buffer is freed if no data exists in the parsed node; ensure that calendar objects are de-ref'd appropriately
> * res_jabber: free buffer in off nominal path
> * res_musiconhold: close the DIR* object in off nominal paths
> * res_rtp_asterisk: if we run out of ports, close the rtp socket object and free the rtp object
> * res_srtp: if we fail to create the session in libsrtp, destroy the temporary ast_srtp object
> 
> 
> This addresses bug ASTERISK-19665.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19665
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/apps/app_minivm.c 366879 
>   /branches/1.8/apps/app_page.c 366879 
>   /branches/1.8/apps/app_queue.c 366879 
>   /branches/1.8/apps/app_record.c 366879 
>   /branches/1.8/apps/app_voicemail.c 366879 
>   /branches/1.8/channels/chan_dahdi.c 366879 
>   /branches/1.8/channels/chan_iax2.c 366879 
>   /branches/1.8/channels/chan_sip.c 366879 
>   /branches/1.8/channels/sip/config_parser.c 366879 
>   /branches/1.8/funcs/func_dialgroup.c 366879 
>   /branches/1.8/funcs/func_odbc.c 366879 
>   /branches/1.8/main/cli.c 366879 
>   /branches/1.8/main/config.c 366879 
>   /branches/1.8/main/data.c 366879 
>   /branches/1.8/main/editline/readline.c 366879 
>   /branches/1.8/main/editline/term.c 366879 
>   /branches/1.8/main/editline/tokenizer.c 366879 
>   /branches/1.8/main/enum.c 366879 
>   /branches/1.8/main/features.c 366879 
>   /branches/1.8/main/netsock2.c 366879 
>   /branches/1.8/main/pbx.c 366879 
>   /branches/1.8/main/xmldoc.c 366879 
>   /branches/1.8/res/res_calendar.c 366879 
>   /branches/1.8/res/res_calendar_caldav.c 366879 
>   /branches/1.8/res/res_calendar_exchange.c 366879 
>   /branches/1.8/res/res_calendar_icalendar.c 366879 
>   /branches/1.8/res/res_jabber.c 366879 
>   /branches/1.8/res/res_musiconhold.c 366879 
>   /branches/1.8/res/res_rtp_asterisk.c 366879 
>   /branches/1.8/res/res_srtp.c 366879 
> 
> Diff: https://reviewboard.asterisk.org/r/1922/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120518/50dec18c/attachment-0001.htm>

More information about the asterisk-dev mailing list