Bug 488112 - WebKit crashes in midori and layout issues
WebKit crashes in midori and layout issues
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: WebKit (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Gordon
Fedora Extras Quality Assurance
:
: 488163 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-02 13:46 EST by Kevin Fenzi
Modified: 2009-06-06 01:49 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-06 01:49:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin Fenzi 2009-03-02 13:46:00 EST
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.
Comment 1 Kevin Fenzi 2009-03-02 13:55:31 EST
Adding Jakub here.

Any ideas on tracking this down?
Comment 2 Kevin Fenzi 2009-03-02 15:37:17 EST
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.
Comment 3 Martin Sourada 2009-03-03 12:58:32 EST
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)
Comment 4 Mamoru TASAKA 2009-03-03 13:09:12 EST
*** Bug 488163 has been marked as a duplicate of this bug. ***
Comment 5 Mamoru TASAKA 2009-03-03 13:14:31 EST
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.
Comment 6 Mamoru TASAKA 2009-03-03 15:02:17 EST
Modified in 1.1.0-0.21
Comment 7 Kevin Fenzi 2009-03-03 15:17:27 EST
Excellent. We should update to the recently released webkit 1.1.1, but I guess thats beyond the scope of this bug. ;)
Comment 8 Kevin Kofler 2009-03-03 20:44:49 EST
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. :-(
Comment 9 Kevin Kofler 2009-03-03 20:48:42 EST
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).
Comment 10 Kevin Kofler 2009-03-03 21:02:23 EST
Actually, I just checked the build.log for Qt and Qt already builds all of QtWebKit with -fno-strict-aliasing. :-/
Comment 11 Mamoru TASAKA 2009-03-03 23:25:51 EST
(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.
Comment 12 Martin Sourada 2009-04-07 08:59:24 EDT
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
Comment 13 Mamoru TASAKA 2009-04-14 12:45:57 EDT
Removing F11Blocker, as current workaround is working.
Comment 14 Martin Sourada 2009-04-29 16:47:30 EDT
Just a short notice that the workaround is not needed anymore for webkitgtk-1.1.5 and newer.
Comment 15 Kevin Fenzi 2009-06-06 01:49:45 EDT
I'm going to go ahead and close this now, as it's fixed in the newer versions.

Note You need to log in before you can comment on or make changes to this bug.