GNOME Bugzilla – Bug 552731
Summary generated repeatedly ad infinitum
Last modified: 2008-10-16 18:56:40 UTC
When I start up evolution, and it's done (or at the end of) generating the vfolder indices etc. it goes into an infinite loop "storing folder". It looks like there's something wrong with the summary generator or validator. I'm using evolution-2.23.92+r36353 built from the GNOME:Factory project in openSUSE's build service. Typical terminal output: (evolution:14496): camel-local-provider-WARNING **: Summary doesn't match the folder contents! eek! expecting offset 103996132 got 103998744, state = 2 Triggering summary_reloaded on Spam 0xb140f00 (evolution:14496): camel-local-provider-WARNING **: Summary doesn't match the folder contents! eek! expecting offset 103996132 got 103998744, state = 2 (evolution:14496): camel-local-provider-WARNING **: Summary doesn't match the folder contents! eek! expecting offset 104024148 got 104027007, state = 2 (evolution:14496): e-data-server-WARNING **: Error in execution: Incompatible types in compare > (evolution:14496): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:14496): camel-local-provider-WARNING **: Summary doesn't match the folder contents! eek! expecting offset 104024148 got 104027007, state = 2 (evolution:14496): camel-local-provider-WARNING **: Summary doesn't match the folder contents! eek! expecting offset 104032513 got 104032659, state = 2
HPJ, Can you get me a glance of gdb traces (2-3 samples) and paste me. I could find from this that the summary is regenerated. But I need t know more on why it goes infinite for you. Thanks.
What are you looking for here? Evolution needs to index for several hours before it gets into this state (and I have to work around bug 552731 by stopping and restarting it periodically), so I'd rather try to get you the right traces the first time around. Maybe there are breakpoints I can set? How about breaking on the "Summary doesn't match the folder contents" warning and getting a trace from there?
This should be fine. I need to see why it has to generate. Do you have any spool/local delivery type accounts?
I have committed some fixes to stable/trunk must fix this. There was a issue where the flag wasn't dirty and the timestamp was mismatching. Please try out and lemme know it fixes it. PS: Camel ABI is broken, so you might have to compile evo after this.
HPJ, Did you try at this?
I just bought some more RAM so I can build and test this in a separate VM. Expect feedback later this week.
This seems to be working now in trunk.