gnome-shell crashes in libmozjs on x86_64

Bug #1682631 reported by Brian Vincent
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
mozjs38 (Ubuntu)
Fix Released
High
Unassigned
Zesty
Fix Released
High
Unassigned

Bug Description

Impact
------
This enables build tests to run on all architectures. The tests now fail the build on all architectures except arm64, ppc64el and s390x. (On arm64 and ppc64el, the tests fail and I wasn't able to test s390x before uploading. This means that there is a decent chance the gnome-shell does not work on these architectures but Ubuntu GNOME only officially supports gnome-shell on i386 and amd64.)

This was done by building without -fstrict-aliasing and skipping 3 ICU tests. (Those 3 tests don't work right with the system ICU that Ubuntu 17.04 is using to build mozjs38.)

Test Case
---------
1. Since the tests will now fail the build if they fail, make sure that mozjs38 builds on all architectures

2. Install the new version and make sure GNOME Shell seems to still work.

Regression Potential
--------------------
I don't know much about strict-aliasing, but I believe it's safer to disable it on a large old codebase like this. Since it makes the build tests pass now, it seems like disabling strict-aliasing may fix some bugs.

Other Info
----------
mozjs is the SpiderMonkey JavaScript engine from Firefox. This version is from Firefox 38.

Original Bug Description
------------------------
A friend and I are seeing frequent gnome-shell crashes on Ubuntu 17.04 on 3 different computers. Here's an example:

Apr 12 22:35:00 ******** kernel: gnome-shell[2592]: segfault at 10 ip 00007f0e3ccc26d7 sp 00007ffdd31b4d90 error 4 in libmozjs-38.so.0.0.0[7f0e3c93e000+6c7000]

I've analyzed the issue for a while and I actually believe I've found the solution.

If I simply download the apt source package and build it using gcc 6.3.0, and then go to js/src and execute:

$ make check-jstests | grep -c UNEXPECTED-FAIL
49

Upon examination, those test failures are all because of segfaults.

If I rebuild and retests with gcc 5, all tests pass.

I've discovered that adding the flag -fno-strict-aliasing causes all of the tests to pass with gcc 6.

Revision history for this message
Brian Vincent (bvinc) wrote :

I checked libmozjs185 to see what's changed in that version. It looks like their build script always uses -fno-strict-aliasing on gcc, no matter the version.

It also appears that js tests get ran when the package gets built.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mozjs38 (Ubuntu):
status: New → Confirmed
Revision history for this message
Michael Brumlow (mbrumlow) wrote :

I can confirm having the same bug and confirm that recompiling the package with -fno-strict-aliasing has solved my problem.

Revision history for this message
Brian Murray (brian-murray) wrote :

There are several crashes about gnome-shell regarding js in the Error Tracker although no individual crash report has a large volume of crashes in and of itself.

I spoke with the bug reporter in irc and none of their crashes have been retraced yet, additionally they don't have a good initial crash signature so I'm not positive which bucket is associated with this issue.

Changed in mozjs38 (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
tags: added: zesty
Revision history for this message
Jeremy Bícha (jbicha) wrote :

I added
export DEB_CFLAGS_MAINT_APPEND = -fno-strict-aliasing
to debian/rules but I still get 50 UNEXPECTED-FAIL 's from check-jstests when built on Ubuntu 17.04.

Revision history for this message
Jeremy Bícha (jbicha) wrote :

I talked with the gjs maintainer Philip Chimento who thought that
https://git.gnome.org/browse/jhbuild/tree/patches/mozjs38-1269317.patch

was a better patch than our fix-gcc6-segfault.patch to fix
https://bugzilla.mozilla.org/show_bug.cgi?id=1245783
That actually managed to raise the UNEXPECTED-FAIL's to 55 in my testing (it did not matter whether I used that -f-no-strict-aliasing rule.)

Revision history for this message
Brian Vincent (bvinc) wrote :

I also tried adding
export DEB_CFLAGS_MAINT_APPEND = -fno-strict-aliasing
to debian/rules. I don't know much about debian packages and how that would normally work, but I don't see how that would ever get picked up by their config/make system. It doesn't appear to be having any effect at all.

Here's what I did to get the test failures down to 0 on gcc6:

1. modify the code at line 3908 in js/src/configure.in to do -fno-strict-aliasing no matter what the gcc version is:

dnl ========================================================
dnl = Disable -fstrict-aliasing with GCC
dnl = See bugs 821502 and 832623.
dnl ========================================================
if test -n "$GNU_CC" -a -z "$CLANG_CC"; then
    CFLAGS="$CFLAGS -fno-strict-aliasing"
    CXXFLAGS="$CXXFLAGS -fno-strict-aliasing"
fi

2. cd js/src
3. autoconf2.13 #regen configure
4. ./configure #reconfigure
5. make clean
6. make #watch and see the -fno-strict-aliasing
7.
make check-jstests | grep -c UNEXPECTED-FAIL
0

PS. This seems to be mostly unrelated to the fix-gcc6-segfault.patch. If I remove fix-gcc6-segfault.patch, the test failures go back up. So what I'm purposing doesn't replace the need for fix-gcc6-segfault.patch. I think it should be treated separately.

Jeremy Bícha (jbicha)
description: updated
Jeremy Bícha (jbicha)
description: updated
Changed in mozjs38 (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Jeremy Bícha (jbicha) wrote :

Brian Vincent, thank you for taking the time to help make Ubuntu better!

I've uploaded your change and some related changes to the zesty-proposed queue where it will need to be manually approved by a member of the Stable Release Update team before it will be available for testing.

Revision history for this message
Adam Conrad (adconrad) wrote : Please test proposed package

Hello Brian, or anyone else affected,

Accepted mozjs38 into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/mozjs38/38.2.1~rc0-0ubuntu6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in mozjs38 (Ubuntu Zesty):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
David John Dudson (bigdavenz) wrote :

Thank you all very much for the fix.

After upgrading from ubuntu-gnome 16.10 -> 17.04 I was running into this issue, as frequently as every 2 minutes gnome-shell would crash, around every ~30 minutes gnome-shell would fail to recover.

After enabling proposed and upgrading I have had 0 issues. (I've been running the new version for ~8 hours)

Installed version (apt output):

libmozjs-38-0/zesty-proposed,now 38.2.1~rc0-0ubuntu6 amd64 [installed,automatic]

tags: added: verification-done
removed: verification-needed
Revision history for this message
Brian Vincent (bvinc) wrote :

I have to think that my purposed changed did some good, but after running the the package from zesty-proposed for almost 3 days now, I got a crash.

Apr 20 14:42:56 ******** kernel: gnome-shell[22791]: segfault at 7300000139 ip 00007f733408be61 sp 00007fff19ee8000 error 4 in libmozjs-38.so.0.0.0[7f7333d5d000+6c8000]

OOPS ID is e919f7c6-2602-11e7-89d6-fa163e171d9b

I guess there is still something wrong. Is there any way for me to get the debug symbols for that build?

Revision history for this message
Jeremy Bícha (jbicha) wrote :

There are several other GNOME 3.24 SRUs that haven't been accepted by the Stable Release Update team yet. One in particular is gjs (LPL: #1682235).

https://wiki.ubuntu.com/Debug%20Symbol%20Packages#Getting_-dbgsym.ddeb_packages

Extensions can crash gnome-shell so maybe try without any extensions enabled.

The test case for this bug is about getting the build tests working though.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mozjs38 - 38.2.1~rc0-0ubuntu6

---------------
mozjs38 (38.2.1~rc0-0ubuntu6) zesty; urgency=medium

  * Add debian/patches/disable-strict-aliasing.patch (LP: #1682631):
    - Patch from Brian Vincent to enable ~50 build tests to pass by
      using -fno-strict-aliasing, might reduce GNOME Shell crashes
  * Add debian/patches/skip-icu-tests.patch:
    - Skip 3 tests that fail because we use a newer system ICU
  * debian/rules:
    - Enable build tests on all architectures except arm64, ppc64el, s390x

 -- Jeremy Bicha <email address hidden> Sat, 15 Apr 2017 13:07:59 -0400

Changed in mozjs38 (Ubuntu):
status: Fix Committed → Fix Released
Changed in mozjs38 (Ubuntu Zesty):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for mozjs38 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.