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

Re: hcache broken (slightly)



Hi,

* Thomas Glanzmann [06-07-12 10:07:09 +0200] wrote:

pop3 hcache segfaults, because it uses the hcache infrastructure in a
way it isn't supposed to be.

Okay, I just assumed it does The Right Thing[TM]. So I guess we need to extend it as, IMHO, we need this feature.

There are two ways around:

       - Find a way to avoid dumping the uncached structures

I don't think this makes sence as many of these depend on the current environment. For example, saving header->tree doesn't make sense as the sorting method may have changed since fetching, etc (also messages could have disappeared from another mutt instance so mutt would restore a bogus tree string).

       - Understand the logic behind the header->thread pointers and
         recalculate them on restore

I think this already is the case. When fetching headers for the first time, they're quite nacked and contain only bare information the server gave us. What we need to do when updating from current messages that have more info, is to find out that "nacked" set of information and store it.

The ideal case, IMHO, would be to let hcache do that because it's only one part of code to modify. I recall Brendan having trouble too, so I don't know what he wanted to do with this feature; but if IMAP needs it, too, this is another reason to put it in hcache.c.

Please apply the attached patch to catch such problems in the future
early: It adds assertions that test that HEADER data which will not be
dumped/restored are always zero and doesn't contain any data to malloced
areas.

Since I think we need this feature of updating, isn't abort a bit harsh?

  bye, Rocco
--
:wq!