Hide Forgot
Description of problem: midori is crashing and repoting an illegal instruction. Version-Release number of selected component (if applicable): midori-0.5.8-1.fc21.i686 Steps to Reproduce: 1. Start Midori 2. Browse for a while Actual results: bash-4.3$ midori java version "1.7.0_55" OpenJDK Runtime Environment (fedora-2.5.0.21.pre04.fc21-i386 u55-b13) OpenJDK Server VM (build 24.60-b09, mixed mode) nIllegal instruction From gdb: Program received signal SIGILL, Illegal instruction. 0x98e9a4bc in ?? () Note that an AMD MP doesn't support SSE2 instructions and this has recently caused some problems for me with ruby libraries (as used by xchat).
If you remove icedtea-web does it start normally? Nothing else in the backtrace? Can you try a: debuginfo-install midori gdb midori run show and see if it gets us more info?
Created attachment 902380 [details] gdb output I got debug output from gdb. The crashing isn't completely consistent. I sometimes need to do the same thing a few times before midori crashes.
I removed icedtea-web and the behavior was pretty much the same. midori started up and I clicked on a page feature that opened another page a few times until it crashed.
If you do a: echo 1 > /proc/sys/kernel/vm/overcommit_memory does it change anything?
(There was a thinko above, and I used echo 1 > /proc/sys/vm/overcommit_memory .) I tried switching back and forth between 0 and 1 and in both cases crashes still happened. But it was variable how many times I triggered new tabs before a crash happened.
Does the problem also happen with /usr/libexec/webkitgtk/GtkLauncher ?
/usr/libexec/webkitgtk/GtkLauncher java version "1.7.0_55" OpenJDK Runtime Environment (fedora-2.5.0.22.pre04.fc21-i386 u55-b13) OpenJDK Server VM (build 24.60-b09, mixed mode) Illegal instruction A window breifly appears (less than one second) and then it crashes.
ok, then it sounds like this is actually a webkitgtk bug... Do you get any better backtrace from the GtkLauncher crash?
I just did a quick test and didn't try to capture another traceback. After my update from the mass rebuild finishes I'll need to reinstall the debug stuff. The update probably won't finish until very late tonight, so it might take me over a day to capture the traceback. You don't happen to know if epiphany is base on webkit too? I have had epiphany crashes as well, but don't try it as often and haven't filed a bug as yet. But maybe it is the same underlying issue.
No problem. Yes, epiphany uses webkitgtk3 (ie, the gtk3 version of webkit). It's the same code, just webkitgtk is gtk2. We should probibly move this bug over to webkitgtk and see if anyone there has ideas...
Created attachment 908617 [details] webkit gdb output
*** This bug has been marked as a duplicate of bug 984689 ***