[asterisk-bugs] [JIRA] (ASTERISK-21012) Memory Leak on res_calendar (icalendar)

Wed Jan 30 07:38:58 CST 2013

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202394#comment-202394 ] 

Joel Vandal edited comment on ASTERISK-21012 at 1/30/13 7:38 AM:
-----------------------------------------------------------------

IMHO the problem is fixed, memory increase in ~10 hours is very small (less than 5mb). Without the patch, asterisk process used about 4GB or memory. 

Yesterday :   11117 scopserv  15   0  877m  68m  12m S  0.0  0.9   0:04.97 /usr/sbin/asterisk -f -vvvg -c

This morning: 11117 scopserv  15   0  883m  75m  12m S  0.0  1.0   2:49.67 /usr/sbin/asterisk -f -vvvg -c

So 5mb vs 4gb of memory for same period and server usage made me thinking that your patch is fully working and that can be commited.

      was (Author: joel_vandal):
    IMHO the problem is fiexed, memory increase in ~10 hours is very small (less than 5mb). Without the patch, asterisk process used about 4GB or memory. 

Yesterday :   11117 scopserv  15   0  877m  68m  12m S  0.0  0.9   0:04.97 /usr/sbin/asterisk -f -vvvg -c

This morning: 11117 scopserv  15   0  883m  75m  12m S  0.0  1.0   2:49.67 /usr/sbin/asterisk -f -vvvg -c

So 5mb vs 4gb of memory for same period and server usage made me thinking that your patch is fully working and that can be commited.

> Memory Leak on res_calendar (icalendar)
> ---------------------------------------
>
>                 Key: ASTERISK-21012
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21012
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_calendar_icalendar
>    Affects Versions: 1.8.20.1
>         Environment: Asterisk 1.8.20.1 running on CentOS 5.8 (x86_64)
>            Reporter: Joel Vandal
>            Assignee: Joel Vandal
>         Attachments: ASTERISK-21012.diff, valgrind.txt
>
>
> Have a server where Asterisk memory usage grow to ~8gb per 24 hours.
> I start Asterisk and after few minutes, I start to see memory changes.
> After some debugging, I've pinpoint the issue to Calendar modules and if I remove all res_calendar_* files then memory usage is normal.
> I've rebuild Asterisk with MALLOC_DEBUG and DONT_OPTIMIZE ..
> Here a partial log of valgrind started with :
> valgrind -v --track-origins=yes --leak-check=full --show-reachable=yes --suppressions=/root/valgrind.supp --log-fd=9 asterisk -vvvvcg 9> valgrind.txt
> ==27030== 2,835,600 bytes in 70,890 blocks are indirectly lost in loss record 3,827 of 3,844
> ==27030==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
> ==27030==    by 0x1278D34D: pvl_newlist (pvl.c:72)
> ==27030==    by 0x1277F1F3: icalproperty_new_impl (icalproperty.c:111)
> ==27030==    by 0x1277D5EA: icalparser_add_line (icalparser.c:830)
> ==27030==    by 0x1277DECC: icalparser_parse (icalparser.c:621)
> ==27030==    by 0x1277E010: icalparser_parse_string (icalparser.c:1285)
> ==27030==    by 0x1BA45359: fetch_icalendar (res_calendar_icalendar.c:156)
> ==27030==    by 0x1BA46CD8: ical_load_calendar (res_calendar_icalendar.c:471)
> ==27030==    by 0x5202DC: dummy_start (in /usr/sbin/asterisk18)
> ==27030==    by 0x37DB60683C: start_thread (in /lib64/libpthread-2.5.so)
> ==27030==    by 0x37DA6D503C: clone (in /lib64/libc-2.5.so)
> ...
> ==27030== 16,816,205 (280 direct, 16,815,925 indirect) bytes in 5 blocks are definitely lost in loss record 3,844 of 3,844
> ==27030==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
> ==27030==    by 0x1277F1D9: icalproperty_new_impl (icalproperty.c:103)
> ==27030==    by 0x1277D5EA: icalparser_add_line (icalparser.c:830)
> ==27030==    by 0x1277DECC: icalparser_parse (icalparser.c:621)
> ==27030==    by 0x1277E010: icalparser_parse_string (icalparser.c:1285)
> ==27030==    by 0x1BA45359: fetch_icalendar (res_calendar_icalendar.c:156)
> ==27030==    by 0x1BA46CD8: ical_load_calendar (res_calendar_icalendar.c:471)
> ==27030==    by 0x5202DC: dummy_start (in /usr/sbin/asterisk18)
> ==27030==    by 0x37DB60683C: start_thread (in /lib64/libpthread-2.5.so)
> ==27030==    by 0x37DA6D503C: clone (in /lib64/libc-2.5.so)
> ==27030==
> ==27030== LEAK SUMMARY:
> ==27030==    definitely lost: 1,926 bytes in 79 blocks
> ==27030==    indirectly lost: 28,121,308 bytes in 419,674 blocks
> ==27030==      possibly lost: 117,010,929 bytes in 1,463,484 blocks
> ==27030==    still reachable: 11,224,116 bytes in 158,313 blocks
> ==27030==         suppressed: 0 bytes in 0 blocks
> ==27030==
> ==27030== ERROR SUMMARY: 127637 errors from 1718 contexts (suppressed: 748 from 7)
> ==27030==

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira