Created attachment 207605 [details] backtrace Running a simple QWebView (qtwebkit) on a geode CPU results in a crash. This is with qtwebkit 2.3.2, built with --no-force-sse2. Let me know if you need more information.
Created attachment 207606 [details] /proc/cpuinfo
Forgot to say (not sure if this is relevant): the build is not done on the same machine (too slow and not enough RAM). It's done on an Intel Core2.
I'm not sure, but this downstream bug is maybe related to this one (tested on old Athlon XP (which doesn't support SSE2) I can crash webkitgtk or qtwebkit browser by opening a web page. https://bugzilla.redhat.com/show_bug.cgi?id=984689
QtWebKit 2.3 is a bit of a special case in that an effort was made to make sure it ran on machines without SSE2. I don't have any easy way of testing anymore though.
Created attachment 266982 [details] Disable the JIT on x86 if there's no SSE2 Are non-SSE2 x86 CPUs even supported nowadays? I'm planning to disable the JIT completely in Debian if there's no SSE2, because otherwise the browser is basically useless in those machines.
Comment on attachment 266982 [details] Disable the JIT on x86 if there's no SSE2 View in context: https://bugs.webkit.org/attachment.cgi?id=266982&action=review > Source/JavaScriptCore/runtime/VM.cpp:140 > +#if CPU(X86) > + if (!MacroAssembler::supportsFloatingPoint()) > + return false; > +#endif I don't think if we should disable JIT here with disabling assembler if !supportsFloatingPoint(). ( Additionally supportsFloatingPoint() == isSSE2Present() on X86, it would be better to use isSSE2Present(). ) Of course it can be a good workaround to disable JIT until somebody trace down which SSE2 instruction is emitted and where. The proper fix would be to make JIT not to emit SSE2 instructions if !isSSE2Present(). There are many ASSERT(isSSE2Present()) assertions in MacroAssermblerX86(Common).h files. I think one of them should hit in debug mode.
(In reply to comment #6) > > Source/JavaScriptCore/runtime/VM.cpp:140 > > +#if CPU(X86) > > + if (!MacroAssembler::supportsFloatingPoint()) > > + return false; > > +#endif > > I don't think if we should disable JIT here with disabling assembler if > !supportsFloatingPoint(). > ( Additionally supportsFloatingPoint() == isSSE2Present() on X86, it would > be better to use isSSE2Present(). ) isSSE2Present() is private > Of course it can be a good workaround to disable JIT until somebody > trace down which SSE2 instruction is emitted and where. The proper > fix would be to make JIT not to emit SSE2 instructions if > !isSSE2Present(). > There are many ASSERT(isSSE2Present()) assertions in > MacroAssermblerX86(Common).h files. I think one of them should hit > in debug mode. Yeah, my question is whether upstream is still interested in this or not. I'll try debugging those assertions as you suggest, but if I don't find an easy fix I think I'll use this workaround downstream, at least for the time being.
Created attachment 266994 [details] backtrace I modified isSSE2Present() to return always false and I got the following backtrace on r189998 during running sunspider. Unfortunately I can't build newer JSC on x86, because my GCC is too old on this x86 machine. I hope it will help debugging.
Well many of our downstreams support computers without SSE2, so I'd say push the workaround upstream, then we can drop it if we find a proper fix in the future. I don't want to have to carry the same downstream patch in both Debian and Fedora.
(In reply to comment #9) > Well many of our downstreams support computers without SSE2, so I'd say push > the workaround upstream, then we can drop it if we find a proper fix in the > future. I don't want to have to carry the same downstream patch in both > Debian and Fedora. I'm not against adding a workaround, but I think the proposed one is not the proper way to disable JIT and it is very confusing. ( Unfortunately I don't have any time for this bug this year and can't help in fixing/workarounding. )
Comment on attachment 266982 [details] Disable the JIT on x86 if there's no SSE2 Let's do it in Options.cpp similar to Apple's and WinCairo's Windows port: https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/Options.cpp#L277 - #if OS(WINDOWS) && CPU(X86) + #if CPU(X86) && ( OS(WINDOWS) || OS(LINUX) ) And it would be great to add a FIXME with referencing a new bug report which is responsible for fixing JIT on non-SSE2 X86.
(In reply to comment #11) > Comment on attachment 266982 [details] > Disable the JIT on x86 if there's no SSE2 > > Let's do it in Options.cpp similar to Apple's and WinCairo's Windows port: > https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/Options. > cpp#L277 > - #if OS(WINDOWS) && CPU(X86) > + #if CPU(X86) && ( OS(WINDOWS) || OS(LINUX) ) > > And it would be great to add a FIXME with referencing a new bug report which > is responsible for fixing JIT on non-SSE2 X86. That sounds good. I will test it first because I want to make sure that this is indeed happening with the current master. Thanks!