When I start my system from a fresh boot and start kmail it loads fine in kubuntu 16.04. If I close kmail and then try and restart it no window is shown and it appears to do nothing except the loading animation in the panel/icon. If I go into ksysmonitor and kill the kmail process and then attempt to load kmail it works. Reproducible: Always Steps to Reproduce: 1. start kamil 2. close kmail normally 3. start kmail again 4. kill kmail process that is in the background 5. start kmail again Actual Results: kmail loaded Expected Results: You shouldn't have to kill the kmail background process in order for kmail to load. I'm running a fresh install of Kubuntu and not an upgrade.
This happens because KMail process never finishes after closing the window. Same here.
I figured out why this is happening. This happens because of the "Empty tocal trash folder on program exit" checkbox is ticked.
Good. Now it's easy to create a patch fixing this.
This is the actual problematic piece of code KSharedConfig::Ptr config = KMKernel::config(); Akonadi::Collection trashCollection = CommonKernel->trashCollectionFolder(); if (trashCollection.isValid()) { if (KMailSettings::self()->emptyTrashOnExit()) { Akonadi::CollectionStatisticsJob *jobStatistics = new Akonadi::CollectionStatisticsJob(trashCollection); if (jobStatistics->exec()) { if (jobStatistics->statistics().count() > 0) { mFolderCollectionMonitor->expunge(trashCollection, true /*sync*/); } } } } from kmkernel.cpp file.
Does that mean a problem exists in the emptyTrashOnExit() function? Because it works while using the context menu right click. Are they that different, or does the trash empty program move the process to an external application because the application closes before doing the empty process?
KMailSettings::self()->emptyTrashOnExit() just reads settings and returns "true" or "false". That's not it.
It's really hard to debug this stuff in kubuntu because package kdepim-dbg is missing. Why?
Ryein Goddard, please check this https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/1584288 Click on "Does this bug affect you?" -> "Yes, it affects me".
Debugging session was really confusing. I found out that the certain thread never finishes going in infinite loop like that [Switching to thread 16 (Thread 0x7fff5dca4700 (LWP 1154))] #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 185 in ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S (gdb) [Switching to thread 16 (Thread 0x7fff5dca4700 (LWP 1154))] #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 185 in ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S (gdb) [Switching to thread 16 (Thread 0x7fff5dca4700 (LWP 1154))] #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 185 in ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
The last executed line of code is always the same: Akonadi::CollectionStatisticsJob::CollectionStatisticsJob (this=0x9e98f0, collection=..., parent=0x0) at /build/kdepimlibs-Nkju09/kdepimlibs-15.12.3/akonadi/src/core/jobs/collectionstatisticsjob.cpp:54 54 /build/kdepimlibs-Nkju09/kdepimlibs-15.12.3/akonadi/src/core/jobs/collectionstatisticsjob.cpp: No such file or directory. (gdb) KMKernel::cleanup (this=this@entry=0x7fffffffdb70) at /build/kdepim-FI8Jpb/kdepim-15.12.3/kmail/kmkernel.cpp:1410 1410 /build/kdepim-FI8Jpb/kdepim-15.12.3/kmail/kmkernel.cpp: No such file or directory. Which is: if (jobStatistics->exec()) { The line from the piece of code I pasted before.
exec() is a member of KJob class. Now let's look what tells us the documentation: * Executes the job synchronously. * * This will start a nested QEventLoop internally. Nested event loop can be dangerous and * can have unintended side effects, you should avoid calling exec() whenever you can and use the * asynchronous interface of KJob instead. * * Should you indeed call this method, you need to make sure that all callers are reentrant, * so that events delivered by the inner event loop don't cause non-reentrant functions to be * called, which usually wreaks havoc. * * Note that the event loop started by this method does not process user input events, which means * your user interface will effectivly be blocked. Other events like paint or network events are * still being processed. The advantage of not processing user input events is that the chance of * accidental reentrancy is greatly reduced. Still you should avoid calling this function. * * @return true if the job has been executed without error, false otherwise AHA!
The only other option is to do it asynchronously if that is what you mean. I think it is discouraged because it is a blocking operation. This wouldn't only be a problem if the gui was still active, but it isn't. Either the operation thread is broken off, or the operation never completes. I think the error might be further down the line.
Ryein Goddard, have you tested this for kdepim 16.04 also?
Your talking about the kdepim package in the kubuntu repos? I didn't have it installed, but I installed it and I didn't get any change.
kmail 5.2.3 still not loading GUI after a quit with "Empty Wastebin on Exit" set to on Qt: 5.6.1 KDE Frameworks: 5.24.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160712) (x86_64)" seems bugs 361679, 358216 are duplicates
I'm having the same issue with Fedora (24) ... KMail: 5.2.3 KDE Frameworks: 5.25.0 Qt 5.6.1 (built against 5.6.1) KDE Plasma: 5.25.0 Kernel: 4.6.6-300
(In reply to Fred Wells from comment #16) > I'm having the same issue with Fedora (24) ... > KMail: 5.2.3 > KDE Frameworks: 5.25.0 > Qt 5.6.1 (built against 5.6.1) > KDE Plasma: 5.25.0 > Kernel: 4.6.6-300 untick "Empty Wastebin on Exit" as this causes the problem. Log out or run up System Activity and kill the kmail process. its fixed in 5.3.0 but 5.3.0 has more serious issues at the moment which may be related to something else
Resolved upstream. Bug status should be changed.