Summary: | ASTERISK-10114: Memory leak in app_voicemail.c using IMAP backend | ||
Reporter: | rayjay (rayjay) | Labels: | |
Date Opened: | 2007-08-18 06:51:38 | Date Closed: | 2007-08-18 09:16:54 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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) ........ ------------------------------------------------------------------------ |