Bug 305626

Summary: Crash related to KMail's MessageList
Product: [Unmaintained] nepomuk Reporter: Allen Winter <winter>
Component: libnepomukcoreAssignee: Nepomuk Bugs Coordination <nepomuk-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: faure, me
Priority: NOR    
Version: git master   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: kmail backtrace showing a crash in Nepomuk2::ResourceWatcher

Description Allen Winter 2012-08-22 18:57:14 UTC
I will attach the backtrace for a crash I got while running KMail (in Kontact) this morning.

Reproducible: Sometimes
Comment 1 Allen Winter 2012-08-22 18:58:17 UTC
Created attachment 73396 [details]
kmail backtrace showing a crash in Nepomuk2::ResourceWatcher
Comment 2 Vishesh Handa 2012-09-25 11:11:22 UTC
Pasting relevant backtrace. Easier to read in the bug report - 

Program terminated with signal 6, Aborted.
#0  0x00000038d940eebb in raise () from /lib64/libpthread.so.0
#0  0x00000038d940eebb in raise () from /lib64/libpthread.so.0
#1  0x00007f438de7243f in KCrash::defaultCrashHandler (sig=6) at /data/kde/trunk/KDE/kdelibs/kdeui/util/kcrash.cpp:346
#2  <signal handler called>
#3  0x00000038d8835925 in raise () from /lib64/libc.so.6
#4  0x00000038d88370d8 in abort () from /lib64/libc.so.6
#5  0x00007f438d10c333 in qt_message_output (msgType=QtFatalMsg, buf=0x6b8a9f8 "ASSERT: \"d->ref == 1\" in file tools/qlist.cpp, line 233") at global/qglobal.cpp:2266
#6  0x00007f438d10c4af in qt_message(QtMsgType, const char *, typedef __va_list_tag __va_list_tag *) (msgType=QtFatalMsg, msg=0x7f438d2d9868 "ASSERT: \"%s\" in file %s, line %d", ap=0x7fff95a23ee8) at global/qglobal.cpp:2312
#7  0x00007f438d10cc79 in qFatal (msg=0x7f438d2d9868 "ASSERT: \"%s\" in file %s, line %d") at global/qglobal.cpp:2495
#8  0x00007f438d10beec in qt_assert (assertion=0x7f438d2dd6a8 "d->ref == 1", file=0x7f438d2dd698 "tools/qlist.cpp", line=233) at global/qglobal.cpp:2013
#9  0x00007f438d14095e in QListData::append (this=0x10e8158, n=1) at tools/qlist.cpp:233
#10 0x00007f438d140a91 in QListData::append (this=0x10e8158) at tools/qlist.cpp:253
#11 0x00007f4387f5b890 in QList<QUrl>::append (this=0x10e8158, t=...) at /data/Qt/Qt-4.8/include/QtCore/qlist.h:530
#12 0x00007f4387f5d5fd in QList<QUrl>::operator<< (this=0x10e8158, t=...) at /data/Qt/Qt-4.8/include/QtCore/qlist.h:334
#13 0x00007f4387fc3486 in Nepomuk2::ResourceWatcher::addResource (this=0x1356080, res=...) at /data/kde/trunk/KDE/nepomuk-core/libnepomukcore/datamanagement/resourcewatcher.cpp:162
#14 0x00007f4387fc4bc1 in Nepomuk2::ResourceWatcher::qt_static_metacall (_o=0x1356080, _c=QMetaObject::InvokeMetaMethod, _id=8, _a=0x7fff95a24220) at /data/kde/trunk/KDE/nepomuk-core/build-master-gcc/libnepomukcore/resourcewatcher.moc:123
#15 0x00007f438d25fb02 in QMetaMethod::invoke (this=0x7fff95a246a0, object=0x1356080, connectionType=Qt::DirectConnection, returnValue=..., val0=..., val1=..., val2=..., val3=..., val4=..., val5=..., val6=..., val7=..., val8=..., val9=...) at kernel/qmetaobject.cpp:1664
#18 0x00007f4387f6938d in Nepomuk2::ResourceData::addToWatcher (this=0x6832e40) at /data/kde/trunk/KDE/nepomuk-core/libnepomukcore/resource/resourcedata.cpp:332
#19 0x00007f4387f69645 in Nepomuk2::ResourceData::load (this=0x6832e40) at /data/kde/trunk/KDE/nepomuk-core/libnepomukcore/resource/resourcedata.cpp:347
Comment 3 David Faure 2012-10-17 11:25:18 UTC
Fixed in Qt 4.8.3


commit c3fe37fe18961d3ddb050fc788281eb79bc61d7a
Author: David Faure <faure@kde.org>
Date:   Sat Jul 14 00:39:18 2012 +0200

    QUrl: fix thread safety.
    
    Developers expect const methods on the same QUrl instance to be usable
    from multiple threads (including copying and modifying the copy).
    The delayed parsing and internal cache of encoded strings break this, however
    (and the implicit sharing, for the case of copying).
    Protection with a mutex fixes this.
    
    Qt-5.0 doesn't have this issue, since QUrl doesn't do delayed parsing
    anymore.
    
    Change-Id: Ie2674e46eb7416b0e753323b673c10f9d3457f6d
    Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
    Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>