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

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-21012:
-----------------------------------

    Assignee: Joel Vandal
      Status: Waiting for Feedback  (was: Triage)
    
> 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
>
>
> 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