Bug 1510876
| Summary: | gjs failed to load libmozjs52 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Michal Odehnal <modehnal> | ||||
| Component: | gjs | Assignee: | Debarshi Ray <debarshir> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.5 | CC: | bgollahe, debarshir, fweimer, jkoten, klember, tpelka | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | aarch64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | gjs-1.50.2-3.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-04-10 13:07:25 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1511093 | ||||||
| Bug Blocks: | 1505747, 1517704, 1519876 | ||||||
| Attachments: |
|
||||||
|
Description
Michal Odehnal
2017-11-08 11:29:12 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 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? Ahh correction, libgweather was already rebased to 3.26. That just leaves gnome-weather to rebase. 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
-> ASSIGNED as per tpelka's suggestion 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 ~]$ 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. 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?
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? (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) 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.
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 (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. (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. (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). Created attachment 1378553 [details]
objdump aarch64
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 |