Bug 488112
| Summary: | WebKit crashes in midori and layout issues | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kevin Fenzi <kevin> |
| Component: | WebKit | Assignee: | Peter Gordon <peter> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | bnocera, jakub, kevin, martin.sourada, maxamillion, mtasaka, peter |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-06-06 05:49:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Kevin Fenzi
2009-03-02 18:46:00 UTC
Adding Jakub here. Any ideas on tracking this down? ok, I rebuilt WebKit without -O2 and it all works again as expected, so this does seem to be a gcc 4.4 -O2 related issue. I can confirm the issue. I've filed the bug upstream: https://bugs.webkit.org/show_bug.cgi?id=24326 (WebKit Gtk built with gcc4.4 and -O2 crashes and has layout issues) *** Bug 488163 has been marked as a duplicate of this bug. *** Fixing aliasing issue on JavaScriptCore/wtf/dtoa.cpp (like bug in nspr: bug 487844 ) fixes "most" of the issues, but not all. Actually there are some other files which are causing strict-aliasing breakage warnings. Fixing all of them may fix this issue completely, however I have not tried yet. Recompiling with -fno-strict-aliasing seems good. For now I will workaround for this to pass -fno-strict-aliasing. Modified in 1.1.0-0.21 Excellent. We should update to the recently released webkit 1.1.1, but I guess thats beyond the scope of this bug. ;) This is the same bug as KJS bug 485968. Did you confirm your patch fixed the issue? I tried Jakub's patch on KJS and it did NOT work. We're currently using -fno-strict-aliasing on the offending file, but I'd rather fix this properly. From the patches posted in the NSPR report, Kai Engert's version looks the cleanest to me. Looks like we also need to patch qt (QtWebKit). Grrr, why do we have to have the same !"§$ing code in 3 !"§$ing packages? :-( Team A develops a HTML library, team B decides to fork it to remove KDE dependencies, team C ports it back to Qt (but without KDE), team D ports it to GTK+ instead. And the funny thing in all this is that KJS can _already_ be built without Qt and KDE, so it wouldn't even have needed a fork by the WebKit developers. :-( Oh, I see from comment #4 that you're using -fno-strict-aliasing on the whole package. :-( That's a really brutal "fix". FWIW, KHTML/Konqueror is apparently fixed when I just compile dtoa.cpp with -fno-strict-aliasing (but for some reason Jakub's dtoa patch did not work for it). Actually, I just checked the build.log for Qt and Qt already builds all of QtWebKit with -fno-strict-aliasing. :-/ (In reply to comment #8) > This is the same bug as KJS bug 485968. > > Did you confirm your patch fixed the issue? I tried Jakub's patch on KJS and it > did NOT work. I did not use Jakub's patch for this issue and tried to fix JavaScriptCore/wtf/dtoa.cpp by myself. As said before it fixed "most" of the issue but not all. > Looks like we also need to patch qt (QtWebKit). Grrr, why do we have to have > the same !"§$ing code in 3 !"§$ing packages? :-( Umm.... (In reply to comment #9) > Oh, I see from comment #4 that you're using -fno-strict-aliasing on the whole > package. :-( That's a really brutal "fix". The trouble is that (as you can see from the spec file) WebKit tries to compile JavaScriptCore/AllInOneFile.cpp (the name of this file shows what is occuring) which has many "include "foo.cpp"", so currently I cannot limit the use of "-fno-strict-aliasing" to only seemingly-breaking codes. I haven't tested it yet, but it seems it has just been fixed upstream in r42262 Reference: https://bugs.webkit.org/show_bug.cgi?id=25033 Patch: https://bugs.webkit.org/attachment.cgi?id=29251&action=view Removing F11Blocker, as current workaround is working. Just a short notice that the workaround is not needed anymore for webkitgtk-1.1.5 and newer. I'm going to go ahead and close this now, as it's fixed in the newer versions. |