Bug 173468

Summary: Crash when attempting to download a file with kget
Product: [Unmaintained] kdelibs Reporter: auxsvr
Component: generalAssignee: kdelibs bugs <kdelibs-bugs>
Status: RESOLVED DUPLICATE    
Severity: crash CC: echidnaman, sebastian
Priority: NOR    
Version: 4.1   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description auxsvr 2008-10-24 20:49:14 UTC
Version:            (using KDE 4.1.2)
Compiler:          gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] 
OS:                Linux
Installed from:    SuSE RPMs

I can reproduce this reliably with a specific file. The backtrace is:

Application: KGet (kget), signal SIGSEGV
[?1034h(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb60878e0 (LWP 14082)]
[KCrash handler]
#6  QUrl::host (this=0x60) at io/qurl.cpp:4247
#7  0xb7b217fb in searchIdleList (idleSlaves=@0x818e344, url=@0x60, 
    protocol=@0xbfa7d544, exact=@0xbfa7d5df)
    at /usr/src/debug/kdelibs-4.1.2/kio/kio/scheduler.cpp:609
#8  0xb7b25374 in KIO::SchedulerPrivate::findIdleSlave (this=0x818e2f0, 
    job=0x8188910, exact=@0xbfa7d5df)
    at /usr/src/debug/kdelibs-4.1.2/kio/kio/scheduler.cpp:683
#9  0xb7b25c6f in KIO::SchedulerPrivate::startJobDirect (this=0x818e2f0)
    at /usr/src/debug/kdelibs-4.1.2/kio/kio/scheduler.cpp:588
#10 0xb7b25e10 in KIO::SchedulerPrivate::startStep (this=0x818e2f0)
    at /usr/src/debug/kdelibs-4.1.2/kio/kio/scheduler.cpp:433
#11 0xb7b26076 in KIO::Scheduler::qt_metacall (this=0x83e37b0, 
    _c=QMetaObject::InvokeMetaMethod, _id=6, _a=0xbfa7d6c8)
    at /usr/src/debug/kdelibs-4.1.2/build/kio/scheduler.moc:101
#12 0xb7651730 in QMetaObject::activate (sender=0x818e2f4, 
    from_signal_index=4, to_signal_index=4, argv=0x0)
    at kernel/qobject.cpp:3031
#13 0xb76524b2 in QMetaObject::activate (sender=0x818e2f4, m=0xb7720904, 
    local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3101
#14 0xb768cbb7 in QTimer::timeout (this=0x818e2f4)
    at .moc/release-shared/moc_qtimer.cpp:126
#15 0xb76581ce in QTimer::timerEvent (this=0x818e2f4, e=0xbfa7db90)
    at kernel/qtimer.cpp:257
#16 0xb764c1ef in QObject::event (this=0x818e2f4, e=0xbfa7db90)
    at kernel/qobject.cpp:1120
#17 0xb681f82c in QApplicationPrivate::notify_helper (this=0x80bb868, 
    receiver=0x818e2f4, e=0xbfa7db90) at kernel/qapplication.cpp:3803
#18 0xb68276ce in QApplication::notify (this=0xbfa7de48, receiver=0x818e2f4, 
    e=0xbfa7db90) at kernel/qapplication.cpp:3393
#19 0xb7ea0e0d in KApplication::notify (this=0xbfa7de48, receiver=0x818e2f4, 
    event=0xbfa7db90)
    at /usr/src/debug/kdelibs-4.1.2/kdeui/kernel/kapplication.cpp:311
#20 0xb763ca61 in QCoreApplication::notifyInternal (this=0xbfa7de48, 
    receiver=0x818e2f4, event=0xbfa7db90) at kernel/qcoreapplication.cpp:587
#21 0xb766add6 in QTimerInfoList::activateTimers (this=0x80be6bc)
    at kernel/qcoreapplication.h:209
#22 0xb76672a0 in timerSourceDispatch (source=0x80be688)
    at kernel/qeventdispatcher_glib.cpp:160
#23 0xb61a52d9 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#24 0xb61a885b in ?? () from /usr/lib/libglib-2.0.so.0
#25 0xb61a89d8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#26 0xb76671f8 in QEventDispatcherGlib::processEvents (this=0x80bb050, flags=
      {i = -1079517896}) at kernel/qeventdispatcher_glib.cpp:319
#27 0xb68b8885 in QGuiEventDispatcherGlib::processEvents (this=0x80bb050, 
    flags={i = -1079517848}) at kernel/qguieventdispatcher_glib.cpp:198
#28 0xb763b13a in QEventLoop::processEvents (this=0xbfa7dde0, flags=
      {i = -1079517784}) at kernel/qeventloop.cpp:143
#29 0xb763b2fa in QEventLoop::exec (this=0xbfa7dde0, flags={i = -1079517720})
    at kernel/qeventloop.cpp:194
