Bug 227947 - browserbenchmark "peacekeeper" causes crash in the first stage
Summary: browserbenchmark "peacekeeper" causes crash in the first stage
Status: RESOLVED DUPLICATE of bug 248880
Alias: None
Product: kio
Classification: Unmaintained
Component: general (show other bugs)
Version: 4.4
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: webkit-devel
URL:
Keywords:
: 238957 243661 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-02-21 16:22 UTC by Fabian B.
Modified: 2010-08-24 11:30 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screenshot (422.92 KB, image/png)
2010-04-25 23:03 UTC, Dawit Alemayehu
Details
New crash information added by DrKonqi (9.76 KB, text/plain)
2010-05-11 22:01 UTC, Konrad Siwczyński
Details
New crash information added by DrKonqi (14.07 KB, text/plain)
2010-05-27 01:30 UTC, Romário Rios
Details
New crash information added by DrKonqi (18.51 KB, text/plain)
2010-08-05 11:04 UTC, Andrea Diamantini
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian B. 2010-02-21 16:22:43 UTC
Application: rekonq (0.3.94)
KDE Platform Version: 4.4.00 (KDE 4.4.0)
Qt Version: 4.6.1
Operating System: Linux 2.6.32-14-generic i686
Distribution: Ubuntu lucid (development branch)

-- Information about the crash:
just go to the site http://service.futuremark.com/peacekeeper/index.action and klick "Benchmark Your Browser". First rekonq will  freeze for a while, next it run the test 1-20 secs and finally rekonq crash ( rekonq daily from https://launchpad.net/~rekonq/+archive/rekonq )

The crash can be reproduced every time.

 -- Backtrace:
Application: rekonq (kdeinit4), signal: Segmentation fault
[Current thread is 1 (Thread 0xb77ed760 (LWP 4668))]

