At frequent intervals, evolution just locks up and stops redrawing itself for up to a minute at a time. I don't believe this was happening yesterday with evo-2.10.0-2; it seems to have started with evo-2.10.2-7 (I didn't try anything in between). I might try reverting the changes to evolution-2.8.1-kill-ethread.patch to see if that's what the problem is.
David, I've not seen the lock up myself but you're right that the kill-ethread patch is likely the culprit. evolution-2.10.0-6.fc7 introduced some updates to the patch. Do let me know if reverting the patch helps. I've been trying to clean up the threading logic in the mailer and it's a minefield, as you can imagine.
Reverting the patch definitely seems to have fixed it -- at least I haven't seen it happen for a while now after restarting the new Evolution, and it was happening quite frequently before.
I've been building my own version of evolution with the older version of your kill-ethread patch, but I see you've just updated that patch. Should I expect it to have addressed this problem?
No, the -2.fc7 update was for a crasher (bug #235096). If you'd be willing to humor me a bit, I suspect the problem you're seeing can be isolated to the changes I made to mail/em-sync-stream.[ch]. Can you try ripping those hunks out of the kill-ethread patch and see if you still experience the lock-up problem? The mail/em-sync-stream.[ch] changes are not directly related to EThread. Rather, I tacked it on in an effort to simultaneously kill off another old E-D-S structure (EMsgPort). Any details you can provide about how to reproduce the hang would be most appreciated. I've not seen it yet myself.
OK, I'll try that. I can't offer specific advice on reproducing the issue, but it may be relevant that I have two separate imap servers, each of which has a few hundred folders and a few gigabytes of mail. Most of these are archive folders which are never touched (at least in my builds which have GNOME #336074 fixed) baythorne /home/dwmw2 $ du -s Maildir 12256924 Maildir baythorne /home/dwmw2 $ find Maildir -name cur | wc -l 804 file /home/dwmw2 $ du -s Maildir 2208552 Maildir file /home/dwmw2 $ find Maildir -name cur | wc -l 259
Hm, my test builds are failing with xml errors... xsltproc -o evolution-sv.omf --stringparam db2omf.basename evolution --stringparam db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML V4.1.2//EN" --stringparam db2omf.lang sv --stringparam db2omf.omf_dir "/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help" --stringparam db2omf.omf_in "/home/dwmw2/working/pkgs/evolution/devel/evolution-2.10.1/help/evolution.omf.in" --stringparam db2omf.scrollkeeper_cl "`scrollkeeper-config --pkgdatadir`/Templates/C/scrollkeeper_cl.xml" `/usr/bin/pkg-config --variable db2omf gnome-doc-utils` sv/evolution.xml || { rm -f "evolution-sv.omf"; exit 1; } sv/evolution.xml:53: parser error : Entity 'trade' not defined <productname>Evolution™</productname> ^ sv/evolution.xml:61: parser error : Entity 'trade' not defined den beskriver hur man använder och hanterar klientprogramvaran Evolution™ ^ sv/evolution.xml:116: parser error : Entity 'reg' not defined <para>Besök Novell®s supportcenter på <ulink url="http://support.novel ^ See failed evolution-2_10_1-4_fc7_dwmw2_1 build: http://brewweb.devel.redhat.com/brew/getfile?taskID=739168&name=build.log
Hm, and when I run the same command manually instead of as part of the RPM build, it works.
Oh, sorry. Ignore me, I'm being stupid. It's actually failing earlier -- on em-sync-stream.c, unsurprisingly. Just removing the hunks of the patch which change em-sync-stream.[ch] doesn't work. I'll try reverting what interdiff shows me is the difference between v1.2 and v1.3 of the offending patch.
sounds blocker-worthy
Using evolution-2.8.1-revert-ethread-parts.patch (on private-evo-sanity-2_10_0-branch) it still seems to be behaving correctly. Next time I do a test build, I'll leave that patch out and will confirm that the lockups still happen.
Matt, did you ever make any progress on this ? Is there any point in keeping this on F7Blocker at this point ?
Based on when David started seeing this it may be related to some threading work I've been doing to the mailer. But I've not seen this bug myself nor have I seen any other reports or complaints about the lock up behavior. So I see no reason this should block F7 at this point. Moving to F7Target. I'll investigate further as more information becomes available.
I still have yet to see this. Are still getting bit by this David? Moving to F8Target
I'm not, and I'm no longer carrying the partial reversion of your threading patches in my own package. Will reopen if it recurs.