Bug 82496 – SIGILL in JavaScriptCore on a Geode processor

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Simon Schampijer]

Epiphany crashes right away on an XO-1 (http://wiki.laptop.org/go/Hardware_specification)

The trace is :
{{{
Program received signal SIGILL, Illegal instruction.
2	0xaf6bc2a2 in ?? ()
3	(gdb) where
4	#0  0xaf6bc2a2 in ?? ()
5	#1  0xb3b06deb in JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*) () from /lib/libjavascriptcoregtk-3.0.so.0
6	#2  0xb3be33da in JSC::evaluate(JSC::ExecState*, JSC::ScopeChainNode*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) () from /lib/libjavascriptcoregtk-3.0.so.0
7	#3  0xae46f8b4 in ?? ()
8	Backtrace stopped: previous frame inner to this frame (corrupt stack?)
}}}

I am using epiphany-3.4.0.1-1.fc17 webkitgtk3-1.8.0-1.fc17, same crash is true for the Browser in Sugar using webkitgtk, filed as http://bugs.sugarlabs.org/ticket/3401. Those two bugs at the Ubuntu tracker does look the same:   https://bugs.launchpad.net/ubuntu/+source/webkit/+bug/952216  https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/950223

[Simon Schampijer]

Tomeu was so helpful to discuss this a bit on irc: the XO-1 has a Geode processor [1] and we seem to fail assuming that some MMX instruction is present when it isn't. The other reports from Ubuntu have a disassembly [2][3] that points to movsd. Moving that bug to the JavaScriptCore component.

[1]  http://en.wikipedia.org/wiki/Geode_%28processor%29
[2] https://launchpadlibrarian.net/96330186/Disassembly.txt 
[3] https://launchpadlibrarian.net/95985450/Disassembly.txt

[Simon Schampijer]

Some more info from irc:

Tomeu did break out the ssid2 test from [1]. 

{{{
#include <stdio.h>

int
main (int argc, char **argv)
{
    int SSE2FeatureBit = 1 << 26;
    int sse2 = 0;
    int flags = 0;

    asm (
         "movl $0x1, %%eax;"
         "pushl %%ebx;"
         "cpuid;"
         "popl %%ebx;"
         "movl %%edx, %0;"
         : "=g" (flags)
         :
         : "%eax", "%ecx", "%edx"
         );

    sse2 = (flags & SSE2FeatureBit);

    printf ("sse2: %hd\n", sse2 != 0);
}
}}}

and running it on the XO does return 0.

[2] suggests that the Geode does support "the parts of SSE that do not involve SSE registers". So we might fail at [3].


[1] http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/assembler/MacroAssemblerX86Common.h#L1455
[2] http://wiki.laptop.org/go/Geode_instruction_set
[3] http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/dfg/DFGFPRInfo.h#L47

[Vincent Cappe]

Happens here too, with an athlon xp 1800+ (which can't do SSE2 either) and  the libwebkit 1.8.0-1 package from Arch Linux (i686, obviously).

same backtrace (except for the addresses themselves and the exact path of the library) and the dissassembly of the offending code is the same too (again except for the addresses). this is with midori instead of epiphany, though. it happens as soon as a page that do javascript is loaded (and does not happen on pages with no javascript, or if javascript is disabled).

the above sse2 test program returns 0, too.

also no sse2 flag in:

$ cat /proc/cpuinfo | grep '^flags' 
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow

[Vincent Cappe]

it does not crash if i recompile with CPPFLAGS='-DENABLE_DFG_JIT=0' as suggested in the sugarlabs bug report.

[Oliver Hunt]

I would guess the DFG is using an SSE2 instruction on the assumption that such is available (this is on the assumption that the cpu is not lying about full SSE support).  If you could provide a disassembly of the offending code, we might be able to determine what instruction is being used.

[Vincent Cappe]

{{{
Program terminated with signal 4, Illegal instruction.
#0  0xa970b5e2 in ?? ()
(gdb) bt
#0  0xa970b5e2 in ?? ()
#1  0xb52e691a in JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) () from /usr/lib/libjavascriptcoregtk-1.0.so.0
#2  0xb53b5352 in JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) () from /usr/lib/libjavascriptcoregtk-1.0.so.0
#3  0xbfb28d18 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) disassemble 0xa970b5e2,+141
Dump of assembler code from 0xa970b5e2 to 0xa970b66f:
=> 0xa970b5e2:  movsd  %xmm0,(%eax)
   0xa970b5e6:  mov    $0xa1b03f50,%eax
   0xa970b5eb:  movsd  %xmm1,(%eax)
   0xa970b5ef:  mov    $0xa1b03f58,%eax
   0xa970b5f4:  movsd  %xmm2,(%eax)
   0xa970b5f8:  mov    $0xa1b03f60,%eax
   0xa970b5fd:  movsd  %xmm3,(%eax)
   0xa970b601:  mov    $0xa1b03f68,%eax
   0xa970b606:  movsd  %xmm4,(%eax)
   0xa970b60a:  mov    $0xa1b03f70,%eax
   0xa970b60f:  movsd  %xmm5,(%eax)
   0xa970b613:  mov    %edi,(%esp)
   0xa970b616:  call   0xb529a820 <compileOSRExit>
   0xa970b61b:  mov    $0xa1b03f48,%eax
   0xa970b620:  movsd  (%eax),%xmm0
   0xa970b624:  mov    $0xa1b03f50,%eax
   0xa970b629:  movsd  (%eax),%xmm1
   0xa970b62d:  mov    $0xa1b03f58,%eax
   0xa970b632:  movsd  (%eax),%xmm2
   0xa970b636:  mov    $0xa1b03f60,%eax
   0xa970b63b:  movsd  (%eax),%xmm3
   0xa970b63f:  mov    $0xa1b03f68,%eax
   0xa970b644:  movsd  (%eax),%xmm4
   0xa970b648:  mov    $0xa1b03f70,%eax
   0xa970b64d:  movsd  (%eax),%xmm5
   0xa970b651:  mov    0xa1b03f20,%eax
   0xa970b656:  mov    0xa1b03f28,%edx
   0xa970b65c:  mov    0xa1b03f30,%ecx
   0xa970b662:  mov    0xa1b03f38,%ebx
   0xa970b668:  mov    0xa1b03f40,%esi
   0xa970b66e:  jmp    *0xb1c6cbb8
End of assembler dump.
}}}

[Oliver Hunt]

Just did some hunting, it appears SSE doesn't support doubles.  The supportsSSE() check (or whatever it's called) should be switched to an SSE2 check.

[Oliver Hunt]

Weird, I see we are looking for SSE2 on x86.  Hmmmm....

[Oliver Hunt]

Created attachment 135919 [details]
Patch

[Oliver Hunt]

Committed r113389: <http://trac.webkit.org/changeset/113389>

[Vincent Cappe]

i confirm that the patch fixes the problem, here.

[Simon Schampijer]

Great, thanks for following up on this! I confirm that the patch does fix the crasher on the XO-1 (patched the F17 webkitgtk3 rpm with it).