Bug 351686

Summary: After using Knotes, Kontakt crashes after reopening following to riduction to icon
Product: [Applications] kontact Reporter: stakanov.s
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED UNMAINTAINED    
Severity: crash CC: kde.bugzilla.2012, kde, kdenis, stakanov.s
Priority: NOR Keywords: drkonqi
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: New crash information added by DrKonqi
New crash information added by DrKonqi

Description stakanov.s 2015-08-24 10:32:53 UTC
Application: kontact (4.14.9)
KDE Platform Version: 4.14.9
Qt Version: 4.8.6
Operating System: Linux 4.1.6-2.gce0123d-desktop x86_64
Distribution: "openSUSE 13.2 (Harlequin) (x86_64)"

-- Information about the crash:
- What I was doing when the application crashed:
reopening minimized Kontact
- Unusual behavior I noticed:
I used before the Knotes plugin. i have noticed that the use of plugins currently seems prejudical to kontakt. When trying to use task you run into problems with the database and Kontakt does not open anymore, now this crash comes after using knotes within kontakt. 

Application opens after clicking on the start menu icon (after having been closed but open in the tray). It crashes immediately. 

I have not yet tried if Knotes gives this repeatedly, however I hope the output gives you some interesting info. 

Opensuse 13.2 from repo.

-- Backtrace:
Application: Kontact (kontact), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f7cf8344800 (LWP 2866))]

Thread 5 (Thread 0x7f7cda9aa700 (LWP 2892)):
#0  0x00007f7cef94a05f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7cf30f0686 in WTF::TCMalloc_PageHeap::scavengerThread() () from /usr/lib64/libQtWebKit.so.4
#2  0x00007f7cf30f06b9 in WTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /usr/lib64/libQtWebKit.so.4
#3  0x00007f7cef9460a4 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f7cf58d308d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f7c9a08f700 (LWP 2911)):
#0  0x00007f7cef94a05f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7cf2e62e7d in JSC::BlockAllocator::blockFreeingThreadMain() () from /usr/lib64/libQtWebKit.so.4
#2  0x00007f7cf31181e6 in WTF::wtfThreadEntryPoint(void*) () from /usr/lib64/libQtWebKit.so.4
#3  0x00007f7cef9460a4 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f7cf58d308d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f7c8ab2f700 (LWP 2921)):
#0  0x00007f7cf58cac5d in poll () from /lib64/libc.so.6
#1  0x00007f7cef37abe4 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7cef37acec in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7cf604d0de in QEventDispatcherGlib::processEvents (this=0x7f7c840008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452
#4  0x00007f7cf601ee6f in QEventLoop::processEvents (this=this@entry=0x7f7c8ab2ede0, flags=...) at kernel/qeventloop.cpp:149
#5  0x00007f7cf601f165 in QEventLoop::exec (this=this@entry=0x7f7c8ab2ede0, flags=...) at kernel/qeventloop.cpp:204
#6  0x00007f7cf5f1c0bf in QThread::exec (this=<optimized out>) at thread/qthread.cpp:538
#7  0x00007f7cf5f1e79f in QThreadPrivate::start (arg=0xf28140) at thread/qthread_unix.cpp:349
#8  0x00007f7cef9460a4 in start_thread () from /lib64/libpthread.so.0
#9  0x00007f7cf58d308d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f7c88b48700 (LWP 2932)):
#0  0x00007f7cf58cac5d in poll () from /lib64/libc.so.6
#1  0x00007f7cef37abe4 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7cef37acec in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7cf604d0de in QEventDispatcherGlib::processEvents (this=0x7f7c7c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452
#4  0x00007f7cf601ee6f in QEventLoop::processEvents (this=this@entry=0x7f7c88b47da0, flags=...) at kernel/qeventloop.cpp:149
#5  0x00007f7cf601f165 in QEventLoop::exec (this=this@entry=0x7f7c88b47da0, flags=...) at kernel/qeventloop.cpp:204
#6  0x00007f7cf5f1c0bf in QThread::exec (this=this@entry=0x2176490) at thread/qthread.cpp:538
#7  0x00007f7cf6000783 in QInotifyFileSystemWatcherEngine::run (this=0x2176490) at io/qfilesystemwatcher_inotify.cpp:265
#8  0x00007f7cf5f1e79f in QThreadPrivate::start (arg=0x2176490) at thread/qthread_unix.cpp:349
#9  0x00007f7cef9460a4 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f7cf58d308d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f7cf8344800 (LWP 2866)):
[KCrash Handler]
#6  0x00007f7cf5823187 in raise () from /lib64/libc.so.6
#7  0x00007f7cf5824538 in abort () from /lib64/libc.so.6
#8  0x00007f7cf5f142b4 in qt_message_output (msgType=msgType@entry=QtFatalMsg, buf=<optimized out>) at global/qglobal.cpp:2359
#9  0x00007f7cf5f14439 in qt_message(QtMsgType, const char *, typedef __va_list_tag __va_list_tag *) (msgType=msgType@entry=QtFatalMsg, msg=0x7f7c8f8ec1a8 "Fatal Error: Accessed global static '%s *%s()' after destruction. Defined at %s:%d", ap=ap@entry=0x7fff58ab82d8) at global/qglobal.cpp:2405
#10 0x00007f7cf5f14c44 in qFatal (msg=<optimized out>) at global/qglobal.cpp:2588
#11 0x00007f7c8f837d84 in operator-> (this=<optimized out>) at /usr/src/debug/kdepim-4.14.9/mailcommon/kernel/mailkernel.cpp:58
#12 MailCommon::Kernel::self () at /usr/src/debug/kdepim-4.14.9/mailcommon/kernel/mailkernel.cpp:75
#13 0x00007f7c8f87fec0 in MailCommon::FolderCollection::writeConfig (this=this@entry=0x1c6ab60) at /usr/src/debug/kdepim-4.14.9/mailcommon/folder/foldercollection.cpp:218
#14 0x00007f7c8f8806c2 in MailCommon::FolderCollection::~FolderCollection (this=0x1c6ab60, __in_chrg=<optimized out>) at /usr/src/debug/kdepim-4.14.9/mailcommon/folder/foldercollection.cpp:84
#15 0x00007f7c8f880739 in MailCommon::FolderCollection::~FolderCollection (this=0x1c6ab60, __in_chrg=<optimized out>) at /usr/src/debug/kdepim-4.14.9/mailcommon/folder/foldercollection.cpp:86
#16 0x00007f7c8f87eff4 in deref (value=0x1c6ab60, d=0x1bd5a00) at /usr/include/QtCore/qsharedpointer_impl.h:342
#17 deref (this=<optimized out>) at /usr/include/QtCore/qsharedpointer_impl.h:336
#18 ~ExternalRefCount (this=<optimized out>, __in_chrg=<optimized out>) at /usr/include/QtCore/qsharedpointer_impl.h:401
#19 ~QSharedPointer (this=<optimized out>, __in_chrg=<optimized out>) at /usr/include/QtCore/qsharedpointer_impl.h:466
#20 QMap<long long, QSharedPointer<MailCommon::FolderCollection> >::freeData (x=0x1c67380, this=<optimized out>) at /usr/include/QtCore/qmap.h:652
#21 0x00007f7cf5825bf9 in __run_exit_handlers () from /lib64/libc.so.6
#22 0x00007f7cf5825c45 in exit () from /lib64/libc.so.6
#23 0x00007f7cf64c3c6b in KCmdLineArgs::isSet (this=0x38c18c0, _opt=...) at /usr/src/debug/kdelibs-4.14.9/kdecore/kernel/kcmdlineargs.cpp:1520
#24 0x0000000000404087 in _start ()

