Summary: | browserbenchmark "peacekeeper" causes crash in the first stage | ||
---|---|---|---|
Product: | [Unmaintained] kio | Reporter: | Fabian B. <apfelmausmail> |
Component: | general | Assignee: | webkit-devel |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | adawit, adjam7, floux.dp, k.siwczynski, kde, luizromario, pano_90, sml |
Priority: | NOR | ||
Version: | 4.4 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
screenshot
New crash information added by DrKonqi New crash information added by DrKonqi New crash information added by DrKonqi |
Description
Fabian B.
2010-02-21 16:22:43 UTC
Working on this. Thanks for the report.. I can reproduce this with latest rekonq from git, but also with Konqueror and the kdewebkit KPart. Since it doesn't crash in arora this most likely is a kdewebkit bug (In reply to comment #2) > I can reproduce this with latest rekonq from git, but also with Konqueror and > the kdewebkit KPart. Since it doesn't crash in arora this most likely is a > kdewebkit bug This is not a kdewebkit issue because #1. I cannot reproduce the crash with konqueror + kwebkitpart from trunk. However, there is no difference between the kdewebkit in trunk and the latest 4.4 branch. See attached screen shot. #2. The backtrace provided shows a crash in the ThreadWeaver library which indicates a multithreading related issue. Neither kdewebkit nor kwebkitpart are multi-threaded. If you have a backtrace for konqueror+kdewebkit, please provide it. Though I doubt this is at all a library bug (kdewebkit/qtwebkit), at least with such a backtrace I can eliminate whether or not this bug is caused by one of the few known crash conditions upstream that seem to have been addressed with the upcoming QtWebKit/2.0 release. Created attachment 43036 [details]
screenshot
Application: Konqueror (kdeinit4), signal: Segmentation fault [Current thread is 1 (Thread 0xb54c7970 (LWP 22552))] Thread 3 (Thread 0xb1e0ab70 (LWP 22553)): #0 0xb77ca424 in __kernel_vsyscall () #1 0xb5f44d31 in select () from /lib/libc.so.6 #2 0xb6c86aff in ?? () from /usr/lib/libQtCore.so.4 #3 0xb6baa44e in ?? () from /usr/lib/libQtCore.so.4 #4 0xb6b3194c in start_thread () from /lib/libpthread.so.0 #5 0xb5f4beae in clone () from /lib/libc.so.6 Thread 2 (Thread 0xadf54b70 (LWP 22603)): #0 0xb77ca424 in __kernel_vsyscall () #1 0xb6b35f35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4a62b57 in WTF::TCMalloc_PageHeap::scavengerThread() () from /usr/lib/libQtWebKit.so.4 #3 0xb4a62bad in WTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /usr/lib/libQtWebKit.so.4 #4 0xb6b3194c in start_thread () from /lib/libpthread.so.0 #5 0xb5f4beae in clone () from /lib/libc.so.6 Thread 1 (Thread 0xb54c7970 (LWP 22552)): [KCrash Handler] #6 0xb478b9db in ?? () from /usr/lib/libQtWebKit.so.4 #7 0xb478d2fb in ?? () from /usr/lib/libQtWebKit.so.4 #8 0xb6cb0e0a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #9 0xb6cbf3af in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #10 0xb6d0e727 in QIODevice::readyRead() () from /usr/lib/libQtCore.so.4 #11 0xb7200986 in ?? () from /usr/lib/libkio.so.5 #12 0xb7200aae in ?? () from /usr/lib/libkio.so.5 #13 0xb6cb0e0a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #14 0xb6cbf3af in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #15 0xb7236839 in KIO::TransferJob::data(KIO::Job*, QByteArray const&) () from /usr/lib/libkio.so.5 #16 0xb7239692 in KIO::TransferJob::slotData(QByteArray const&) () from /usr/lib/libkio.so.5 #17 0xb723d205 in KIO::TransferJob::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkio.so.5 #18 0xb6cb0e0a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #19 0xb6cbf3af in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #20 0xb7308c13 in KIO::SlaveInterface::data(QByteArray const&) () from /usr/lib/libkio.so.5 #21 0xb730bedf in KIO::SlaveInterface::dispatch(int, QByteArray const&) () from /usr/lib/libkio.so.5 #22 0xb7308fb3 in KIO::SlaveInterface::dispatch() () from /usr/lib/libkio.so.5 #23 0xb72fc498 in KIO::Slave::gotInput() () from /usr/lib/libkio.so.5 #24 0xb72fc6a3 in KIO::Slave::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkio.so.5 #25 0xb6cb0e0a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #26 0xb6cbf3af in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #27 0xb7207b07 in KIO::Connection::readyRead() () from /usr/lib/libkio.so.5 #28 0xb7209eae in ?? () from /usr/lib/libkio.so.5 #29 0xb7209fde in KIO::Connection::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkio.so.5 #30 0xb6cb0e0a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #31 0xb6cbb316 in QMetaCallEvent::placeMetaCall(QObject*) () from /usr/lib/libQtCore.so.4 #32 0xb6cbc3ee in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4 #33 0xb61f0eec in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #34 0xb61f7a3e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #35 0xb6f9e2ca in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #36 0xb6cabc0b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #37 0xb6cae5e3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4 #38 0xb6cae74d in QCoreApplication::sendPostedEvents(QObject*, int) () from /usr/lib/libQtCore.so.4 #39 0xb6cd7a0f in ?? () from /usr/lib/libQtCore.so.4 #40 0xb59cb895 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #41 0xb59cf568 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #42 0xb59cf748 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #43 0xb6cd7505 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #44 0xb62adab5 in ?? () from /usr/lib/libQtGui.so.4 #45 0xb6caa249 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #46 0xb6caa69a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #47 0xb6cae80f in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #48 0xb61f0f87 in QApplication::exec() () from /usr/lib/libQtGui.so.4 #49 0xb348fa9e in kdemain (argc=2, argv=0x94521c0) at /home/phil/kdemod/core/kdebase/src/kdebase-4.4.2/apps/konqueror/src/konqmain.cpp:271 #50 0x0804e119 in _start () Crashes 20 secs after starting the test. I'm installing the qt debug package, I'll post another backtrace soon. Application: Konqueror (kdeinit4), signal: Segmentation fault [Current thread is 1 (Thread 0xb54c7970 (LWP 22715))] Thread 2 (Thread 0xae854b70 (LWP 22749)): #0 0xb77ca424 in __kernel_vsyscall () #1 0xb6b35f35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4a62b57 in WTF::TCMalloc_PageHeap::scavengerThread() () from /usr/lib/libQtWebKit.so.4 #3 0xb4a62bad in WTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /usr/lib/libQtWebKit.so.4 #4 0xb6b3194c in start_thread () from /lib/libpthread.so.0 #5 0xb5f4beae in clone () from /lib/libc.so.6 Thread 1 (Thread 0xb54c7970 (LWP 22715)): [KCrash Handler] #6 0xb478b9db in ?? () from /usr/lib/libQtWebKit.so.4 #7 0xb478d2fb in ?? () from /usr/lib/libQtWebKit.so.4 #8 0xb6cb0e0a in QMetaObject::metacall (object=0x9909fb0, cl=2938786368, idx=7, argv=0xbfa4612c) at kernel/qmetaobject.cpp:237 #9 0xb6cbf3af in QMetaObject::activate (sender=0xa3c3b20, m=0xb6dbdda8, local_signal_index=0, argv=<value optimized out>) at kernel/qobject.cpp:3293 #10 0xb6d0e727 in QIODevice::readyRead (this=0xa3c3b20) at .moc/release-shared/moc_qiodevice.cpp:91 #11 0xb7200986 in KDEPrivate::AccessManagerReply::appendData (this=0xa3c3b20, kioJob=0x9c01f40, data=...) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kio/kio/accessmanagerreply_p.cpp:153 #12 0xb7200aae in KDEPrivate::AccessManagerReply::qt_metacall (this=0xa3c3b20, _c=QMetaObject::InvokeMetaMethod, _id=15, _a=0xbfa462a4) at /home/phil/kdemod/core/kdelibs/src/build/kio/accessmanagerreply_p.moc:81 #13 0xb6cb0e0a in QMetaObject::metacall (object=0xa3c3b20, cl=2938786368, idx=15, argv=0xbfa462a4) at kernel/qmetaobject.cpp:237 #14 0xb6cbf3af in QMetaObject::activate (sender=0x9c01f40, m=0xb73ea350, local_signal_index=0, argv=<value optimized out>) at kernel/qobject.cpp:3293 #15 0xb7236839 in KIO::TransferJob::data (this=0x9c01f40, _t1=0x9c01f40, _t2=...) at /home/phil/kdemod/core/kdelibs/src/build/kio/jobclasses.moc:388 #16 0xb7239692 in KIO::TransferJob::slotData (this=0x9c01f40, _data=...) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kio/kio/job.cpp:953 #17 0xb723d205 in KIO::TransferJob::qt_metacall (this=0x9c01f40, _c=QMetaObject::InvokeMetaMethod, _id=48, _a=0xbfa46438) at /home/phil/kdemod/core/kdelibs/src/build/kio/jobclasses.moc:368 #18 0xb6cb0e0a in QMetaObject::metacall (object=0x9c01f40, cl=2938786368, idx=48, argv=0xbfa46438) at kernel/qmetaobject.cpp:237 #19 0xb6cbf3af in QMetaObject::activate (sender=0xa46bd38, m=0xb73ecfc4, local_signal_index=0, argv=<value optimized out>) at kernel/qobject.cpp:3293 #20 0xb7308c13 in KIO::SlaveInterface::data (this=0xa46bd38, _t1=...) at /home/phil/kdemod/core/kdelibs/src/build/kio/slaveinterface.moc:146 #21 0xb730bedf in KIO::SlaveInterface::dispatch (this=0xa46bd38, _cmd=100, rawdata=...) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kio/kio/slaveinterface.cpp:163 #22 0xb7308fb3 in KIO::SlaveInterface::dispatch (this=0xa46bd38) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kio/kio/slaveinterface.cpp:91 #23 0xb72fc498 in KIO::Slave::gotInput (this=0xa46bd38) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kio/kio/slave.cpp:324 #24 0xb72fc6a3 in KIO::Slave::qt_metacall (this=0xa46bd38, _c=QMetaObject::InvokeMetaMethod, _id=30, _a=0xbfa4671c) at /home/phil/kdemod/core/kdelibs/src/build/kio/slave.moc:82 #25 0xb6cb0e0a in QMetaObject::metacall (object=0xa46bd38, cl=2938786368, idx=30, argv=0xbfa4671c) at kernel/qmetaobject.cpp:237 #26 0xb6cbf3af in QMetaObject::activate (sender=0xa46df90, m=0xb73e98a0, local_signal_index=0, argv=<value optimized out>) at kernel/qobject.cpp:3293 #27 0xb7207b07 in KIO::Connection::readyRead (this=0xa46df90) at /home/phil/kdemod/core/kdelibs/src/build/kio/connection.moc:92 #28 0xb7209eae in KIO::ConnectionPrivate::dequeue (this=0xa400a58) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kio/kio/connection.cpp:82 #29 0xb7209fde in KIO::Connection::qt_metacall (this=0xa46df90, _c=QMetaObject::InvokeMetaMethod, _id=5, _a=0x96e95e8) at /home/phil/kdemod/core/kdelibs/src/build/kio/connection.moc:79 #30 0xb6cb0e0a in QMetaObject::metacall (object=0xa46df90, cl=2938786368, idx=5, argv=0x96e95e8) at kernel/qmetaobject.cpp:237 #31 0xb6cbb316 in QMetaCallEvent::placeMetaCall (this=0x98e2560, object=0xa46df90) at kernel/qobject.cpp:561 #32 0xb6cbc3ee in QObject::event (this=0xa46df90, e=0x98e2560) at kernel/qobject.cpp:1248 #33 0xb61f0eec in QApplicationPrivate::notify_helper (this=0x948aa18, receiver=0xa46df90, e=0x98e2560) at kernel/qapplication.cpp:4304 #34 0xb61f7a3e in QApplication::notify (this=0xbfa471f4, receiver=0xa46df90, e=0x98e2560) at kernel/qapplication.cpp:3708 #35 0xb6f9e2ca in KApplication::notify (this=0xbfa471f4, receiver=0xa46df90, event=0x98e2560) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kdeui/kernel/kapplication.cpp:302 #36 0xb6cabc0b in QCoreApplication::notifyInternal (this=0xbfa471f4, receiver=0xa46df90, event=0x98e2560) at kernel/qcoreapplication.cpp:704 #37 0xb6cae5e3 in QCoreApplication::sendEvent (receiver=0x0, event_type=0, data=0x93fb858) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215 #38 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x93fb858) at kernel/qcoreapplication.cpp:1345 #39 0xb6cae74d in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1238 #40 0xb6cd7a0f in QCoreApplication::sendPostedEvents (s=0x948cd10) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220 #41 postEventSourceDispatch (s=0x948cd10) at kernel/qeventdispatcher_glib.cpp:276 #42 0xb59cb895 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #43 0xb59cf568 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #44 0xb59cf748 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #45 0xb6cd7505 in QEventDispatcherGlib::processEvents (this=0x93fc330, flags=...) at kernel/qeventdispatcher_glib.cpp:412 #46 0xb62adab5 in QGuiEventDispatcherGlib::processEvents (this=0x93fc330, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #47 0xb6caa249 in QEventLoop::processEvents (this=0xbfa46fd4, flags=) at kernel/qeventloop.cpp:149 #48 0xb6caa69a in QEventLoop::exec (this=0xbfa46fd4, flags=...) at kernel/qeventloop.cpp:201 #49 0xb6cae80f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981 #50 0xb61f0f87 in QApplication::exec () at kernel/qapplication.cpp:3583 #51 0xb348fa9e in kdemain (argc=2, argv=0x94521c0) at /home/phil/kdemod/core/kdebase/src/kdebase-4.4.2/apps/konqueror/src/konqmain.cpp:271 #52 0x0804e119 in launch (argc=<value optimized out>, _name=<value optimized out>, args=<value optimized out>, cwd=0x0, envc=0, envs=0x947c4c4 "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x947c4c8 "arch;1272229985;789124;2913_TIME46797971") at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kinit/kinit.cpp:717 #53 0x0804ea05 in handle_launcher_request (sock=<value optimized out>, who=<value optimized out>) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kinit/kinit.cpp:1209 #54 0x0804eff4 in handle_requests (waitForPid=<value optimized out>) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kinit/kinit.cpp:1402 #55 0x0804f857 in main (argc=4, argv=0xbfa47e94, envp=0xbfa47ea8) at /home/phil/kdemod/core/kdelibs/src/kdelibs-4.4.2/kinit/kinit.cpp:1845 new backtrace, I hope it helps And these backtraces are from the same system as originally reported on the bug ? That is the same KDE and Qt versions ? Anyhow, it is curious why I am unable to duplicate the crash with KDE 4.4.70 and standard Qt 4.6.2 package from my distro, i.e. the older QtWebKit bundled with 4.6.x. There is no kdewebkit change from 4.4 to 4.5 except for the renaming of kwebviewprivate_p.h to kwebview_p.h. In my system (KDE 4.4 from branches, Qt 4.6.2, rekonq git master) rekonq crashes every time in the peacekeeper test. konqueror never (Also if it "fails" the test, 50% of the times). Arora "wins" every time. So, I'm quite sure this is NOT a *webkit issue but a KIO one. Moreover, launching rekonq from the terminal, we have these "strange" messages (possibly related to this problem), that I never see in konqueror (khtml or webkit): rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished: KIO::TransferJob(0xae7cc28) KIO::Slave(0xad219c8) rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::cancelJob: Doing nothing because I don't know job KIO::TransferJob(0xae7cc28) rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished: KIO::TransferJob(0xae80668) KIO::Slave(0xaca1168) rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::cancelJob: Doing nothing because I don't know job KIO::TransferJob(0xae80668) So, without having read 1 line of code about yet, situation seems the following: - kio::scheduler doesn't "know" rekonq requests, while "knows" konqueror's ones. - (going ahead with imagination..) - in "heavy load" situations (such the peacekeeper test is) this lets kio-rekonq use something forbidden (or just deleted). And crash! Ok, sorry for the last lines. :) Time to start "KIO investigation".. (In reply to comment #8) > In my system (KDE 4.4 from branches, Qt 4.6.2, rekonq git master) rekonq > crashes every time in the peacekeeper test. konqueror never (Also if it "fails" > the test, 50% of the times). Arora "wins" every time. > So, I'm quite sure this is NOT a *webkit issue but a KIO one. Moreover, > launching rekonq from the terminal, we have these "strange" messages (possibly > related to this problem), that I never see in konqueror (khtml or webkit): Well if you use multi-threading in your application and somehow access a kio job generated in one thread from a completely different one, you can indeed have unexecpted crashe. You should actually check to see if you get "KIO is not thread-safe." warning message in your .xsession-error or X.err files or on the command line where you started it. > rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished: > KIO::TransferJob(0xae7cc28) KIO::Slave(0xad219c8) > rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::cancelJob: Doing nothing > because I don't know job KIO::TransferJob(0xae7cc28) > rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished: > KIO::TransferJob(0xae80668) KIO::Slave(0xaca1168) > rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::cancelJob: Doing nothing > because I don't know job KIO::TransferJob(0xae80668) I get that a lot too with Konqueror + kwebkitpart. It is benign and you can ignore it. It seems to be debug statement that comes from a sanity check to prevent multiple deletion of an already deleted ioslave... > So, without having read 1 line of code about yet, situation seems the > following: > - kio::scheduler doesn't "know" rekonq requests, while "knows" konqueror's > ones. I am not familiar with the new scheduler code because it has been re-written for KDE 4.5 by Andreas, but the above statement does not make any sense if you look at the code. You can effectively ignore the bogus/unclear debug for the reasons I stated above. Anyhow, it is entirely possible the bug stems from this scheduler rewrite. With all the new functionality and features added to it, the schduler has become more complicated than it was... More complications/features almost always by definition entails the introduction of new bugs. I know because I have been stuck fixing a lot of bugs in kio_http which was re-written for KDE 4. > - (going ahead with imagination..) > - in "heavy load" situations (such the peacekeeper test is) this lets > kio-rekonq use something forbidden (or just deleted). And crash! Doubt it. It is more likely caused by something else. Like accessing the same KIO job from multiple thread for example. However, no matter what I do here, I cannot duplicate the crash at all and the test finishes completely. I will retest > Ok, sorry for the last lines. :) > Time to start "KIO investigation".. Can you try to comment out the deprecated KIO::Scheduler::scheduleJob(...) from KIO::AccessManager::createRequest and see if that makes any difference in your case ? I doubt it, but never hurts to try... On Monday 26 April 2010 01:56:33 Dawit Alemayehu wrote: > https://bugs.kde.org/show_bug.cgi?id=227947 > > ... > > > rekonq(2259)/kio (Scheduler) KIO::SchedulerPrivate::cancelJob: Doing > > nothing because I don't know job KIO::TransferJob(0xae80668) > > I get that a lot too with Konqueror + kwebkitpart. It is benign and you can > ignore it. It seems to be debug statement that comes from a sanity check to > prevent multiple deletion of an already deleted ioslave... Ok, thanks for info. > > So, without having read 1 line of code about yet, situation seems the > > following: > > - kio::scheduler doesn't "know" rekonq requests, while "knows" > > konqueror's ones. > > I am not familiar with the new scheduler code because it has been > re-written for KDE 4.5 by Andreas, but the above statement does not make > any sense if you look at the code. You can effectively ignore the > bogus/unclear debug for the reasons I stated above. Anyhow, it is entirely > possible the bug stems from this scheduler rewrite. With all the new > functionality and features added to it, the schduler has become more > complicated than it was... More complications/features almost always by > definition entails the introduction of new bugs. I know because I have > been stuck fixing a lot of bugs in kio_http which was re-written for KDE > 4. I'm not familiar with KIO code at all. And I have to say it's really difficult to understand and debug. > Can you try to comment out the deprecated KIO::Scheduler::scheduleJob(...) > from KIO::AccessManager::createRequest and see if that makes any > difference in your case ? I doubt it, but never hurts to try... Sure. Thanks for hints and feedback. Regards, Infos about first testing: 1) commenting out the KIO::scheduler() line in KIO::AccessManager code (kdelibs trunk) creates a deadlock. rekonq does nothing on peacekeeper test, while KIO continues to create (and create, and create) get actions. 2) reverting rekonq to QNetworkAccessManager let it perform quite well the test. So, this is definitely a KIO bug. Moving it there. Created attachment 43489 [details]
New crash information added by DrKonqi
I was doing some peacekeeper test and rekonq just crashed.
Created attachment 43931 [details]
New crash information added by DrKonqi
Rekonq crashed on Peacekeeper on its first stage.
Besides, I noticed that, before the crash, the tests were running painfully slowly.
*** Bug 238957 has been marked as a duplicate of this bug. *** Same for me. Here's the backtrace: (gdb) run Starting program: /usr/bin/rekonq --nofork [Thread debugging using libthread_db enabled] [New Thread 0x7fffe565e710 (LWP 1658)] [New Thread 0x7fffe384f710 (LWP 1659)] [New Thread 0x7fffe2697710 (LWP 1660)] rekonq(1655)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: [New Thread 0x7fffe1e96710 (LWP 1661)] [Thread 0x7fffe1e96710 (LWP 1661) exited] QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Nessun file o directory [New Thread 0x7fffe1e96710 (LWP 1663)] QFileSystemWatcher: failed to add paths: /home/test/.config/ibus/bus Bus::open: Can not get ibus-daemon's address. IBusInputContext::createInputContext: no connection to ibus-daemon [New Thread 0x7fffdd9ad710 (LWP 1671)] [New Thread 0x7fffdd1ac710 (LWP 1672)] [New Thread 0x7fffdc389710 (LWP 1674)] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff70ac709 in WebCore::QNetworkReplyHandler::forwardData (this=0x3f2faf0) at platform/network/qt/QNetworkReplyHandler.cpp:391 391 platform/network/qt/QNetworkReplyHandler.cpp: Nessun file o directory. in platform/network/qt/QNetworkReplyHandler.cpp (gdb) bt #0 0x00007ffff70ac709 in WebCore::QNetworkReplyHandler::forwardData (this=0x3f2faf0) at platform/network/qt/QNetworkReplyHandler.cpp:391 #1 0x00007ffff70adfb4 in WebCore::QNetworkReplyHandler::qt_metacall (this=0x3f2faf0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffffffc8a0) at ./moc_QNetworkReplyHandler.cpp:86 #2 0x00007ffff322d597 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #3 0x00007ffff5abec37 in ?? () from /usr/lib/libkio.so.5 #4 0x00007ffff322d597 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #5 0x00007ffff5af2f54 in KIO::TransferJob::data(KIO::Job*, QByteArray const&) () from /usr/lib/libkio.so.5 #6 0x00007ffff5af5700 in KIO::TransferJob::slotData(QByteArray const&) () from /usr/lib/libkio.so.5 #7 0x00007ffff5af94c6 in KIO::TransferJob::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkio.so.5 #8 0x00007ffff322d597 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #9 0x00007ffff5ba6942 in KIO::SlaveInterface::data(QByteArray const&) () from /usr/lib/libkio.so.5 #10 0x00007ffff5ba9925 in KIO::SlaveInterface::dispatch(int, QByteArray const&) () from /usr/lib/libkio.so.5 #11 0x00007ffff5ba6bf3 in KIO::SlaveInterface::dispatch() () from /usr/lib/libkio.so.5 #12 0x00007ffff5b9a7a6 in KIO::Slave::gotInput() () from /usr/lib/libkio.so.5 #13 0x00007ffff5b9a98c in KIO::Slave::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkio.so.5 #14 0x00007ffff322d597 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #15 0x00007ffff5ac8207 in ?? () from /usr/lib/libkio.so.5 #16 0x00007ffff5ac832d in KIO::Connection::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkio.so.5 #17 0x00007ffff322766e in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4 #18 0x00007ffff392784c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #19 0x00007ffff392d2ed in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #20 0x00007ffff55dcd86 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #21 0x00007ffff321587c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #22 0x00007ffff32187a2 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4 #23 0x00007ffff3241e33 in ?? () from /usr/lib/libQtCore.so.4 #24 0x00007fffeebac0f2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #25 0x00007fffeebaff78 in ?? () from /lib/libglib-2.0.so.0 #26 0x00007fffeebb012c in g_main_context_iteration () from /lib/libglib-2.0.so.0 #27 0x00007ffff3241973 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #28 0x00007ffff39d8dfe in ?? () from /usr/lib/libQtGui.so.4 #29 0x00007ffff32145b2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #30 0x00007ffff321498c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #31 0x00007ffff3218a3b in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #32 0x00007ffff7bb8902 in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_rekonq.so #33 0x00007ffff25a2d8d in __libc_start_main () from /lib/libc.so.6 #34 0x00000000004007b9 in _start () (gdb) *** Bug 243661 has been marked as a duplicate of this bug. *** Created attachment 49826 [details]
New crash information added by DrKonqi
rekonq (0.5.53) on KDE Platform 4.5.00 (KDE 4.5.0) using Qt 4.7.0
- What I was doing when the application crashed:
just testing another time the peacekeeper test. I checked the backtrace and think it can be useful.
-- Backtrace (Reduced):
#10 0xb704631c in QIODevice::readyRead() () from /opt/qt/lib/libQtCore.so.4
#11 0xb5a6a00f in KDEPrivate::AccessManagerReply::appendData (this=0xa8ec270, kioJob=0xa8ec348, data=...) at /tmp/build-kdelibs/kdelibs/kio/kio/accessmanagerreply_p.cpp:168
#12 0xb5a6a08d in KDEPrivate::AccessManagerReply::qt_metacall (this=0xa8ec270, _c=QMetaObject::InvokeMetaMethod, _id=15, _a=0xbfd96d04)
at /tmp/build-kdelibs/kdelibs/build/kio/accessmanagerreply_p.moc:81
[...]
[...]
#15 0xb5a9c464 in KIO::TransferJob::data (this=0xa8ec348, _t1=0xa8ec348, _t2=...) at /tmp/build-kdelibs/kdelibs/build/kio/jobclasses.moc:388
#16 0xb5a9f792 in KIO::TransferJob::slotData (this=0xa8ec348, _data=...) at /tmp/build-kdelibs/kdelibs/kio/kio/job.cpp:1003
*** This bug has been marked as a duplicate of bug 248880 *** |