[asterisk-bugs] [Asterisk 0018343]: [patch] [regression] meetme conf_run leaks refs

Asterisk Bug Tracker noreply at bugs.digium.com
Sat Jan 29 12:09:39 CST 2011


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18343 
====================================================================== 
Reported By:                kobaz
Assigned To:                seanbright
====================================================================== 
Project:                    Asterisk
Issue ID:                   18343
Category:                   Applications/app_meetme
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
JIRA:                       SWP-2636 
Regression:                 Yes 
Reviewboard Link:           https://reviewboard.asterisk.org/r/1025/ 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 295784 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-11-20 22:23 CST
Last Modified:              2011-01-29 12:09 CST
====================================================================== 
Summary:                    [patch] [regression] meetme conf_run leaks refs
Description: 
Affects 1.8
Affects trunk

There's two conditions (original lines 2626, 3675) where in the unlikly
event of an ao2 alloc failing, we bail from conf_run and never do any
cleanup.  This leaks a ref to an ast_conf_user.

Also there's a problem with a misuse of the user* pointer while in the *8
submenu (original line 3209), we lose the original *user pointer which will
prevent proper cleanup on leave.

And lastly, this part at the bottom looks like it will never run.  It
looks like if we get to this point, user->user_no will always have been
properly initialized... and why would we want to decrement the ref count
only if user_no is invalid?  We should always clean up at the end of this
function.

3699		if (!user->user_no) {
3700			ao2_ref(user, -1);

So far, I think that everything in the else block of the above if could be
always done on cleanup.
====================================================================== 

---------------------------------------------------------------------- 
 (0131216) svnbot (reporter) - 2011-01-29 12:09
 https://issues.asterisk.org/view.php?id=18343#c131216 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 304777

_U  branches/1.8/
U   branches/1.8/apps/app_meetme.c

------------------------------------------------------------------------
r304777 | seanbright | 2011-01-29 12:09:37 -0600 (Sat, 29 Jan 2011) | 22
lines

Merged revisions 304776 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

........
  r304776 | seanbright | 2011-01-29 13:08:14 -0500 (Sat, 29 Jan 2011) | 15
lines
  
  If we fail to allocate our announcement objects, make sure we don't leak
objects.
  
  The majority of this patch was committed already in r304726 and r304729.
  
  (issue https://issues.asterisk.org/view.php?id=18225)
  Reported by: kenji
  
  (issue https://issues.asterisk.org/view.php?id=18444)
  Reported by: junky
  
  (closes issue https://issues.asterisk.org/view.php?id=18343)
  Reported by: kobaz
  Patches:
        meetme-refs.diff uploaded by kobaz (license 834)
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=304777 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-29 12:09 svnbot         Checkin                                      
2011-01-29 12:09 svnbot         Note Added: 0131216                          
======================================================================




More information about the asterisk-bugs mailing list