Bug 235083 - evolution locks up and doesn't redraw for long periods of time.
evolution locks up and doesn't redraw for long periods of time.
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
7
All Linux
high Severity medium
: ---
: ---
Assigned To: Matthew Barnes
:
Depends On:
Blocks: F8Target
  Show dependency treegraph
 
Reported: 2007-04-03 14:25 EDT by David Woodhouse
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-13 12:30:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 362638 None None None Never

  None (edit)
Description David Woodhouse 2007-04-03 14:25:05 EDT
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 16:40:10 EDT
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 19:03:37 EDT
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 14:23:50 EDT
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 14:44:17 EDT
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 15:02:20 EDT
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

Comment 6 David Woodhouse 2007-04-15 06:57:38 EDT
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&trade;</productname>
                               ^
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:
http://brewweb.devel.redhat.com/brew/getfile?taskID=739168&name=build.log
Comment 7 David Woodhouse 2007-04-15 07:03:16 EDT
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 07:25:44 EDT
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 19:02:14 EDT
sounds blocker-worthy
Comment 10 David Woodhouse 2007-04-19 13:03:52 EDT
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 14:01:41 EDT
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 14:21:57 EDT
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 12:29:12 EDT
I still have yet to see this.  Are still getting bit by this David?

Moving to F8Target
Comment 14 David Woodhouse 2007-10-13 12:30:35 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.