A drop in the ocean

Libical memory management

with 6 comments

I started looking into libical code after speaking with michael meeks last week. Libical was holding 2500 memory blocks in a temporary buffer ring and was deallocating them in a round robin fashion. The memory blocks also held the strings which was given to its clients. The clients referring to this memory would not know when the string is going to be free’d. I sent my observation and approach to get this fixed to michael who immediately responded with his comments.  The solution is, now libical would not own the memory for the strings returned to the clients and it would use the buffer ring to manage the memory internally for its use while parsing the strings. This will prevent unnecessary memory being stored in libical for every thread and also fix some random crashers which happen due to the temp buffer. I have listed the functions which have been changed in libical here. The changes in EDS have been incorporated. I will be making similar changes in evolution as well probably by this weekend as I have to get on with listing sled evolution patches which needs to be upstreamed and upstream some eds opensuse patches. The other clients such as clock-applet and external backend’s might need to free the strings returned by the following functions  once the patch gets in. I thank michael in advance for his patch review too :)

About these ads

Written by chenthill

February 14, 2008 at 11:27 am

Posted in gnome, suse

6 Responses

Subscribe to comments with RSS.

  1. Hi Chenthill,

    libical is used in a couple of other projects too – we use it in the Bongo project, and I think the Citadel people have a copy of that library too.

    It would be great to have libical be a standalone, independent library outside of EDS so that others could contribute to its development too – would you be interested in that at all?


    Alex Hudson

    February 14, 2008 at 1:58 pm

  2. Alex,

    Libical is a seperate project by itself. It lies under svn.gnome.org/libical . Just the EDS checkout links a checkout of libical also. Otherwise, nothing so closely related :)


    February 15, 2008 at 4:26 am

  3. Currently I suppose EDS is the only module in GNOME which uses libical and so we did not want to spend much effort on getting it as a standalone library. I am not sure about the reason why libical was made as a separate GNOME module although its also in upstream at http://freeassociation.sourceforge.net/ . I will need to know why that was done. I would be definetly happy in having it as a standalone library if it facilitates to have contributors. I will get back to you soon on it.


    February 15, 2008 at 9:23 am

  4. I do believe from recent chatter on the libical list there is an effort at the moment to merge all the divergent forks of the library.

    Mark Tearle

    February 15, 2008 at 2:03 pm

  5. [...] libical a while ago using glib, when michael advised me and got me into the right path to fix the memory issues in libical rather writing another one. Federico’s fosdem 2007 talk about the profiling desktop [...]

  6. libical upstream is maintained as a standalone project, and there is an effort underway to get everyone tracking the upstream again. Anyone maintaining a fork is *strongly* encouraged to help out with this effort.

    IGnatius T Foobar

    July 14, 2008 at 3:24 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 746 other followers

%d bloggers like this: