Re: TnyFolderMonitor infrastructure in place and working

[Philip Van Hoof <spam pvanhoof be>]

The documentation has been updated to reflect this new API.

Online too: http://tinymail.org/API


On Sun, 2007-01-21 at 18:16 +0100, Philip Van Hoof wrote:
> The TnyFolderObserver and TnyFolderMonitor infrastructure is now
> operational in that that it can already add dummy headers.
> 
> Such a dummy header is indeed added if you compile the tny-camel-
> folder.c file with a #define IM_TESTING or -DIM_TESTING flag at the
> compiler line (export CFLAGS="-DIM_TESTING" before building).
> 
> This code is, indeed, for testing purposes.
> 
> I'm now implementing the bits in camel-lite to actually get meaningful
> latest summary items (in case new ones where put in the active folder).
> 
> And after that, melting the pieces together should implement the
> feature.
> 
> http://tinymail.org/trac/tinymail/wiki/WhenNewMessagesArrive
> 
> 
> An important bug has been fixed in camel-folder-summary.c, the
> camel_message_info_new used the wrong size to allocate the instance in
> case the s parameter of the function was NULL.
> 
> This of course caused a bunch of extremely strange memory corruption
> bugs. Which aren't that strange after looking at that it:
> 
> o. CamelMessageInfo is a dummy struct that is smaller than the real,
> it's just there to present the offsets of the first members of
> CamelMessageInfoBase. That's why the real size of each being allocated
> is different from sizeof (CamelMessageInfo) but usually near (never
> smaller than) the size of CamelMessageInfoBase.
> 
> It's larger in case the provider's CamelMessageInfo instances have extra
> information that the normal one doesn't have. Sometimes this is the
> case. That's why the Camel people did this allocation trick (to add more
> members to the instance in case of overriding).
> 
> With NULL as argument, the sizeof(CamelMessageInfoBase) was suppose to
> be used, the sizeof(CamelMessageInfo) was, however, used in camel-lite's
> version of the function. Returning a much smaller instance, that was
> being casted to CamelMessageInfoBase all over the place.
> 
> In other words .. each time members of the instance where written, other
> memory was overwritten (because the offsets of CamelMessageInfoBase
> where often further-away from the root than the size of the simpler
> CamelMessageInfo structure).
> 
> 
> Why is this related to adding summary information? Because adding
> summary information starts with creating one item, with that "s"
> parameter set to NULL (which triggered this bug).
> 
> 
> 
-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog