Summary: | Konqueror with kwebkitpart (and Rekonq) crash when running futuremark peacekeeper benchmark [WebCore::QNetworkReplyHandler::forwardData, ..., KDEPrivate::AccessManagerReply::qt_metacall, KIO::TransferJob::data] | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Stanislav Ionascu <stanislav.ionascu> |
Component: | kdewebkit | Assignee: | webkit-devel |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | adawit, adjam7, andresbajotierra, franciscoadriansanchez, L.Bonnaud, mossad, sven.assmann, xwarman |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
New crash information added by DrKonqi
New crash information added by DrKonqi New crash information added by DrKonqi |
Description
Stanislav Ionascu
2010-08-11 01:21:12 UTC
Created attachment 51641 [details]
New crash information added by DrKonqi
konqueror (4.5.1 (KDE 4.5.1)) on KDE Platform 4.5.1 (KDE 4.5.1) using Qt 4.7.0
- What I was doing when the application crashed:
I was surfering some pages (bancofrances.com.ar & movistar.com.ar/online) and suddenly, Konqueror + Webkit crashed
-- Backtrace (Reduced):
#9 0x00007f3bbd62baa7 in KDEPrivate::AccessManagerReply::qt_metacall (this=0xf65a00, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffb7115450) at ./accessmanagerreply_p.moc:81
[...]
#11 0x00007f3bbd660524 in KIO::TransferJob::data (this=0xe93720, _t1=0xe887a0, _t2=<value optimized out>) at ./jobclasses.moc:388
#12 0x00007f3bbd662cd0 in KIO::TransferJob::slotData (this=0xe887a0, _data=...) at ../../kio/kio/job.cpp:1003
#13 0x00007f3bbd666a56 in KIO::TransferJob::qt_metacall (this=0xe887a0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffb7115630) at ./jobclasses.moc:368
[...]
#15 0x00007f3bbd714982 in KIO::SlaveInterface::data (this=0xe93720, _t1=<value optimized out>) at ./slaveinterface.moc:146
Created attachment 51926 [details] New crash information added by DrKonqi rekonq (0.4.0) on KDE Platform 4.5.1 (KDE 4.5.1) using Qt 4.7.0 - What I was doing when the application crashed: open the URL: http://service.futuremark.com/peacekeeper/run.action -- Backtrace (Reduced): #6 0x00007f1a76b58619 in WebCore::QNetworkReplyHandler::forwardData (this=0x20ce6a0) at platform/network/qt/QNetworkReplyHandler.cpp:399 #7 0x00007f1a76b59e54 in WebCore::QNetworkReplyHandler::qt_metacall (this=0x20ce6a0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fff70ddfcd0) at ./moc_QNetworkReplyHandler.cpp:86 [...] #9 0x00007f1a79470aa7 in KDEPrivate::AccessManagerReply::qt_metacall (this=0x265fcf0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fff70ddfe40) at ./accessmanagerreply_p.moc:81 [...] #11 0x00007f1a794a5524 in KIO::TransferJob::data (this=0x0, _t1=0x26392b0, _t2=<value optimized out>) at ./jobclasses.moc:388 #12 0x00007f1a794a7cd0 in KIO::TransferJob::slotData (this=0x26392b0, _data=...) at ../../kio/kio/job.cpp:1003 *** Bug 252042 has been marked as a duplicate of this bug. *** Believe it or not, this is both an upstream and downstream issue at the same time! Why may all ask ? Well it is because the only I was able to duplicate this bug is when I compile QtWebKit in debug mode and then split the debug symbols from the generated library into a separate debug library using objcopy and striped out the debugging symbols from the original library. As such I can only assume that the distro(s) in question here follow the same method outlined above to create their qtwebkit packages. If that is the case, then that is where the problem needs to be addressed. I was originally unable to reproduce this issue originally because my QtWebkit was compiled in release mode... (In reply to comment #4) > Believe it or not, this is both an upstream and downstream issue at the same > time! Why may all ask ? Well it is because the only I was able to duplicate > this bug is when I compile QtWebKit in debug mode and then split the debug > symbols from the generated library into a separate debug library using objcopy > and striped out the debugging symbols from the original library. > > As such I can only assume that the distro(s) in question here follow the same > method outlined above to create their qtwebkit packages. If that is the case, > then that is where the problem needs to be addressed. I was originally unable > to reproduce this issue originally because my QtWebkit was compiled in release > mode... Uhm... let me say that I ever compiled QtWebKit in debug mode, striping out the symbols. I ever could reproduce the issue with rekonq or konqueror, but never with arora. (In reply to comment #5) > (In reply to comment #4) > > Believe it or not, this is both an upstream and downstream issue at the same > > time! Why may all ask ? Well it is because the only I was able to duplicate > > this bug is when I compile QtWebKit in debug mode and then split the debug > > symbols from the generated library into a separate debug library using objcopy > > and striped out the debugging symbols from the original library. > > > > As such I can only assume that the distro(s) in question here follow the same > > method outlined above to create their qtwebkit packages. If that is the case, > > then that is where the problem needs to be addressed. I was originally unable > > to reproduce this issue originally because my QtWebkit was compiled in release > > mode... > > Uhm... let me say that I ever compiled QtWebKit in debug mode, striping out the > symbols. Did you mean to say that "I have never compiled" ? But have you compiled it in debug without doing the rest ? IOW, I was able to duplicate this crash when I did what I stated above. Otherwise, I cannot reproduce the result. > I ever could reproduce the issue with rekonq or konqueror, but never with > arora. For me, I cannot reproduce this issue with konqueror + kwebkitpart if I compile qtwebkit in release mode... BTW, do any of you get a warning dialog about the script running for a long time and whether or not you want to stop it ? (In reply to comment #6) > (In reply to comment #5) > > > > Uhm... let me say that I ever compiled QtWebKit in debug mode, striping out the > > symbols. > > Did you mean to say that "I have never compiled" ? But have you compiled it in > debug without doing the rest ? IOW, I was able to duplicate this crash when I > did what I stated above. Otherwise, I cannot reproduce the result. > > > I ever could reproduce the issue with rekonq or konqueror, but never with > > arora. No, I'm saying I always compile QtWebKit in debug mode striping out debug symbols. I'm used to with every software I compile from myself. I ever... always could reproduce the issue with rekonq and with konqueror + kwebkit, but NEVER with Arora. So, I'm suggesting the issue comes from kio integration. BTW, I'll try compiling QtWebKit in release mode and test it with the 3 browsers. PS: Can I reduce the title length to "Konqueror with kwebkitpart (and Rekonq) crash when running futuremark peacekeeper benchmark" ? :D @Andrea: You can reduce the lenght of the title but consider that bug triagers use the backtrace functions in the title to identify the master crash report when handling duplicates. Leaving the first function only may still work. Regards On Saturday 20 November 2010 19:08:56 Dario Andres wrote:
> https://bugs.kde.org/show_bug.cgi?id=247311
>
>
>
>
>
> --- Comment #10 from Dario Andres <andresbajotierra gmail com> 2010-11-20
> 19:08:56 --- @Andrea: You can reduce the lenght of the title but consider
> that bug triagers use the backtrace functions in the title to identify the
> master crash report when handling duplicates. Leaving the first function
> only may still work. Regards
Ah, ok. Dario, thanks for clarification. You switched on a light in my bugzilla
knowledge :)
[Comment from a bug triager] Note: bug 253340 is now grouping crashes with a similar/the same backtrace but under different situations (no related to this benchmarking site). The root cause may still be the same. Regards On Sat, Nov 20, 2010 at 1:03 PM, Andrea Diamantini <adjam7@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=247311 > > > > > > --- Comment #8 from Andrea Diamantini <adjam7 gmail com> 2010-11-20 19:03:11 --- > (In reply to comment #6) >> (In reply to comment #5) >> > >> > Uhm... let me say that I ever compiled QtWebKit in debug mode, striping out the >> > symbols. >> >> Did you mean to say that "I have never compiled" ? But have you compiled it in >> debug without doing the rest ? IOW, I was able to duplicate this crash when I >> did what I stated above. Otherwise, I cannot reproduce the result. >> >> > I ever could reproduce the issue with rekonq or konqueror, but never with >> > arora. > > No, I'm saying I always compile QtWebKit in debug mode striping out debug > symbols. I'm used to with every software I compile from myself. > I ever... always could reproduce the issue with rekonq and with konqueror + > kwebkit, but NEVER with Arora. > > So, I'm suggesting the issue comes from kio integration. Well I have never ever been able to reproduce this bug with konqueror + kwebkitpart until I compiled QtWebKit in debug mode and stripped out the debugging symbols into own separate library. I doubt the issue is in KIO integration especially since we no longer return a NULL where a QNetworkReply was expected. Right now there is only one known and outstanding issue with the KIO integration and that is its inability to properly handle KIO's slave pause and resume functionality on unknown/unsupported mime-types. > BTW, I'll try compiling QtWebKit in release mode and test it with the 3 browsers. Please let me know how that goes. I too have tried this benchmark with QtTestBrowser, Arora, Konqueror + kwebkitpart and to date I have yet to see a single crash when QtWebKit is compiled in release mode. Hmm, can you also try the debug mode version without stripping out any of the debugging symbols into a separate library ? I see the same crash in Ubuntu maverick with the following package versions: Package: konqueror Version: 4:4.5.4-0ubuntu1~maverick1~ppa1 Package: rekonq Version: 0.6.1-0ubuntu1 Package: libkdewebkit5 Version: 4:4.5.4-0ubuntu1~maverick1~ppa2 Package: libqtwebkit4 Version: 2.0.0-0ubuntu1 Just scrored 2152 points with rekonq (which was identified as Konqueror) and Qt 4.7.1. I think whatever caused the crash has been fixed in Qt 4.7.1 Created attachment 54839 [details]
New crash information added by DrKonqi
rekonq (0.6.1) on KDE Platform 4.5.1 (KDE 4.5.1) using Qt 4.7.0
- What I was doing when the application crashed:
Peacekeeper's rendering test phase cused crash
-- Backtrace (Reduced):
#11 0x03dd0ec7 in QIODevice::readyRead (this=0xa49f260) at .moc/release-shared/moc_qiodevice.cpp:91
#12 0x0223e896 in KDEPrivate::AccessManagerReply::appendData (this=0xa49f260, kioJob=0x8fed590, data=...) at ../../kio/kio/accessmanagerreply_p.cpp:168
#13 0x0223e9be in KDEPrivate::AccessManagerReply::qt_metacall (this=0xa49f260, _c=QMetaObject::InvokeMetaMethod, _id=15, _a=0xbfcf9b54) at ./accessmanagerreply_p.moc:81
[...]
[...]
#16 0x022774c9 in KIO::TransferJob::data (this=0x8fed590, _t1=0x8fed590, _t2=...) at ./jobclasses.moc:388
#17 0x0227a312 in KIO::TransferJob::slotData (this=0x8fed590, _data=...) at ../../kio/kio/job.cpp:1003
For those using a self compiled QtWebKit from git, the crash you get, if any, at this benchmark site is a separate issue unless you are using KDE older than version 4.5.4. Otherwise, the source of this crash has already been addressed. See comment #13 in bug# 253340 for further details. *** This bug has been marked as a duplicate of bug 253340 *** |