On Thu, 2009-03-26 at 17:20 -0400, Chris Frey wrote:
> In my Debian Lenny system, the evolution-data-server packages install
> /usr/include/evolution-data-server-2.22/libical/ical.h, which contains
> the following code at the end:
>
> #ifndef HANDLE_LIBICAL_MEMORY
> #warning "Please ensure that the memory returned by the functions mentioned at
http://bugzilla.gnome.org/show_bug.cgi?id=516408#c1 are free'ed"
> #endif
>
> #define LIBICAL_MEMFIXES 1
>
> If this change is not supported in the plugin, then according to the
> URL above, there's a ring buffer that's freed internally in libical, and
> this would explain my near random crash behaviour.
Not quite: if the plugin does not support this change in libecal's copy
if libical, then it will leak memory. libical will not fall back to
using the ring buffer if HANDLE_LIBICAL_MEMORY is undefined. The only
purpose of that define is to suppress the warning when the user of the
library is doing the right thing.
This particular change in libical was not merged into upstream libical,
which is what libecal 2.26 is using. Instead libical decided to not
break the API of libical and added _r variants of the relevant
functions. The traditional variants still use the ring buffer.
For apps this means they *must* check LIBICAL_MEMFIXES before freeing
some of these strings - or never free them and hope that it won't matter
because a) the strings are small or b) the app is going to be used with
a libical which doesn't need it.
Using the _r variants if available is the best approach. The ring buffer
has been a source of problems because of the indeterministic life time
of the strings, so it is better to not depend on it.
--
Bye, Patrick Ohly
--
Patrick.Ohly@...
http://www.estamos.de/------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel