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!