Thread 6 (Thread 0xb61b4b70 (LWP 4669)):
#0  0x00c23422 in __kernel_vsyscall ()
#1  0x03384cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0x03384ad1 in sleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x082c2e30 in WTF::TCMalloc_PageHeap::scavengerThread (this=0x9076dc0) at ../JavaScriptCore/wtf/FastMalloc.cpp:2303
#4  0x082c2ef1 in WTF::TCMalloc_PageHeap::runScavengerThread (context=0x9076dc0) at ../JavaScriptCore/wtf/FastMalloc.cpp:1433
#5  0x009ac8de in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6  0x033ba95e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 5 (Thread 0xb5827b70 (LWP 4670)):
#0  0x00c23422 in __kernel_vsyscall ()
#1  0x009b0f55 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x00ebc247 in QWaitConditionPrivate::wait (this=0x984d308, mutex=0x982dcc0, time=4294967295) at thread/qwaitcondition_unix.cpp:87
#3  QWaitCondition::wait (this=0x984d308, mutex=0x982dcc0, time=4294967295) at thread/qwaitcondition_unix.cpp:159
#4  0x07c8b860 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x984d2f0, th=0x9d6d988) at ../../../threadweaver/Weaver/WeaverImpl.cpp:365
#5  0x07c8e37c in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0x9815208, th=0x9d6d988) at ../../../threadweaver/Weaver/WorkingHardState.cpp:80
#6  0x07c8a27b in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0x984d2f0, th=0x9d6d988) at ../../../threadweaver/Weaver/WeaverImpl.cpp:356
#7  0x07c8e472 in ThreadWeaver::WorkingHardState::applyForWork (this=0x9815208, th=0x9d6d988) at ../../../threadweaver/Weaver/WorkingHardState.cpp:71
#8  0x07c8b4d3 in ThreadWeaver::WeaverImpl::applyForWork (this=0x984d2f0, th=0x9d6d988, previous=0xa0a2200) at ../../../threadweaver/Weaver/WeaverImpl.cpp:351
#9  0x07c8c50e in ThreadWeaver::ThreadRunHelper::run (this=0xb58272a4, parent=0x984d2f0, th=0x9d6d988) at ../../../threadweaver/Weaver/Thread.cpp:87
#10 0x07c8cc2b in ThreadWeaver::Thread::run (this=0x9d6d988) at ../../../threadweaver/Weaver/Thread.cpp:142
#11 0x00ebb2ee in QThreadPrivate::start (arg=0x9d6d988) at thread/qthread_unix.cpp:248
#12 0x009ac8de in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#13 0x033ba95e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 4 (Thread 0xb4d47b70 (LWP 4671)):
#0  0x00c23422 in __kernel_vsyscall ()
#1  0x009b0f55 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x00ebc247 in QWaitConditionPrivate::wait (this=0x99d6188, mutex=0x99dc2c8, time=4294967295) at thread/qwaitcondition_unix.cpp:87
#3  QWaitCondition::wait (this=0x99d6188, mutex=0x99dc2c8, time=4294967295) at thread/qwaitcondition_unix.cpp:159
#4  0x082c8260 in WTF::ThreadCondition::wait (this=0xb58f8dd4, mutex=...) at ../JavaScriptCore/wtf/qt/ThreadingQt.cpp:238
#5  0x087eccc4 in WebCore::IconDatabase::syncThreadMainLoop (this=0xb58f8d80) at loader/icon/IconDatabase.cpp:1412
#6  0x087f1b70 in WebCore::IconDatabase::iconDatabaseSyncThread (this=0xb58f8d80) at loader/icon/IconDatabase.cpp:1038
#7  0x082c7cff in threadEntryPoint (contextData=0xb58b9180) at ../JavaScriptCore/wtf/Threading.cpp:64
#8  0x082c8133 in WTF::ThreadPrivate::run (this=0x9e07fa8) at ../JavaScriptCore/wtf/qt/ThreadingQt.cpp:64
#9  0x00ebb2ee in QThreadPrivate::start (arg=0x9e07fa8) at thread/qthread_unix.cpp:248
#10 0x009ac8de in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#11 0x033ba95e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 3 (Thread 0xb4546b70 (LWP 4673)):
#0  0x00c23422 in __kernel_vsyscall ()
#1  0x033acb66 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0x02703ccb in g_poll () from /lib/libglib-2.0.so.0
#3  0x026f6acf in ?? () from /lib/libglib-2.0.so.0
#4  0x026f6e58 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#5  0x00fe93ef in QEventDispatcherGlib::processEvents (this=0xb4f02330, flags=...) at kernel/qeventdispatcher_glib.cpp:414
#6  0x00fbbe29 in QEventLoop::processEvents (this=0xb4546240, flags=) at kernel/qeventloop.cpp:149
#7  0x00fbc27a in QEventLoop::exec (this=0xb4546240, flags=...) at kernel/qeventloop.cpp:201
#8  0x00eb8568 in QThread::exec (this=0x9e230a0) at thread/qthread.cpp:487
#9  0x00f9bafb in QInotifyFileSystemWatcherEngine::run (this=0x9e230a0) at io/qfilesystemwatcher_inotify.cpp:248
#10 0x00ebb2ee in QThreadPrivate::start (arg=0x9e230a0) at thread/qthread_unix.cpp:248
#11 0x009ac8de in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#12 0x033ba95e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb26bfb70 (LWP 5043)):
#0  0x00c23422 in __kernel_vsyscall ()
#1  0x009b0f55 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x00ebc247 in QWaitConditionPrivate::wait (this=0x984d308, mutex=0x982dcc0, time=4294967295) at thread/qwaitcondition_unix.cpp:87
#3  QWaitCondition::wait (this=0x984d308, mutex=0x982dcc0, time=4294967295) at thread/qwaitcondition_unix.cpp:159
#4  0x07c8b860 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x984d2f0, th=0x9d5ee98) at ../../../threadweaver/Weaver/WeaverImpl.cpp:365
#5  0x07c8e37c in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0x9815208, th=0x9d5ee98) at ../../../threadweaver/Weaver/WorkingHardState.cpp:80
#6  0x07c8a27b in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0x984d2f0, th=0x9d5ee98) at ../../../threadweaver/Weaver/WeaverImpl.cpp:356
#7  0x07c8e472 in ThreadWeaver::WorkingHardState::applyForWork (this=0x9815208, th=0x9d5ee98) at ../../../threadweaver/Weaver/WorkingHardState.cpp:71
#8  0x07c8b4d3 in ThreadWeaver::WeaverImpl::applyForWork (this=0x984d2f0, th=0x9d5ee98, previous=0x0) at ../../../threadweaver/Weaver/WeaverImpl.cpp:351
#9  0x07c8c50e in ThreadWeaver::ThreadRunHelper::run (this=0xb26bf2a4, parent=0x984d2f0, th=0x9d5ee98) at ../../../threadweaver/Weaver/Thread.cpp:87
#10 0x07c8cc2b in ThreadWeaver::Thread::run (this=0x9d5ee98) at ../../../threadweaver/Weaver/Thread.cpp:142
#11 0x00ebb2ee in QThreadPrivate::start (arg=0x9d5ee98) at thread/qthread_unix.cpp:248
#12 0x009ac8de in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#13 0x033ba95e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb77ed760 (LWP 4668)):
[KCrash Handler]
#6  0x0875d4eb in WebCore::QNetworkReplyHandler::forwardData (this=0x9ece0c8) at platform/network/qt/QNetworkReplyHandler.cpp:356
#7  0x0875edc3 in WebCore::QNetworkReplyHandler::qt_metacall (this=0x9ece0c8, _c=QMetaObject::InvokeMetaMethod, _id=7, _a=0x9e34c18) at .moc/release-shared/moc_QNetworkReplyHandler.cpp:84
#8  0x00fc2a6a in QMetaObject::metacall (object=0x9ece0c8, cl=124, idx=7, argv=0x9e34c18) at kernel/qmetaobject.cpp:237
#9  0x00fcd116 in QMetaCallEvent::placeMetaCall (this=0x9ed4740, object=0x9ece0c8) at kernel/qobject.cpp:561
#10 0x00fce23e in QObject::event (this=0x9ece0c8, e=0x9ed4740) at kernel/qobject.cpp:1248
#11 0x0655f2dc in QApplicationPrivate::notify_helper (this=0x97b5f00, receiver=0x9ece0c8, e=0x9ed4740) at kernel/qapplication.cpp:4298
#12 0x06565f2e in QApplication::notify (this=0xbfbb9db8, receiver=0x9ece0c8, e=0x9ed4740) at kernel/qapplication.cpp:3702
#13 0x007cfb2a in KApplication::notify (this=0xbfbb9db8, receiver=0x9ece0c8, event=0x9ed4740) at ../../kdeui/kernel/kapplication.cpp:302
#14 0x00fbd80b in QCoreApplication::notifyInternal (this=0xbfbb9db8, receiver=0x9ece0c8, event=0x9ed4740) at kernel/qcoreapplication.cpp:704
#15 0x00fc0243 in QCoreApplication::sendEvent (receiver=0x0, event_type=0, data=0x975f048) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#16 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x975f048) at kernel/qcoreapplication.cpp:1345
#17 0x00fc03ad in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1238
#18 0x00fe98bf in QCoreApplication::sendPostedEvents (s=0x97d9b18) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220
#19 postEventSourceDispatch (s=0x97d9b18) at kernel/qeventdispatcher_glib.cpp:276
#20 0x026f2f95 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#21 0x026f6c98 in ?? () from /lib/libglib-2.0.so.0
#22 0x026f6e58 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#23 0x00fe93b5 in QEventDispatcherGlib::processEvents (this=0x97b5928, flags=...) at kernel/qeventdispatcher_glib.cpp:412
#24 0x0661e3f5 in QGuiEventDispatcherGlib::processEvents (this=0x97b5928, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#25 0x00fbbe29 in QEventLoop::processEvents (this=0xbfbb9d04, flags=) at kernel/qeventloop.cpp:149
#26 0x00fbc27a in QEventLoop::exec (this=0xbfbb9d04, flags=...) at kernel/qeventloop.cpp:201
#27 0x00fc046f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981
#28 0x0655f377 in QApplication::exec () at kernel/qapplication.cpp:3577
#29 0x04a5fb23 in kdemain (argc=1, argv=0x9795000) at /build/buildd/rekonq-0.3.94/src/main.cpp:157
#30 0x0804e037 in launch (argc=<value optimized out>, _name=<value optimized out>, args=<value optimized out>, cwd=0x0, envc=1, envs=0x9795c68 "DISPLAY=:0.0", reset_env=false, tty=0x0, 
    avoid_loops=false, startup_id_str=0x9795c79 "Milchii;1266765040;152646;1495_TIME26951063") at ../../kinit/kinit.cpp:717
