[Home]

Summary:ASTERISK-10114: Memory leak in app_voicemail.c using IMAP backend
Reporter:rayjay (rayjay)Labels:
Date Opened:2007-08-18 06:51:38Date Closed:2007-08-18 09:16:54
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:It seems an earlier reported memory leak has returned to app_voicemail when running with an IMAP backend.  The leak occurs in the 'messagecount' function when calling 'find_user'.  The returned 'vmu' variable does not appear to be free'd correctly by the 'free_user(vmu)' calls?  I expect this is because the "if (ast_test_flag(vmu, VM_ALLOCED))" call within free_user is not matching for some reason?  If I change the free_user(vmu) to "free(vmu)" then the memory leak appears to go away?  In my setup the Asterisk process managed to reach 600MB in 24 hours with this memory leak.  If you require any further info let me know.
Comments:By: Digium Subversion (svnbot) 2007-08-18 09:12:50

Repository: asterisk
Revision: 79947

------------------------------------------------------------------------
r79947 | tilghman | 2007-08-18 09:12:50 -0500 (Sat, 18 Aug 2007) | 3 lines

Don't allocate vmu for messagecount when we could just use the stack instead (closes issue ASTERISK-10114)
Also, remove a useless (and leaky) SQLAllocHandle (closes issue ASTERISK-10104)

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

By: Digium Subversion (svnbot) 2007-08-18 09:16:54

Repository: asterisk
Revision: 79949

------------------------------------------------------------------------
r79949 | tilghman | 2007-08-18 09:16:54 -0500 (Sat, 18 Aug 2007) | 11 lines

Merged revisions 79947 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r79947 | tilghman | 2007-08-18 09:30:44 -0500 (Sat, 18 Aug 2007) | 3 lines

Don't allocate vmu for messagecount when we could just use the stack instead (closes issue ASTERISK-10114)
Also, remove a useless (and leaky) SQLAllocHandle (closes issue ASTERISK-10104)

........

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