On Friday, 29th July, started my hunt for memory leaks in the recent ECal bindings in Evolution#.
Found a potential memory leak when creating an array of CalComponent objects from icalcomponent and ECalComponent objects. The call to the glue-API that does the intermediate conversion to ECalGlueComponent objects expects the caller to free the returned list of ECalGlueComponent objects but was never freed, instead, the individual fields of this objects were getting freed through the GLib.Marshaller.PtrToStringGFree() method. In order to fix this, I wrote a glue-API that takes the list of ECalGlueComponent objects are unref's them.
Every thing went fine till the new "memory-leak fix" API was called. When the API tried to unref the objects, *BANG*, a sexy segfault occurred.
Spent the whole afternoon trying to nail the culprit in the holy cross, but, didn't. Packed the laptop and caught the 2:30 PM bus to my native.
Saturday, 30th July, 10:00 PM:
Booted to my linux partition. (laptop has got a default windows partition, to be removed). Started hunting for the criminal that actually frees the memory of one of the fields of ECalGlueComponent object. Spent an hour adding all possible g_warning aka fprintf to pring debug messages.
*Voila*, to the epitome of surprise, found the hide-out of the culprit who was doing this - Mono marshaller.
Suppose, if a native call returns a "char*", mono converts it to "string" type by default. However, as an added-offer, it also "de-allocates" the source/original memory.
I am not pretty sure on the behaviour, though.
Expect the unexpected?
Tuesday, August 02, 2005
Subscribe to:
Post Comments (Atom)
1 comment:
Ahh... memory leak when creating array of CalComponent objects from icalcomponent and ecalcomponent objects! What a coincidence. Its back in the exact same place and same form :-).
Post a Comment