Summary:ASTERISK-17153: [patch] Memory leaking in calendars
Reporter:Bc. Jan Kaláb (pitel)Labels:
Date Opened:2010-12-23 09:15:40.000-0600Date Closed:2011-01-04 11:04:16.000-0600
Versions:Frequency of
Environment:Attachments:( 0) allocations.txt
( 1) allocations2.txt
( 2) calendar.conf
( 3) ne_request_destroy.patch
( 4) ps.txt
( 5) summary.txt
( 6) summary2.txt
( 7) warnings.txt
Description:Memory is leaking in calendaring module.

Noticed after backporting calendaring to Asterisk, but it also appear in!


Currently, we have 7 calendars using different protocols, and it's eating more and more memory every hour. About 1 MB every hour!

Some of those calendars are misconfigured (nonexistent address, bas username or password), so it might be problem with that. But I guess it should be handled without memory leaks!

I compiled Asterisk with malloc debugging and without optimalizations, but `memory show summary` still shows about the same amount on the end of the log. But ps utitity running every minute and saving the numbers to database shows how it grows.

I have loaded only the calendaring modules in modules.conf for the testing purposes. No SIP or any other modules. Autoload is disabled.

If you will guide me how to run valgrind to debug that, I would be glad.
Comments:By: Bc. Jan Kaláb (pitel) 2010-12-23 09:17:29.000-0600

warnings.txt shows the warnings about misconfigured calendars.

allocations.txt is output of `memory show allocations`. I'll upload new one in couple of hours, so we might see where it's leaking.

By: Bc. Jan Kaláb (pitel) 2010-12-23 09:21:14.000-0600

My colleague just told me, it's also leaking even without any calendars set up.

EDIT: But I can't confirm that. After one day of Asterisk running only with calendar modules, but without calendars, it still require only reasonable 7 MBs.

By: Clod Patry (junky) 2010-12-30 09:07:14.000-0600

Can you attach you calendar.conf  (Don't forget to hide your passwords).
"memory show summary" over the time would be great to see too.


By: Bc. Jan Kaláb (pitel) 2010-12-30 09:18:49.000-0600

Sure, I attached calendar.conf. But it's just full of made-up calendars on mostly non-existing URLs. Just what we get we tested our web interface. :)

I also attached `memory show summary` output from now, which is just couple of minutes after restarting asterisk. ps says it allocates 8.4 MBs.

By: Clod Patry (junky) 2010-12-30 09:31:25.000-0600

In fact, there's "1213385 bytes allocated in 2134 allocations", which is 1.2 MB total.
Repost in few hours/days the exact same output.

By: Bc. Jan Kaláb (pitel) 2010-12-31 02:28:14.000-0600

And now I attached the summary2.txt. There is again about 1.2 MB of allocations.

But I also attached ps.txt showing that the memory usage is really rising. The first record is from the same time as summary.txt, the second one is from summary2.txt time.

So, if it's not leaking from Asterisk, do you suggest it might be leak in some libraries calendars are using (libical, iksemel, libneon, libxml2, ...)?

By: Marek Cervenka (cervajs) 2010-12-31 04:49:09.000-0600

i found this commit in libical

r1037 | awinterz | 2010-10-07 00:33:54 +0200 (Thu, 07 Oct 2010) | 18 lines

fix some memory leaks in libical
patch from qkmiao -- Thanks!
ID: 3046011

1. In icalparameter_set_* series function, param->string is overridden
with new string. Then the old string gets lost. icalparameter_set_* series
functions are in icalderivedparameter.c. This c file is generated by
libical/scripts/mkderivedparameters.pl. Just add code to free non-empty
param->string before it is overridden.

2. Function "icalcomponent_remove_property" will remove property instance
from properties list but don't free the space it holds. So, when call this
function, the property instance remove from properties list should be free
explicitly. Similarly for "pvl_remove (prop->parameters, p);" it also should
be explicitly free memory after remove parameter instance form parameter list.

i will try latest libical 0.46 with pitel (we are using 0.43)

happy new year!

By: Bc. Jan Kaláb (pitel) 2011-01-03 04:05:44.000-0600

Updating libical didn't helped. It growed to almost 70 MBs over weekend.

By: Bc. Jan Kaláb (pitel) 2011-01-03 04:33:24.000-0600

I'm gonna test it per-module.

By: Bc. Jan Kaláb (pitel) 2011-01-04 03:04:55.000-0600

EWS ok (neon)
caldav ok (neon, ical, libxml2)

ical leaks (neon, ical)
exchange leaks (neon, ical, iksemel)

By: Bc. Jan Kaláb (pitel) 2011-01-04 08:20:29.000-0600

I just noticed ical and exchange modules are missing ne_request_destroy() after processing request.

I'm testing it, and if it will fix the leak, I'll submit patch for code review.

By: Bc. Jan Kaláb (pitel) 2011-01-04 10:15:11.000-0600

It indeed fixes the leak!

Patch is attached, and I'm gonna file code review.

By: Bc. Jan Kaláb (pitel) 2011-01-04 10:24:09.000-0600

Here is the review board: https://reviewboard.asterisk.org/r/1068

By: Digium Subversion (svnbot) 2011-01-04 11:01:53.000-0600

Repository: asterisk
Revision: 300214

U   branches/1.8/res/res_calendar_exchange.c
U   branches/1.8/res/res_calendar_icalendar.c

r300214 | pitel | 2011-01-04 11:01:52 -0600 (Tue, 04 Jan 2011) | 7 lines

Memory leaking in calendars

ne_request_destroy() was missing in icalendar and exchange calendar modules, causing memory leak.

(closes issue ASTERISK-17153)
Review: https://reviewboard.asterisk.org/r/1068/



By: Digium Subversion (svnbot) 2011-01-04 11:04:15.000-0600

Repository: asterisk
Revision: 300215

_U  trunk/
U   trunk/res/res_calendar_exchange.c
U   trunk/res/res_calendar_icalendar.c

r300215 | pitel | 2011-01-04 11:04:15 -0600 (Tue, 04 Jan 2011) | 14 lines

Merged revisions 300214 via svnmerge from

 r300214 | pitel | 2011-01-04 18:01:52 +0100 (?\195?\154t, 04 led 2011) | 7 lines
 Memory leaking in calendars
 ne_request_destroy() was missing in icalendar and exchange calendar modules, causing memory leak.
 (closes issue ASTERISK-17153)
 Review: https://reviewboard.asterisk.org/r/1068/