Bug 1510876 - gjs failed to load libmozjs52
Summary: gjs failed to load libmozjs52
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gjs
Version: 7.5
Hardware: aarch64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Debarshi Ray
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords:
Depends On: 1511093
Blocks: 1519876 1505747 1517704
TreeView+ depends on / blocked
 
Reported: 2017-11-08 11:29 UTC by Michal Odehnal
Modified: 2018-05-17 14:39 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-04-10 13:07:25 UTC


Attachments (Terms of Use)
objdump aarch64 (67.47 KB, text/plain)
2018-01-08 14:05 UTC, Tomas Pelka
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0770 None None None 2018-04-10 13:08 UTC

Description Michal Odehnal 2017-11-08 11:29:12 UTC
Description of problem:
gnome-weather will probably need rebuild against gjs-1.50 with bundled mozjs52

Version-Release number of selected component (if applicable):
gnome-weather-3.20.2-1.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. Start gnome-weather
2.
3.

Actual results:
/usr/bin/gjs: error while loading shared libraries: libmozjs-52.so: cannot open shared object file: No such file or directory

Expected results:
gnome-weather starts

Additional info:
$ ln -s /usr/lib64/gjs/libmozjs-52.so /usr/lib64/libmozjs-52.so
(org.gnome.Weather.Application:7660): Gjs-CRITICAL **: JS ERROR: SyntaxError: redeclaration of let copyright @ resource:///org/gnome/Weather/Application/js/app/window.js:221
JS_EvaluateScript() failed

Comment 2 Tomas Pelka 2017-11-08 11:34:22 UTC
Something seems to be clearly wrong with gjs with bundled mozjs52, when I remove the symlink in /usr/lib64 running gjs from terminal throws again:

gjs: error while loading shared libraries: libmozjs-52.so: cannot open shared object file: No such file or directory

Comment 3 Kalev Lember 2017-11-08 16:15:33 UTC
The libmozjs52 loading issue should be fixed in gjs-1.50.2-2.el7. That gets us a bit further, but gnome-weather still fails with:

Gjs-CRITICAL **: JS ERROR: SyntaxError: redeclaration of let copyright @ resource:///org/gnome/Weather/Application/js/app/window.js:221
JS_EvaluateScript() failed

To fix that, we'll need to either backport gjs related fixes to gnome-weather or rebase gnome-weather+libgweather to 3.26. Looking at the changes upstream between 3.20 (that's what we have in RHEL 7.4) and 3.26 (latest upstream), there's very little else beyond gjs fixes and translations updates. tpelka, mclasen, if you agree, can you help set up rebase bugs for these two please?

Comment 4 Kalev Lember 2017-11-08 16:21:05 UTC
Ahh correction, libgweather was already rebased to 3.26. That just leaves gnome-weather to rebase.

Comment 6 Debarshi Ray 2017-11-30 10:52:30 UTC
I suspect that this isn't completely fixed. eg., on aarch64, I get:

  [test@hp-moonshot-02-c19 ~]$ rpm -q gjs
  gjs-1.50.2-2.el7.aarch64
  [test@hp-moonshot-02-c19 ~]$ gjs
  gjs: error while loading shared libraries: libmozjs-52.so: cannot open
    shared object file: No such file or directory
  [test@hp-moonshot-02-c19 ~]$

That leads to AX_CHECK_GIRS_GJS failing in the gnome-documents build on aarch64:
  https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14648040

Comment 7 Debarshi Ray 2017-11-30 10:57:26 UTC
-> ASSIGNED

as per tpelka's suggestion

Comment 8 Debarshi Ray 2017-11-30 12:29:31 UTC
On aarch64:

[test@hp-moonshot-02-c19 ~]$ ldd /usr/bin/gjs | grep mozjs
	libmozjs-52.so => not found
	libmozjs-52.so => /usr/lib64/gjs/libmozjs-52.so (0x0000ffff8f520000)
[test@hp-moonshot-02-c19 ~]$


On x86_64:

[rishi@kolache-rhel75 ~]$ ldd /usr/bin/gjs | grep mozjs
	libmozjs-52.so => /usr/lib64/gjs/libmozjs-52.so (0x00007ff0d85d5000)
[rishi@kolache-rhel75 ~]$

Comment 9 Debarshi Ray 2017-11-30 13:11:25 UTC
On aarch64:

[test@hp-moonshot-02-c19 ~]$ objdump -p /usr/bin/gjs | grep NEEDED | grep mozjs
  NEEDED               libmozjs-52.so
[test@hp-moonshot-02-c19 ~]$


On x86_64:

[rishi@kolache-rhel75 ~]$ objdump -p /usr/bin/gjs | grep NEEDED | grep mozjs
[rishi@kolache-rhel75 ~]$


It makes me wonder if --as-needed isn't working as expected on aarch64.

Comment 10 Debarshi Ray 2017-11-30 18:49:30 UTC
ldd -v /usr/bin/gjs-console has:

        /usr/bin/gjs-console:
                ld-linux-aarch64.so.1 (GLIBC_2.17) => /lib/ld-linux-aarch64.so.1
                libstdc++.so.6 (CXXABI_1.3) => /lib64/libstdc++.so.6
                libc.so.6 (GLIBC_2.17) => /lib64/libc.so.6
                libmozjs-52.so (js) => /usr/lib64/gjs/libmozjs-52.so