#30 0xb763d995 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:845
#31 0xb681f6a7 in QApplication::exec () at kernel/qapplication.cpp:3331
#32 0x0809616a in _start ()
#0  0xffffe430 in __kernel_vsyscall ()


Also, a valgrind trace:

==9572== Memcheck, a memory error detector.
==9572== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==9572== Using LibVEX rev 1804, a library for dynamic binary translation.
==9572== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==9572== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==9572== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==9572== For more details, rerun with: -v
==9572== 
==9572== My PID = 9572, parent PID = 5004.  Prog and args are:
==9572==    kget
==9572==    --nofork
==9572== 
==9572== Invalid read of size 4
==9572==    at 0x4F607E6: Soprano::FilterModel::addStatement(Soprano::Statement
const&) (filtermodel.cpp:92)
==9572==    by 0x4F48208:
Soprano::Model::addStatements(QList<Soprano::Statement> const&) (model.cpp:135)
==9572==    by 0x5014D1C:
Nepomuk::ResourceFilterModel::addStatements(QList<Soprano::Statement> const&)
(resourcefiltermodel.cpp:245)
==9572==    by 0x500BED3: Nepomuk::ResourceData::store() (resourcedata.cpp:285)
==9572==    by 0x500C4BA: Nepomuk::ResourceData::setProperty(QUrl const&,
Nepomuk::Variant const&) (resourcedata.cpp:370)
==9572==    by 0x5027A81: Nepomuk::Resource::setProperty(QUrl const&,
Nepomuk::Variant const&) (resource.cpp:227)
==9572==    by 0x43C2CA1: NepomukHandler::saveFileProperties(Nepomuk::Resource
const&) (in /usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43C2C37: NepomukHandler::saveFileProperties() (in
/usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43B1331: Transfer::setStatus(Job::Status, QString const&,
QPixmap const&) (in /usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43B24BE: Transfer::load(QDomElement const&) (in
/usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43B2CA0: Transfer::Transfer(TransferGroup*, TransferFactory*,
Scheduler*, KUrl const&, KUrl const&, QDomElement const*) (in
/usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x76F095A: (within /usr/lib/kde4/kget_kiofactory.so)
==9572==  Address 0x694e878 is 0 bytes inside a block of size 24 free'd
==9572==    at 0x402371A: operator delete(void*) (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9572==    by 0x500F722: Nepomuk::MainModel::~MainModel()
(nepomukmainmodel.cpp:173)
==9572==    by 0x500E667: Nepomuk::ResourceManager::init()
(resourcemanager.cpp:88)
==9572==    by 0x500E75F: Nepomuk::ResourceManager::mainModel()
(resourcemanager.cpp:227)
==9572==    by 0x500EA8E: Nepomuk::ResourceManager::generateUniqueUri()
(resourcemanager.cpp:206)
==9572==    by 0x5014C2A:
Nepomuk::ResourceFilterModel::addStatements(QList<Soprano::Statement> const&)
(resourcefiltermodel.cpp:236)
==9572==    by 0x500BED3: Nepomuk::ResourceData::store() (resourcedata.cpp:285)
==9572==    by 0x500C4BA: Nepomuk::ResourceData::setProperty(QUrl const&,
Nepomuk::Variant const&) (resourcedata.cpp:370)
==9572==    by 0x5027A81: Nepomuk::Resource::setProperty(QUrl const&,
Nepomuk::Variant const&) (resource.cpp:227)
==9572==    by 0x43C2CA1: NepomukHandler::saveFileProperties(Nepomuk::Resource
const&) (in /usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43C2C37: NepomukHandler::saveFileProperties() (in
/usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43B1331: Transfer::setStatus(Job::Status, QString const&,
QPixmap const&) (in /usr/lib/libkgetcore.so.4.1.0)
==9572== 
==9572== Jump to the invalid address stated on the next line
==9572==    at 0x0: ???
==9572==    by 0x4F48208:
Soprano::Model::addStatements(QList<Soprano::Statement> const&) (model.cpp:135)
==9572==    by 0x5014D1C:
Nepomuk::ResourceFilterModel::addStatements(QList<Soprano::Statement> const&)
(resourcefiltermodel.cpp:245)
==9572==    by 0x500BED3: Nepomuk::ResourceData::store() (resourcedata.cpp:285)
==9572==    by 0x500C4BA: Nepomuk::ResourceData::setProperty(QUrl const&,
Nepomuk::Variant const&) (resourcedata.cpp:370)
==9572==    by 0x5027A81: Nepomuk::Resource::setProperty(QUrl const&,
Nepomuk::Variant const&) (resource.cpp:227)
==9572==    by 0x43C2CA1: NepomukHandler::saveFileProperties(Nepomuk::Resource
const&) (in /usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43C2C37: NepomukHandler::saveFileProperties() (in
/usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43B1331: Transfer::setStatus(Job::Status, QString const&,
QPixmap const&) (in /usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43B24BE: Transfer::load(QDomElement const&) (in
/usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x43B2CA0: Transfer::Transfer(TransferGroup*, TransferFactory*,
Scheduler*, KUrl const&, KUrl const&, QDomElement const*) (in
/usr/lib/libkgetcore.so.4.1.0)
==9572==    by 0x76F095A: (within /usr/lib/kde4/kget_kiofactory.so)
==9572==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9572== 
==9572== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 68 from 4)
==9572== malloc/free: in use at exit: 2,520,345 bytes in 35,620 blocks.
==9572== malloc/free: 186,546 allocs, 150,926 frees, 109,236,341 bytes
allocated.
==9572== For counts of detected errors, rerun with: -v
==9572== searching for pointers to 35,620 not-freed blocks.
==9572== checked 23,063,100 bytes.
==9572== 
==9572== LEAK SUMMARY:
==9572==    definitely lost: 9,589 bytes in 365 blocks.
==9572==      possibly lost: 25,039 bytes in 957 blocks.
==9572==    still reachable: 2,485,717 bytes in 34,298 blocks.
==9572==         suppressed: 0 bytes in 0 blocks.
==9572== Rerun with --leak-check=full to see details of leaked memory.
Comment 1 auxsvr 2008-10-25 13:15:44 UTC
According to David Faure (comment 15 in #163171), this is a nepomuk/soprano crash.
Comment 2 Lukas Appelhans 2008-10-25 13:40:40 UTC
Well are u sure both Crashs are the same? It looks kind of different ;)

Lukas
Comment 3 auxsvr 2008-10-25 13:54:44 UTC
Are you talking about the valgrind vs gdb backtrace? If I don't attach valgrind, kget crashes with the gdb backtrace posted above. If I attach it, I get the valgrind output. I did this 3 times, it's 100% reproducible here. Also, it appears that every file download makes kget crash.
Comment 4 Lukas Appelhans 2008-10-25 14:19:18 UTC
Ok, well seems very much like a Soprano/Nepomuk issue...

Lukas
Comment 5 auxsvr 2008-10-25 18:54:58 UTC
Some more kget/kioslave crashes. If I turn on konqueror integration and click apply:

Application: KGet (kget), signal SIGSEGV
[?1034h(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb60998e0 (LWP 7511)]
[KCrash handler]
#6  0xb7664cf0 in QObject::disconnect (sender=0x822dc48, 
    signal=0x86a0901 "finished(KJob*)", receiver=0x81fd190, 
    method=0x85b0001 "unregisterJob(KJob*)") at kernel/qobject.cpp:2592
#7  0xb786ba6d in KJobTrackerInterface::unregisterJob (this=0x81fd190, 
    job=0x822dc48)
    at /usr/src/debug/kdelibs-4.1.2/kdecore/jobs/kjobtrackerinterface.cpp:82
#8  0xb7ea6054 in KAbstractWidgetJobTracker::unregisterJob (this=0x81fd190, 
    job=0x822dc48)
    at /usr/src/debug/kdelibs-4.1.2/kdeui/jobs/kabstractwidgetjobtracker.cpp:50
#9  0xb7ea8e8c in KWidgetJobTracker::unregisterJob (this=0x81fd190, 
    job=0x822dc48)
    at /usr/src/debug/kdelibs-4.1.2/kdeui/jobs/kwidgetjobtracker.cpp:93
#10 0xb7cf21a9 in ?? () from /usr/lib/libkgetcore.so.4
#11 0xb7cddd82 in KGet::reloadKJobs () from /usr/lib/libkgetcore.so.4
#12 0x0808f552 in _start ()
#0  0xffffe430 in __kernel_vsyscall ()

If I turn off konqueror integration and click apply:

Application: KGet (kget), signal SIGSEGV
[?1034h(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb60f78e0 (LWP 7521)]
[KCrash handler]
#6  0x00000001 in ?? ()
#7  0xb78c9a6d in KJobTrackerInterface::unregisterJob (this=0x8253af8, 
    job=0x8183e38)
    at /usr/src/debug/kdelibs-4.1.2/kdecore/jobs/kjobtrackerinterface.cpp:82
#8  0xb7f04054 in KAbstractWidgetJobTracker::unregisterJob (this=0x8253af8, 
    job=0x8183e38)
    at /usr/src/debug/kdelibs-4.1.2/kdeui/jobs/kabstractwidgetjobtracker.cpp:50
#9  0xb7f06e8c in KWidgetJobTracker::unregisterJob (this=0x8253af8, 
    job=0x8183e38)
    at /usr/src/debug/kdelibs-4.1.2/kdeui/jobs/kwidgetjobtracker.cpp:93
#10 0xb7d501a9 in ?? () from /usr/lib/libkgetcore.so.4
#11 0xb7d3bd82 in KGet::reloadKJobs () from /usr/lib/libkgetcore.so.4
#12 0x0808f552 in _start ()
#0  0xffffe430 in __kernel_vsyscall ()
Comment 6 Jonathan Thomas 2009-01-07 04:08:11 UTC

*** This bug has been marked as a duplicate of bug 163171 ***