<<< Date Index >>>     <<< Thread Index >>>

Re: mutt cache sensitivity



On Sunday, 01 April 2007 at 11:04, Rocco Rutte wrote:
>  Hi,
> 
>  * Kyle Wheeler [07-04-01 00:31:56 -0600] wrote:
> > On Friday, March 30 at 03:29 PM, quoth Rocco Rutte:
> >>> So... you're telling me that pointers are no longer stored in
> >>> the hcache? Mutt (with hcache) no longer relies on malloc
> >>> returning predictable results?
> 
> >> No. Pointers are still stored. We don't really update the hcache
> >> so that pointers could be an issue.
> 
> > ... I guess you mean that pointers aren't *restored*?
> 
>  They are both: stored and restored. Storing a message happens is
>  just right after it got fetched from the server so that at that
>  point there isn't data behind those pointers, they're just NULL.
>  After reading the message from the cache, mutt gets NULL pointers
>  all the time and thus behaves exactly as it would without the cache
>  because the message is the same as it was after the fetch.
> 
>  That's why it's so difficult to fix the issue because we need to
>  identify which pointers may contain garbage and which don't.
> 
>  My first approach (which was rejected) was with a whitelist,
>  i.e. storing only pointers we also dump/restore data for. The right
>  approach was considered to be a blacklist one that only sets
>  "dangerous" pointers to NULL. I failed to implement that because of
>  the above reason. Hence the issue is still open...

I've just pushed some changes to blacklist dangerous pointers (all
that aren't already handled). I was pretty conservative - I may be
zeroing out more than strictly necessary. I've got a local hack to
update the hcache with the full parsed message whenever I fetch a
message, and it seems to be working fine -- it used to crash when I
opened such a cache, but now it continues on happily, using the extra
data. I think there were two big problems: the threading code got
horribly confused, and FREE would probably blow up on other existing
pointers.

By the way, I really have no idea why the CRC is per message instead
of per folder. It makes more sense to me to have it per-folder.

Now, if we can extend the cache to preserve the IMAP data (UID and
flags), we should be on our way to opening folders that haven't
received new mail virtually instantly.

Attachment: pgp38Cbl35F0C.pgp
Description: PGP signature