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:
runlevel: N 5
var_log_messages: Jul 15 18:47:28 localhost abrt: 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
Thread no. 1 (10 frames)
#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]
Created attachment 773835 [details]
Created attachment 773836 [details]
Created attachment 773837 [details]
Created attachment 773838 [details]
Created attachment 773839 [details]
Created attachment 773840 [details]
Created attachment 773841 [details]
Created attachment 773842 [details]
Can you try this scratch build:
tested it on the same machine, same problem, abrt points to this bug as already reported
If you do:
echo 1 > /proc/sys/vm/overcommit_memory
and re-run the test, does it crash the same way?
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,
*** 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.
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
Thank you for reporting this bug and we are sorry it could not be fixed.