Bug 772585

Summary: evolution-3.3.3-1.fc17 does not startup
Product: [Fedora] Fedora Reporter: Andreas Bierfert <andreas.bierfert>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: lucilanga, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-09 17:15:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
log with CAMEL_DEBUG=all
none
gdb backtrace of stuck evolution 3.3.3 none

Description Andreas Bierfert 2012-01-09 10:34:26 UTC
Created attachment 551527 [details]
log with CAMEL_DEBUG=all

Description of problem:
I upgraded my system from f16-updates-testing to rawhide this weekend. When I try to startup evolution it hangs. Camel debug output does not point to anything obvious.

strace shows that it is waiting on a futex:
futex(0x181ca44, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>

evolution-3.3.3-1.fc17.x86_64
evolution-data-server-3.3.3-2.fc17.x86_64
evolution-data-server-devel-3.3.3-2.fc17.x86_64
evolution-data-server-doc-3.3.3-2.fc17.noarch
evolution-exchange-3.3.3-1.fc17.x86_64
evolution-mapi-3.3.3-1.fc17.x86_64
evolution-NetworkManager-3.3.3-1.fc17.x86_64
evolution-perl-3.3.3-1.fc17.x86_64
evolution-pst-3.3.3-1.fc17.x86_64

glibc-2.15-1.fc17.x86_64
kernel-3.2.0-2.fc17.x86_64

3.3.2 from koji does not start either. 3.3.1 from koji seems to work fine.

Comment 1 Milan Crha 2012-01-09 11:40:39 UTC
Thanks for a bug report. Could you get a backtrace (with debuginfo packages of the right version for evolution-data-server and evolution installed) of the stuck evolution process, please? It'll show where it is stuck and can give a bit of hints. You can capture such backtrace with a command like this:
   $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt
where PID is a process ID of a running application, in our case evolution.

By any chance, do you use any IMAP account (not IMAP+), with set real trash and/or junk folders?

Comment 2 Andreas Bierfert 2012-01-09 14:07:27 UTC
Created attachment 551573 [details]
gdb backtrace of stuck evolution 3.3.3

Comment 3 Andreas Bierfert 2012-01-09 14:11:19 UTC
I have a couple of imap accounts configured an at least two of them set draft,trash explicitly somewhere in the imap folder structure (INBOX/{Drafts,Trash})...

Comment 4 Milan Crha 2012-01-09 17:15:16 UTC
Thanks for the update. That's the same thing as the upstream bug [1], thus I'm moving it there. It's caused by code changes and the fact that it tries to get the remote Trash folder on start. I'm afraid there is nothing easier than a downgrade for now. The bug will be hopefully fixed in 3.3.4.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=667281

Comment 5 Andreas Bierfert 2012-01-09 17:19:18 UTC
Thanks I will follow upstream...