Summary: | rekonq crashes on several sites with javascript enabled | ||
---|---|---|---|
Product: | [Applications] rekonq | Reporter: | Mathias Kraus <k.hias> |
Component: | general | Assignee: | Andrea Diamantini <adjam7> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | andresbajotierra, benjamin.poulain, boris.bigott, fedora, m.wege, pano_90, paulo.miguel.dias, sml, Sven.Roederer, zoiss |
Priority: | NOR | ||
Version: | 0.5.0 | ||
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
Mathias Kraus
2010-07-18 23:02:15 UTC
I can confirm this with KDE SC 4.5 RC 2, Qt 4.6.3 on Arch Linux x86_64 (64 Bit) and rekonq from git as of today. I’ve set the plugins to only load manually, so I can rule out flash as the culprit for this crash. (Also AFAIK that site does not use flash at all). Works here as it should. rekonq 0.5.0, KDE SC 4.5 RC 2, Qt 4.6.3, openSUSE 11.2 The site works as expected, and rekonq doesn't crash here on Kubuntu 10.04. Qt: 4.6.3 KDE Development Platform: 4.4.5 (KDE 4.4.5) rekonq: 0.4.95 I cannot reproduce the bug. Qt: 4.7.0-trunk KDE: 4.4.2 Rekonq: 0.5.0-trunk Site works for me. For the record; KDE SC 4.5 RC2 Qt4.7 beta 2 Fedora 13 (i686) rekonq 0.5.0 (the official release / Fedora build) I habe additional information how to reproduce this bug. it looks like it's not only the enabled javascript but also a non default font. I tried to further investigate the reason for the crash and accidently deleted the rekonqrc file instead of renaming it :(. but guess what happend after I startet rekonq. it doesn't crash anymore. I was happy and reconfigured rekonq like before and now it crashed again on that site. here are the steps you need to do to reproduce the crash: 1. rename rekonqrc to rekonqrc.backup or what you like 2. start rekonq 3. go to "Configure rekonq...->Appearance" 4. change the "Serif font" to something else 5. go to http://www.pro-linux.de/news/1/15917/opensuse-113-veroeffentlicht.html I also noticed, that all the other fonts also chage if only the serif font is changed. this might be related to the bug. Jedrzej tested #6 with QtWebKit trunk and was not able to reproduce the crash. M. Kraus’ E-Mail to the rekonq mailing list about this bug: the reason for the crash seems to be a bug in qtwebkit. in Application::updateConfiguration() is setFontFamily(...) called and if the string with the font is empty, rekonq will crash on http://www.pro-linux.de/news/1/15917/opensuse-113-veroeffentlicht.html the best solution would be, if setFontFamily(...) would check for an empty string. the reason for the empty font string is a rekonq bug. if some certain settings are changed, e.g. from the webshortcuts or the cookies, AppearanceWidget::save() is called and sets empty font strings because the slots AppearanceWidget::slotStandardFont(const QFont &f) and so on are not called and therefore reFont[] has empty strings. @ M. Kraus: Can you report this bug at the WebKit bugtracker? should be fixed with the Commit bdf09030a60214b5476cbfaa5c6237d54d4dec2d yay, it's fixed and the font bug too. I'll wait for the next qtwebkit beta to see if I can reproduce it on a more recent qtwebkit version, because it seams to be fixed in trunk. thank's for fixing the bug. *** Bug 245330 has been marked as a duplicate of this bug. *** *** Bug 247083 has been marked as a duplicate of this bug. *** *** Bug 247409 has been marked as a duplicate of this bug. *** *** Bug 247825 has been marked as a duplicate of this bug. *** *** Bug 248603 has been marked as a duplicate of this bug. *** Created attachment 50858 [details] New crash information added by DrKonqi rekonq (0.5.81) on KDE Platform 4.5.00 (KDE 4.5.0) using Qt 4.7.0 - What I was doing when the application crashed: I see this bug is closed, but DrKonqi suggests my report is related to it, so I'm attaching mine here, to let developers decide whether to reopen it. In fact, I've upgraded to the latest beta, but still experience these crashes. What I did: I went here https://bugs.kde.org and clicked on "Search Existing Reports" - that's when the crash occurred. -- Backtrace (Reduced): #7 WebCore::StringImpl::existingHash (family=...) at platform/text/StringImpl.h:173 #8 WebCore::AtomicStringHash::hash (family=...) at platform/text/AtomicStringHash.h:40 #9 WTF::IdentityHashTranslator<WebCore::AtomicString, WebCore::AtomicString, WebCore::AtomicStringHash>::hash (family=...) at ../JavaScriptCore/wtf/HashTable.h:279 #10 lookup<WebCore::AtomicString, WTF::IdentityHashTranslator<WebCore::AtomicString, WebCore::AtomicString, WebCore::AtomicStringHash> > (family=...) at ../JavaScriptCore/wtf/HashTable.h:483 #11 contains<WebCore::AtomicString, WTF::IdentityHashTranslator<WebCore::AtomicString, WebCore::AtomicString, WebCore::AtomicStringHash> > (family=...) at ../JavaScriptCore/wtf/HashTable.h:803 Created attachment 51834 [details] New crash information added by DrKonqi rekonq (0.6.0) on KDE Platform 4.5.1 (KDE 4.5.1) using Qt 4.7.0 - What I was doing when the application crashed: I read from the original report that this bug was fixed some time ago, but I'm running the latest stable release, and have just had this crash (which still happens frequently) visiting this website: http://lucidfox.org/posts/view/623 -- Backtrace (Reduced): #7 WebCore::StringImpl::existingHash (family=...) at platform/text/StringImpl.h:173 #8 WebCore::AtomicStringHash::hash (family=...) at platform/text/AtomicStringHash.h:40 #9 WTF::IdentityHashTranslator<WebCore::AtomicString, WebCore::AtomicString, WebCore::AtomicStringHash>::hash (family=...) at ../JavaScriptCore/wtf/HashTable.h:279 #10 lookup<WebCore::AtomicString, WTF::IdentityHashTranslator<WebCore::AtomicString, WebCore::AtomicString, WebCore::AtomicStringHash> > (family=...) at ../JavaScriptCore/wtf/HashTable.h:483 #11 contains<WebCore::AtomicString, WTF::IdentityHashTranslator<WebCore::AtomicString, WebCore::AtomicString, WebCore::AtomicStringHash> > (family=...) at ../JavaScriptCore/wtf/HashTable.h:803 it doesn't crash at that site and I hadn't any crash since a few weeks. which qtwebkit version do you use? if it's not qtwebkit 2 then that might be the reason. can you try to reanam the ~/.kde/share/config/rekonqrc and check if it help? > it doesn't crash at that site and I hadn't any crash since a few weeks. > which qtwebkit version do you use? if it's not qtwebkit 2 then that might > be the reason. I use qtwebkit 2. > can you try to reanam the ~/.kde/share/config/rekonqrc and check if it > help? Yes, it helps, thanks. It seems I can safely browse that website without a crash, now. [Comment from a bug triager] There is a new version of this crash (similar/same backtrace) happening even with Qt 4.7.1 according to some of the duplicates on it: bug 251171 Created attachment 58934 [details]
New crash information added by DrKonqi
rekonq (0.7.0) on KDE Platform 4.6.2 (4.6.2) using Qt 4.7.2
- What I was doing when the application crashed:
Visiting sourceforge.net
- Unusual behavior I noticed:
It crashes.
- Custom settings of the application:
I enabled Javascript
-- Backtrace (Reduced):
#6 0x00007f8c63835af9 in WebCore::RenderTextControl::hasValidAvgCharWidth(WebCore::AtomicString) () from /usr/lib64/qt4/libQtWebKit.so.4
#7 0x00007f8c63835ca5 in WebCore::RenderTextControl::getAvgCharWidth(WebCore::AtomicString) () from /usr/lib64/qt4/libQtWebKit.so.4
#8 0x00007f8c63837b5c in WebCore::RenderTextControlSingleLine::getAvgCharWidth(WebCore::AtomicString) () from /usr/lib64/qt4/libQtWebKit.so.4
#9 0x00007f8c638335c7 in WebCore::RenderTextControl::calcPrefWidths() () from /usr/lib64/qt4/libQtWebKit.so.4
#10 0x00007f8c637c6833 in WebCore::RenderBox::maxPrefWidth() const () from /usr/lib64/qt4/libQtWebKit.so.4
After a bit more reading :), I could fix the issue by deleteing the rekonqrc. Nevertheless, it would be cool if rekonq hadn't crashed in the first first place. |