Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 235083

Summary: evolution locks up and doesn't redraw for long periods of time.
Product: [Fedora] Fedora Reporter: David Woodhouse <dwmw2>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Severity: medium Docs Contact:
Priority: high    
Version: 7   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-13 16:30:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 235704    

Description David Woodhouse 2007-04-03 18:25:05 UTC
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.

Comment 1 Matthew Barnes 2007-04-03 20:40:10 UTC
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.

Comment 2 David Woodhouse 2007-04-03 23:03:37 UTC
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.

Comment 3 David Woodhouse 2007-04-11 18:23:50 UTC
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?

Comment 4 Matthew Barnes 2007-04-11 18:44:17 UTC
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.

Comment 5 David Woodhouse 2007-04-11 19:02:20 UTC
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

file /home/dwmw2 $ du -s Maildir
2208552 Maildir
file /home/dwmw2 $  find Maildir -name cur | wc -l

Comment 6 David Woodhouse 2007-04-15 10:57:38 UTC
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
--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
sv/evolution.xml:61: parser error : Entity 'trade' not defined
den beskriver hur man använder och hanterar klientprogramvaran Evolution&trade;
sv/evolution.xml:116: parser error : Entity 'reg' not defined
    <para>Besök Novell&reg;s supportcenter på <ulink url="http://support.novel

See failed evolution-2_10_1-4_fc7_dwmw2_1 build:

Comment 7 David Woodhouse 2007-04-15 11:03:16 UTC
Hm, and when I run the same command manually instead of as part of the RPM
build, it works.

Comment 8 David Woodhouse 2007-04-15 11:25:44 UTC
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.

Comment 9 Matthias Clasen 2007-04-17 23:02:14 UTC
sounds blocker-worthy

Comment 10 David Woodhouse 2007-04-19 17:03:52 UTC
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.

Comment 11 Matthias Clasen 2007-05-17 18:01:41 UTC
Matt, did you ever make any progress on this ? 
Is there any point in keeping this on F7Blocker at this point ?

Comment 12 Matthew Barnes 2007-05-17 18:21:57 UTC
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.

Comment 13 Matthew Barnes 2007-10-04 16:29:12 UTC
I still have yet to see this.  Are still getting bit by this David?

Moving to F8Target

Comment 14 David Woodhouse 2007-10-13 16:30:35 UTC
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.