Possible duplicates by query: bug 350570, bug 345895, bug 335457, bug 330850, bug 328224.

Reported using DrKonqi
Comment 1 Allen Winter 2015-09-26 14:36:17 UTC
*** Bug 352801 has been marked as a duplicate of this bug. ***
Comment 2 stakanov.s 2015-12-25 09:43:31 UTC
Created attachment 96294 [details]
New crash information added by DrKonqi

kontact (4.14.9) on KDE Platform 4.14.9 using Qt 4.8.6

- What I was doing when the application crashed:
signing a mail with a "cryptokey"

- Unusual behavior I noticed:
closing kontakt after sending it crashed. 
I attached this because I think it could be interesting if connected to the use of crytohardware with email sending. 
Sorry if this should be redundant. 

Cryptografic hardware was Cryptokey 1.2 (look at www.nitrokey.com for further details).

-- Backtrace (Reduced):
#11 0x00007f0c29419d84 in operator-> (this=<optimized out>) at /usr/src/debug/kdepim-4.14.9/mailcommon/kernel/mailkernel.cpp:58
#12 MailCommon::Kernel::self () at /usr/src/debug/kdepim-4.14.9/mailcommon/kernel/mailkernel.cpp:75
#13 0x00007f0c29461ec0 in MailCommon::FolderCollection::writeConfig (this=this@entry=0x1950050) at /usr/src/debug/kdepim-4.14.9/mailcommon/folder/foldercollection.cpp:218
#14 0x00007f0c294626c2 in MailCommon::FolderCollection::~FolderCollection (this=0x1950050, __in_chrg=<optimized out>) at /usr/src/debug/kdepim-4.14.9/mailcommon/folder/foldercollection.cpp:84
#15 0x00007f0c29462739 in MailCommon::FolderCollection::~FolderCollection (this=0x1950050, __in_chrg=<optimized out>) at /usr/src/debug/kdepim-4.14.9/mailcommon/folder/foldercollection.cpp:86
Comment 3 sedrubal 2016-01-21 15:10:16 UTC
Created attachment 96767 [details]
New crash information added by DrKonqi

kontact (4.14.10) on KDE Platform 4.14.14 using Qt 4.8.7

- What I was doing when the application crashed:

Kontact war running, I closed it by clicking on the window 'x' -> kmail runs in background. I have a keyboard shortcut for starting kontact. I hit this shortcut and kontact crashed. Usually this works...

-- Backtrace (Reduced):
#11 0x00007f6ff8133a87 in MailCommon::Kernel::self() () at /lib64/libmailcommon.so.4
#12 0x00007f6ff8187f43 in MailCommon::FolderCollection::writeConfig() const () at /lib64/libmailcommon.so.4
#13 0x00007f6ff81887f2 in MailCommon::FolderCollection::~FolderCollection() () at /lib64/libmailcommon.so.4
#14 0x00007f6ff8188869 in MailCommon::FolderCollection::~FolderCollection() () at /lib64/libmailcommon.so.4
#16 0x00007f7065fdd658 in __run_exit_handlers () at /lib64/libc.so.6
Comment 4 Denis Kurz 2017-06-23 20:58:16 UTC
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks, except possibly a Technology Preview version 5.0.x. Those Framework-based versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the opportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Comment 5 Denis Kurz 2018-02-01 09:47:00 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12; preferably much more recent), please open a new one unless it already exists. Thank you for all your input.