WebKit in rawhide is pretty unusable. ;( (I can seperate these bugs if you like): 1. Layout issues. See: http://www.declera.com/~yaneti/webkit-gcc-rend.png 2. js crashes. Most any page with javascript crashes midori with the following trace: #0 WTF::dtoa (d=63232, ndigits=<value optimized out>, decpt=<value optimized out>, sign=<value optimized out>, rve=<value optimized out>) at JavaScriptCore/wtf/dtoa.cpp:2170 #1 0x00002aaaab3e76e3 in JSC::UString::from (d=0) at JavaScriptCore/runtime/UString.cpp:929 #2 0x00002aaaab43484c in jscyyparse (globalPtr=<value optimized out>) at JavaScriptCore/parser/Grammar.y:318 #3 0x00002aaaab43b1b7 in JSC::Parser::parse (this=0x2aaab65f4240, globalData=0x2aaab65ff400, errLine=0x7fffffff01dc, errMsg=0x7fffffff01d0) at JavaScriptCore/parser/Parser.cpp:58 #4 0x00002aaaab43b28f in JSC::Parser::reparseInPlace (this=0x4, globalData=0x40eee000, functionBodyNode=0x2aaab74acc60) at JavaScriptCore/parser/Parser.cpp:77 #5 0x00002aaaab43bbfb in JSC::FunctionBodyNode::generateBytecode (this=0x2aaab74acc60, scopeChainNode=0x2aaab49bc618) at JavaScriptCore/parser/Nodes.cpp:2617 #6 0x00002aaaab38f282 in JSC::FunctionBodyNode::bytecode () at JavaScriptCore/parser/Nodes.h:2194 #7 JSC::Interpreter::privateExecute (this=0x2aaab6601b00, flag=<value optimized out>, registerFile=<value optimized out>, callFrame=0x2aaab6657048, exception=<value optimized out>) at JavaScriptCore/interpreter/Interpreter.cpp:3290 #8 0x00002aaaab39180b in JSC::Interpreter::execute (this=0x2aaab6601b00, programNode=0x2aaac448e510, callFrame=0x2aaab6b9c808, scopeChain=<value optimized out>, thisObj=<value optimized out>, exception=<value optimized out>) at JavaScriptCore/interpreter/Interpreter.cpp:870 #9 0x00002aaaab43d401 in JSC::evaluate (exec=0x2aaab6b9c808, scopeChain=@0x2aaab6b9c7c0, source=@0x7fffffffd260, thisValue=<value optimized out>) at JavaScriptCore/runtime/Completion.cpp:67 #10 0x00002aaaaad8e14b in WebCore::ScriptController::evaluate (this=0x2aaaabbb6bd8, sourceCode=@0x7fffffffd260) at WebCore/bindings/js/ScriptController.cpp:114 #11 0x00002aaaaafe8f9b in WebCore::FrameLoader::executeScript (this=0x2aaaabbb6850, sourceCode=@0x7fffffffd260) at WebCore/loader/FrameLoader.cpp:781 #12 0x00002aaaaaf867da in WebCore::HTMLTokenizer::scriptExecution (this=0x2aaab6637800, sourceCode=@0x7fffffffd260, state=<value optimized out>) at WebCore/html/HTMLTokenizer.cpp:563 #13 0x00002aaaaaf86ebf in WebCore::HTMLTokenizer::notifyFinished (this=0x2aaab6637800) at WebCore/html/HTMLTokenizer.cpp:1986 #14 0x00002aaaaafbe4cc in WebCore::CachedScript::checkNotify (this=0x2aaab6c42200) at WebCore/loader/CachedScript.cpp:108 #15 0x00002aaaab00cb7d in WebCore::Loader::Host::didFinishLoading (this=0x2aaab6c2dc60, loader=0x2aaab48e1500) at WebCore/loader/loader.cpp:304 #16 0x00002aaaaaffbb7f in WebCore::SubresourceLoader::didFinishLoading (this=0x2aaab48e1500) at WebCore/loader/SubresourceLoader.cpp:183 #17 0x00002aaaab1af93e in finishedCallback (session=<value optimized out>, msg=0x1560450, data=<value optimized out>) at WebCore/platform/network/soup/ResourceHandleSoup.cpp:285 #18 0x0000003164a320a4 in final_finished (req=0x1560450, user_data=<value optimized out>) at soup-session-async.c:329 #19 0x000000314de0b8ee in IA__g_closure_invoke (closure=0x151bce0, return_value=0x0, n_param_values=1, param_values=0x1577800, invocation_hint=0x7fffffffd5e0) at gclosure.c:767 #20 0x000000314de22527 in signal_emit_unlocked_R (node=0x158bb40, detail=<value optimized out>, instance=<value optimized out>, emission_return=<value optimized out>, ---Type <return> to continue, or q <return> to quit--- instance_and_params=<value optimized out>) at gsignal.c:3314 #21 0x000000314de232de in IA__g_signal_emit_valist (instance=0x1560450, signal_id=<value optimized out>, detail=0, var_args=0x7fffffffd7d0) at gsignal.c:2977 #22 0x000000314de23873 in IA__g_signal_emit (instance=0x4, signal_id=1089396736, detail=2147483648) at gsignal.c:3034 #23 0x0000003164a296b5 in soup_message_io_finished (msg=0x1560450) at soup-message-io.c:172 #24 0x000000314de0b8ee in IA__g_closure_invoke (closure=0x1511b70, return_value=0x0, n_param_values=1, param_values=0x1616400, invocation_hint=0x7fffffffda00) at gclosure.c:767 #25 0x000000314de21ef8 in signal_emit_unlocked_R (node=0x176d610, detail=<value optimized out>, instance=<value optimized out>, emission_return=<value optimized out>, instance_and_params=<value optimized out>) at gsignal.c:3244 #26 0x000000314de232de in IA__g_signal_emit_valist (instance=0x14ffb30, signal_id=<value optimized out>, detail=0, var_args=0x7fffffffdbf0) at gsignal.c:2977 #27 0x000000314de23873 in IA__g_signal_emit (instance=0x4, signal_id=1089396736, detail=2147483648) at gsignal.c:3034 #28 0x0000003164a33da2 in socket_read_watch (chan=<value optimized out>, cond=0, user_data=0x14ffb30) at soup-socket.c:1049 #29 0x000000314d23812e in g_main_dispatch (context=<value optimized out>) at gmain.c:1814 #30 IA__g_main_context_dispatch (context=0x6ad630) at gmain.c:2367 #31 0x000000314d23b888 in g_main_context_iterate (context=0x6ad630, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at gmain.c:2448 #32 0x000000314d23bd25 in IA__g_main_loop_run (loop=0x7faf40) at gmain.c:2656 #33 0x0000003154744a57 in IA__gtk_main () at gtkmain.c:1205 #34 0x000000000041c028 in main () Using these exact same midori and WebKit-gtk packages on F10, but rebuilt in mock for F10, everything is just fine. I am suspecting very stongly a gcc 4.4 opt bug is causing both of these issues. Is there some way we can track this down and fix it? Note that newer WebKit/midori do the same thing.
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.