You need to
before you can comment on or make changes to this bug.
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 ?? ()
7 #3 0xae46f8b4 in ?? ()
8 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
I am using epiphany-188.8.131.52-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
Some more info from irc:
Tomeu did break out the ssid2 test from .
main (int argc, char **argv)
int SSE2FeatureBit = 1 << 26;
int sse2 = 0;
int flags = 0;
"movl $0x1, %%eax;"
"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.
 suggests that the Geode does support "the parts of SSE that do not involve SSE registers". So we might fail at .
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).
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 ?? ()
#0 0xa970b5e2 in ?? ()
#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 an attachment (id=135919) [details]
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).