Bug 984689 - [abrt] midori-0.5.0-1.fc19: Process /usr/bin/midori was killed by signal 4 (SIGILL)
[abrt] midori-0.5.0-1.fc19: Process /usr/bin/midori was killed by signal 4 (S...
Product: Fedora
Classification: Fedora
Component: webkitgtk (Show other bugs)
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
: 1103967 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2013-07-15 13:09 EDT by Branko Grubić
Modified: 2015-02-18 09:00 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-02-18 09:00:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
File: backtrace (101.62 KB, text/plain)
2013-07-15 13:09 EDT, Branko Grubić
no flags Details
File: cgroup (140 bytes, text/plain)
2013-07-15 13:09 EDT, Branko Grubić
no flags Details
File: core_backtrace (3.22 KB, text/plain)
2013-07-15 13:09 EDT, Branko Grubić
no flags Details
File: dso_list (12.30 KB, text/plain)
2013-07-15 13:10 EDT, Branko Grubić
no flags Details
File: environ (1.44 KB, text/plain)
2013-07-15 13:10 EDT, Branko Grubić
no flags Details
File: limits (1.29 KB, text/plain)
2013-07-15 13:10 EDT, Branko Grubić
no flags Details
File: maps (47.03 KB, text/plain)
2013-07-15 13:10 EDT, Branko Grubić
no flags Details
File: open_fds (5.25 KB, text/plain)
2013-07-15 13:10 EDT, Branko Grubić
no flags Details
File: proc_pid_status (783 bytes, text/plain)
2013-07-15 13:10 EDT, Branko Grubić
no flags Details
trace from a rekonq (qtwebkit) browser (6.24 KB, text/plain)
2013-12-10 17:57 EST, Branko Grubić
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
WebKit Project 112239 None None None Never
WebKit Project 119190 None None None Never

  None (edit)
Description Branko Grubić 2013-07-15 13:09:47 EDT
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:

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
Comment 1 Branko Grubić 2013-07-15 13:09:53 EDT
Created attachment 773834 [details]
File: backtrace
Comment 2 Branko Grubić 2013-07-15 13:09:56 EDT
Created attachment 773835 [details]
File: cgroup
Comment 3 Branko Grubić 2013-07-15 13:09:59 EDT
Created attachment 773836 [details]
File: core_backtrace
Comment 4 Branko Grubić 2013-07-15 13:10:03 EDT
Created attachment 773837 [details]
File: dso_list
Comment 5 Branko Grubić 2013-07-15 13:10:06 EDT
Created attachment 773838 [details]
File: environ
Comment 6 Branko Grubić 2013-07-15 13:10:14 EDT
Created attachment 773839 [details]
File: limits
Comment 7 Branko Grubić 2013-07-15 13:10:38 EDT
Created attachment 773840 [details]
File: maps
Comment 8 Branko Grubić 2013-07-15 13:10:47 EDT
Created attachment 773841 [details]
File: open_fds
Comment 9 Branko Grubić 2013-07-15 13:10:52 EDT
Created attachment 773842 [details]
File: proc_pid_status
Comment 10 Kevin Fenzi 2013-07-15 13:53:41 EDT
Can you try this scratch build: 

Comment 11 Branko Grubić 2013-07-15 14:23:04 EDT
tested it on the same machine, same problem, abrt points to this bug as already reported
Comment 12 Kevin Fenzi 2013-07-15 14:31:28 EDT

If you do: 

echo 1 > /proc/sys/vm/overcommit_memory

and re-run the test, does it crash the same way?
Comment 13 Branko Grubić 2013-07-15 15:02:48 EDT
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)
Comment 14 Kevin Fenzi 2013-07-15 19:06:45 EDT
ok, that sounds like a webkitgtk bug then... 

Can you duplicate the crash with: /usr/libexec/webkitgtk/GtkLauncher ? 
(thats the webkitgtk reference browser).
Comment 15 Branko Grubić 2013-07-16 01:33:14 EDT
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 )
Comment 16 Kevin Fenzi 2013-07-16 11:51:17 EDT
ok. Moving over to webkitgtk...
Comment 17 Rex Dieter 2013-12-10 17:56:37 EST
looks like jscore may use sse2 unconditionally, and I will likely have to fix qtwebkit similarly.
Comment 18 Branko Grubić 2013-12-10 17:57:17 EST
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
Comment 19 Rex Dieter 2013-12-11 08:14:18 EST
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)
Comment 20 Rex Dieter 2013-12-11 08:15:36 EST
Sorry, wrong bug (copy-n-paste'o), this one,
Comment 21 Michael Catanzaro 2014-11-18 19:02:54 EST
*** Bug 1103967 has been marked as a duplicate of this bug. ***
Comment 22 Michael Catanzaro 2014-11-18 20:45:03 EST
Whoops, upstream bug 133621 has the same reporter, but it's quite different.
Comment 23 Kevin Kofler 2014-11-23 03:05:10 EST
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.
Comment 24 Michael Catanzaro 2014-11-23 10:24:51 EST
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.
Comment 25 Fedora End Of Life 2015-01-09 17:12:25 EST
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.
Comment 26 Fedora End Of Life 2015-02-18 09:00:37 EST
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.

Note You need to log in before you can comment on or make changes to this bug.