Bug 119190 – "Illegal instruction" crash on AMD Geode CPU

• Component: JavaScriptCore
• Status: UNCONFIRMED

[Gauvain Pocentek]

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.

[Gauvain Pocentek]

Created attachment 207606 [details]
/proc/cpuinfo

[Gauvain Pocentek]

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.

[(bitlord)]

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

[Allan Sandfeld Jensen]

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.

[Alberto Garcia]

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.

[Csaba Osztrogonác]

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.

[Alberto Garcia]

(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.

[Csaba Osztrogonác]

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.

[Michael Catanzaro]

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.

[Csaba Osztrogonác]

(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. )

[Csaba Osztrogonác]

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.

[Alberto Garcia]

(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!