GNOME Bugzilla – Bug 730344
Spawned processes hang when clicking on an appointment
Last modified: 2017-07-29 15:23:51 UTC
With Debian Sid/unstable using Evolution 3.12.2 and Evolution Data Server 3.12.2 starting Evolution takes a long time. This time an appointment was due and the reminder window popped right up. Clicking *Edit* nothing happened. After a while a message appeared informing the user that there was already running an Evolution process in the background. The user left the reminder window open. After Evolution was done loading, the user clicked *Edit* again and nothing happened either. Closing Evolution it hung and investigating it showed that there were two other Evolution processes in the background taking up a lot of CPU time. $ ps aux | grep evolution joey 9736 0.0 0.0 4336 828 pts/6 S+ 21:57 0:00 grep evolution joey 18077 17.6 10.0 1286040 792344 pts/1 Sl 20:26 16:07 evolution joey 18108 0.0 0.1 120128 12448 ? SLl 20:26 0:03 /usr/lib/evolution/evolution-source-registry joey 18171 0.0 0.3 310056 29528 pts/1 Sl 20:27 0:02 /usr/lib/evolution/3.12/evolution-alarm-notify joey 18177 1.9 3.7 444680 296276 ? Sl 20:27 1:45 /usr/lib/evolution/evolution-calendar-factory joey 19210 80.0 2.2 552676 181688 pts/1 tl 20:30 69:39 evolution calendar:///?source-uid=1400363736.24675.3@myhostname&comp-uid=20140517T230529Z-24675-1000-4050-196@myhostname joey 23970 0.0 0.1 126424 11892 ? Sl 20:48 0:00 /usr/lib/evolution/evolution-addressbook-factory joey 25752 84.9 0.7 392924 61124 pts/1 Rl 20:55 52:55 evolution calendar:///?source-uid=1400363736.24675.3@myhostname&comp-uid=20140517T230529Z-24675-1000-4050-196@myhostname Attaching to process 19210 with GDB and running `t a a bt f` shows the output below.
+ Trace 233610
Thread 1 (Thread 0xb0b39900 (LWP 19210))
Inferior 1 [process 19210] will be detached. Quit anyway? (y or n) Detaching from program: /usr/bin/evolution, process 19210 Killing both processes, the “original” Evolution finally closed.
Thanks for a bug report. It looks odd. Could it be that your folders.db file for an IMAP account is broken, probably after some other crash, which leads to this long start and later misbehaviour? I would try to get rid of all folders.db files from ~/.cache/evolution/mail/*/ folders. The backtrace shows that SQLite is cleaning your Junk folder's local cache and it makes it quite busy. It can be that the file was just in that folder when you caught the backtrace, thus it can move forward to other folders of the account later on, but still, if the folders.db file is broken, then nothing will help.
Shouldn’t my `folders.db` file be fine as there is the other Evolution instance running just fine? Also in subsequent starts, where no appointments are due or “Cancel”(?) instead of “Edit” is clicked, it works fine too. Maybe you can reproduce it with the steps below. 1. Add a CalDAV calendar and add an appointment which is going to pop up during the next start. 2. Go into Offline mode and close Evolution 3. Wait until the appointment is due. 4. Open Evolution and the reminder for the appointment should pop up right away (even if closed in Offline mode) and click on »Edit«. 5. Check if several Evolution processes are in the background.
OK, I confess I've got lost when you switch between versions. it can be that some clean-up of "old" data from 3.10 is causing the slow start. I'm pretty sure the slow start is causing the "two instances running" for you too. The "Edit" button response simply runs evolution with a command line like: evolution calendar:///?source-uid=XXXXXX&comp-uid=YYYYYYY You might see exact command line in a 'ps' result. Once evolution initializes, it recognizes that it's the second instance and just passes the arguments to the already running instance and closes itself. The start delay causes that you see two evolutions running. I do not see it here, because my start it quicker. I believe a backtrace of the second instance wil be similar to the one in comment #0. The simplest test is to move away the folders.db file(s) and see whether it is caused by it.
Pual: Can you please answer comment 3 if this is still a problem?
(In reply to André Klapper from comment #4) > Pual: Can you please answer comment 3 if this is still a problem? Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!