objdump -T /usr/bin/gjs-console has:

0000000000000000      DF *UND*  0000000000000000  js          abort


Could it be that the "abort" symbol is pulling in libmozjs-52.so?

Comment 11 Debarshi Ray 2017-11-30 18:57:51 UTC
objdump -T /usr/lib64/gjs/libmozjs-52.so has:

000000000066dd44 g    DF .text  0000000000000014  js          abort


Question is, why is that getting picked up only in aarch64?

Comment 12 Debarshi Ray 2017-11-30 19:29:49 UTC
(In reply to Debarshi Ray from comment #11)
> objdump -T /usr/lib64/gjs/libmozjs-52.so has:
> 
> 000000000066dd44 g    DF .text  0000000000000014  js          abort

As far as I can figure out, it is:
  #define abort moz_abort
... done through one of mozjs-52's moz.build files.

(sorry about this continued rambling)

Comment 13 Florian Weimer 2017-12-01 19:51:39 UTC
The aarch64 startup code does this:

        /* Let the libc call main and exit with its return code.  */
        bl      __libc_start_main

        /* should never get here....*/
        bl      abort

This means that every binary has a reference to the abort function.  libmozjs-52.so redefines abort and versions it with @js, so linking produces a reference to abort@js.  This pulls in libmozjs-52.so, but the build then strips the rpath of the directory which contains it.  So the aarch64 binary does not load.

On x86-64, the startup code does not call abort, so there is no reference to the symbol, and things happen to work.

The bug is the redefinition of abort.  There is a comment:

// Define abort() here, so that it is used instead of the system abort(). This
// lets us control the behavior when aborting, in order to get better results
// on *NIX platforms. See mozalloc_abort for details.

mozalloc_abort is uncommented.

Comment 14 Debarshi Ray 2017-12-04 16:49:05 UTC
Thanks for digging into it, Florian!

I put together a scratch SRPM with this patch to see if that stops the "js" abort from getting exported:
diff -urNp firefox-52.4.0esr.orig/memory/mozalloc/mozalloc_abort.h firefox-52.4.0esr/memory/mozalloc/mozalloc_abort.h
--- firefox-52.4.0esr.orig/memory/mozalloc/mozalloc_abort.h	2017-12-04 16:29:43.955029594 +0100
+++ firefox-52.4.0esr/memory/mozalloc/mozalloc_abort.h	2017-12-04 16:32:50.855179785 +0100
@@ -18,7 +18,6 @@
  * Note: MOZ_NORETURN seems to break crash stacks on ARM, so we don't
  * use that annotation there.
  */
-MFBT_API
 #if !defined(__arm__)
   MOZ_NORETURN
 #endif

The Brew build is here:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14674175

Comment 15 Debarshi Ray 2017-12-04 17:33:01 UTC
(In reply to Debarshi Ray from comment #14)
> diff -urNp firefox-52.4.0esr.orig/memory/mozalloc/mozalloc_abort.h
> firefox-52.4.0esr/memory/mozalloc/mozalloc_abort.h
> --- firefox-52.4.0esr.orig/memory/mozalloc/mozalloc_abort.h	2017-12-04
> 16:29:43.955029594 +0100
> +++ firefox-52.4.0esr/memory/mozalloc/mozalloc_abort.h	2017-12-04
> 16:32:50.855179785 +0100
> @@ -18,7 +18,6 @@
>   * Note: MOZ_NORETURN seems to break crash stacks on ARM, so we don't
>   * use that annotation there.
>   */
> -MFBT_API
>  #if !defined(__arm__)
>    MOZ_NORETURN
>  #endif

Oops, no. That's the wrong file. That's the signature for mozalloc_abort, not abort. Let's try to '#if 0' the whole abort redefinition.

The other option is __attribute__((visibility("hidden"))), but let's try the bigger hammer first. I am not sure what these DEFINE['abort'] lines in the moz.build files are about, so I want to be really really sure that this particular definition has been nuked.

Comment 16 Debarshi Ray 2017-12-05 16:13:37 UTC
(In reply to Debarshi Ray from comment #15)
> Oops, no. That's the wrong file. That's the signature for mozalloc_abort,
> not abort. Let's try to '#if 0' the whole abort redefinition.

This seems OK so far. I say "seems" because I didn't exhaustively test all architectures. Only x86_64 and aarch64, and I saw from my earlier build failure (comment 6) that s390(x) didn't have this problem.

I have submitted a build for gjs-1.50.2-3.el7 to unblock the builds relying on this fix:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14689747

We can resort to __attribute__((visibility("hidden"))) if the "#if 0" hammer turns out / is considered to be too extreme.

Comment 18 Ray Strode [halfline] 2017-12-05 19:00:34 UTC
(In reply to Debarshi Ray from comment #16)
> We can resort to __attribute__((visibility("hidden"))) if the "#if 0" hammer
> turns out / is considered to be too extreme.
Hammer may be a good idea, anyway.  Florian mentioned on IRC that libc had to remove fflush(stderr) from its abort() implementation because it caused problems (don't know the details), and the mozjs implementation of abort() does fflush(stderr).

Comment 20 Tomas Pelka 2018-01-08 14:05 UTC
Created attachment 1378553 [details]
objdump aarch64

Comment 23 errata-xmlrpc 2018-04-10 13:07:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0770


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