Bug 363085

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.