Bug 82496

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

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

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

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

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.

{{{ 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. }}}

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.

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

Created attachment 135919 [details] Patch

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

i confirm that the patch fixes the problem, here.

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