Red Hat Bugzilla – Bug 984689
[abrt] midori-0.5.0-1.fc19: Process /usr/bin/midori was killed by signal 4 (SIGILL)
Last modified: 2015-02-18 09:00:37 EST
Description of problem: I was browsing the web and opened multiple web sites and midori disappeared. Looked at dmesg didn't saw any message about crash, run it through gdb and saw SIGILL (Illegal instruction), asked on #fedora, #fedora-devel ... and they say best way to report it is to use abrt, so I hope it will give enough information. It is probably somewhere in submited files, but I use fedora 19 xfce spin (x86 (i686)) on a old Athlon xp processor (10+ years old), so I think the code is optimized for some instruction which it doesn't have? Version-Release number of selected component: midori-0.5.0-1.fc19 Additional info: reporter: libreport-2.1.5 backtrace_rating: 4 cmdline: midori executable: /usr/bin/midori kernel: 3.9.9-302.fc19.i686 runlevel: N 5 uid: 1000 var_log_messages: Jul 15 18:47:28 localhost abrt[1224]: Saved core dump of pid 1202 (/usr/bin/midori) to /var/tmp/abrt/ccpp-2013-07-15-18:47:25-1202 (188534784 bytes) xsession_errors: ** (midori4:1202): WARNING **: adblock_compile_regexp: Error while compiling regular expression /cdn-cgi/pe/bag\?r[]=.*cpalead.com at char 34: missing terminating ] for character class Truncated backtrace: Thread no. 1 (10 frames) #0 ?? #1 JSC::Interpreter::execute at /lib/libjavascriptcoregtk-1.0.so.0 #2 JSC::evaluate at /lib/libjavascriptcoregtk-1.0.so.0 #3 WebCore::ScriptController::evaluateInWorld at /lib/libwebkitgtk-1.0.so.0 #4 WebCore::ScriptController::evaluate at /lib/libwebkitgtk-1.0.so.0 #5 WebCore::ScriptElement::executeScript at /lib/libwebkitgtk-1.0.so.0 #6 WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent at /lib/libwebkitgtk-1.0.so.0 #7 WebCore::HTMLScriptRunner::executeParsingBlockingScript at /lib/libwebkitgtk-1.0.so.0 #8 WebCore::HTMLScriptRunner::executeParsingBlockingScripts at /lib/libwebkitgtk-1.0.so.0 #9 WebCore::HTMLScriptRunner::execute at /lib/libwebkitgtk-1.0.so.0
Created attachment 773834 [details] File: backtrace
Created attachment 773835 [details] File: cgroup
Created attachment 773836 [details] File: core_backtrace
Created attachment 773837 [details] File: dso_list
Created attachment 773838 [details] File: environ
Created attachment 773839 [details] File: limits
Created attachment 773840 [details] File: maps
Created attachment 773841 [details] File: open_fds
Created attachment 773842 [details] File: proc_pid_status
Can you try this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5609813
tested it on the same machine, same problem, abrt points to this bug as already reported
ok. If you do: echo 1 > /proc/sys/vm/overcommit_memory and re-run the test, does it crash the same way?
With echo 1 > /proc/sys/vm/overcommit_memory and using the package from koji 0.5.2-1, it is killed by the same signal SIGILL, but abrt doesn't say it is reported, probably something different And another information not related to midori, but maybe to this "problem", I can reproduce this with epiphany browser (it uses "different" webkit (webkitgtk3)), with the same page, It doesn't "crash" completely because it works differently (each tab, different webkit process ...), but it stops loading page says something went wrong ... (I think), and abrt says WebKitWebProcess was killed by signal 4 (SIGILL)
ok, that sounds like a webkitgtk bug then... Can you duplicate the crash with: /usr/libexec/webkitgtk/GtkLauncher ? (thats the webkitgtk reference browser).
yes, when I provide that link it crashes (Illegal instruction (core dumped)) (the link which always crashes the browser is: techdrivein.com/2011/01/midori-vs-epiphany-review.html )
ok. Moving over to webkitgtk...
looks like jscore may use sse2 unconditionally, and I will likely have to fix qtwebkit similarly.
Created attachment 834983 [details] trace from a rekonq (qtwebkit) browser I think this is optimization issue (but I'm not sure about it, I know nothing!), Athlon XP used in my system doesn't support SSE2 instructions, also this may be related to this upstream bug https://bugs.webkit.org/show_bug.cgi?id=119190
Hrm, maybe disabling JIT may not help, upstream bug 119190 documents a case of a crash using AMD Geode CPU with JIT already disabled (on ubuntu). (not sure if fedora supports geode or vice-versa)
Sorry, wrong bug (copy-n-paste'o), this one, https://bugs.webkit.org/show_bug.cgi?id=112239
*** Bug 1103967 has been marked as a duplicate of this bug. ***
Whoops, upstream bug 133621 has the same reporter, but it's quite different.
For QtWebKit, we actually build the library twice now, once as /usr/lib/libQtWebKit.so.4* with --no-force-sse2 (not sure whether this disables the JIT entirely or just makes it not use SSE2 – according to the linked upstream bug, it looks like the JIT can be built with x87 now, so I'd guess that's what the flag does now) and once as /usr/lib/sse2/libQtWebKit.so.4* without that flag. You probably need to do something similar in webkitgtk.
For non-x86-64 machines: We already build without sse2 instructions except for developer builds from git checkouts using the build-webkit script (where they're essential to make floating point tests pass, and where we assume that a developer has a sufficiently "new" computer). It looks like the qtwebkit Fedora package is using that script, which explains why you needed that workaround. So sse2 should never be used in our builds. I think JavaScriptCore uses a runtime check to decide whether to emit SSE2 instructions when compiling JS, though. Most likely, something has gone wrong with that; maybe it's not being checked everywhere it should be. If anyone can get a backtrace with debug symbols from JavaScriptCore, that might help. I'm not sure why ABRT wasn't smart enough to grab those.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.