#31 0x0804ec55 in handle_launcher_request (sock=<value optimized out>, who=<value optimized out>) at ../../kinit/kinit.cpp:1209
#32 0x0804f193 in handle_requests (waitForPid=<value optimized out>) at ../../kinit/kinit.cpp:1402
#33 0x0804fe7f in main (argc=4, argv=0xbfbba8a4, envp=0xbfbba8b8) at ../../kinit/kinit.cpp:1841

Possible duplicates by query: bug 222093, bug 220863, bug 217845, bug 216299, bug 214231.

Reported using DrKonqi
Comment 1 Andrea Diamantini 2010-02-24 17:20:24 UTC
Working on this. Thanks for the report..
Comment 2 Panagiotis Papadopoulos 2010-04-25 01:23:27 UTC
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
Comment 3 Dawit Alemayehu 2010-04-25 23:01:27 UTC
(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.
Comment 4 Dawit Alemayehu 2010-04-25 23:03:07 UTC
Created attachment 43036 [details]
screenshot
Comment 5 Panagiotis Papadopoulos 2010-04-25 23:08:57 UTC
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.
Comment 6 Panagiotis Papadopoulos 2010-04-25 23:21:19 UTC
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
Comment 7 Dawit Alemayehu 2010-04-26 00:35:35 UTC
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.
Comment 8 Andrea Diamantini 2010-04-26 01:21:06 UTC
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"..
Comment 9 Dawit Alemayehu 2010-04-26 01:56:29 UTC
(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...
Comment 10 Andrea Diamantini 2010-04-26 11:14:13 UTC
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,
Comment 11 Andrea Diamantini 2010-04-26 12:02:50 UTC
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.
Comment 12 Konrad Siwczyński 2010-05-11 22:01:52 UTC
Created attachment 43489 [details]
New crash information added by DrKonqi

I was doing some peacekeeper test and rekonq just crashed.
Comment 13 Romário Rios 2010-05-27 01:30:26 UTC
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.
Comment 14 Panagiotis Papadopoulos 2010-05-27 11:34:29 UTC
*** Bug 238957 has been marked as a duplicate of this bug. ***
Comment 15 support.intranet 2010-06-08 19:13:03 UTC
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)
Comment 16 Panagiotis Papadopoulos 2010-07-30 20:39:59 UTC
*** Bug 243661 has been marked as a duplicate of this bug. ***
Comment 17 Andrea Diamantini 2010-08-05 11:04:50 UTC
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
Comment 18 Nicolas L. 2010-08-24 11:30:12 UTC

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