1434033 - After Firefox applies an update and restarts, evince fails opening PDFs with "Failed to load backend for 'application/pdf': libnss3.so: failed to map segment from shared object"

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Chris AtLee [:catlee]]

Lately I have been unable to open PDFs in evince when launched from Firefox. The GUI opens, but displays an error message:

Failed to load backend for 'application/pdf': libnss3.so: failed to map segment from shared object.

I am able to open the same PDF when I launch evince from a terminal or from my desktop environment's menu.

Filing this in Core:Build Config because it sounded very similar to bug 1433703 in terms of the symptoms at least.

Comment 1

[Mike Hommey [:glandium]]

Can you mozregression this (if you can confirm it's actually a regression from Firefox)?

Comment 2

[Chris AtLee [:catlee]]

sigh, after a reboot today, the issue went away.

Comment 3

[noszalyaron4]

I still have this issue with latest nightly.

Comment 4

[noszalyaron4]

It seems like it depends on my profile, because I couldn't reproduce it with a blank profile and also couldn't mozregression it (stupid me, I did mozregression first :D)

Comment 5

[Chris AtLee [:catlee]]

It's happening again for me too. Can't reproduce with mozregression though.

Comment 6

[Peter Bašista]

According to my experience, this issue only occurs when Firefox downloads an update and then is allowed to restart and upgrade itself. After that, the PDFs cannot be opened in Evince directly from Firefox until the next time Firefox is manually restarted. I have noticed this behavior with Nightly quite a long time ago (months, maybe a year back). As of today, it is still reproducible.

I do not know how exactly Firefox launches Evince and other 3rd party programs, but it may be worth looking into it. The upgrade procedure should also be checked. I assume that when Firefox upgrades and restarts itself, some of the original runtime dependencies (i.e. from the original, non-upgraded Firefox) are still kept in memory somewhere and perhaps may cause this "failed to map segment from shared object" issue when launching Evince. Not sure.

Comment 7

[noszalyaron4]

Nice observation! I can indeed confirm that this is the case for me too: after update the issues is there, but then "hard" restarting firefox and it's gone.

Comment 8

[Peter Bašista]

The status of "RESOLVED INVALID" is incorrect. Can someone with the appropriate rights update it?

Comment 9

[Chris AtLee [:catlee]]

So one difference between when evince is launched from a fresh Firefox vs. an updated Firefox is that LD_LIBRARY_PATH is set in the latter.

When I launch Firefox directly, and then open an PDF, evince's environment does not have LD_LIBRARY_PATH set. firefox's environment doesn't either.

After Firefox updates, both evince's and firefox's environment have LD_LIBRARY_PATH set to /home/catlee/minefield.

If I run evince from a terminal with LD_LIBRARY_PATH set explicitly to the same path, it fails in the same way.

Comment 10

[mbudde]

I'm also affected by this bug and can confirm that firefox is setting LD_LIBRARY_PATH which is causing evince to fail. A workaround (inspired by [1]) is to create a evince wrapper script that unsets LD_LIBRARY_PATH:

#!/bin/sh
unset LD_LIBRARY_PATH
exec evince "$@"

and a desktop entry file:

[Desktop Entry]
Name=Evince Wrapper
TryExec=/home/mbu/usr/bin/evince-firefox-wrapper
Exec=/home/mbu/usr/bin/evince-firefox-wrapper %U
StartupNotify=true
Terminal=false
Type=Application
Icon=evince
Categories=GNOME;GTK;Office;Viewer;Graphics;2DGraphics;VectorGraphics;
MimeType=application/pdf;application/x-bzpdf;application/x-gzpdf;application/x-xzpdf;application/x-ext-pdf;application/postscript;application/x-bzpostscript;application/x-gzpostscript;image/x-eps;image/x-bzeps;image/x-gzeps;application/x-ext-ps;application/x-ext-eps;application/illustrator;application/x-dvi;application/x-bzdvi;application/x-gzdvi;application/x-ext-dvi;image/vnd.djvu+multipage;application/x-ext-djv;application/x-ext-djvu;image/tiff;application/x-cbr;application/x-cbz;application/x-cb7;application/x-cbt;application/x-ext-cbr;application/x-ext-cbz;application/vnd.comicbook+zip;application/x-ext-cb7;application/x-ext-cbt;application/oxps;application/vnd.ms-xpsdocument;

and use that to open PDFs in Firefox.

[1]: https://forums.zotero.org/discussion/comment/307034/#Comment_307034

Comment 11

[Nathan Froyd [:froydnj]]

Presumably this is due to this code:

https://searchfox.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#634-654

I think what we want to do here is pass the LD_LIBRARY_PATH into the environment of the updater, rather than setting it in Firefox's environment.  So something execve-like...jld, do we already have something in ipc/ for launching a process with extra environment variables?

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

base::LaunchApp can do that for fork/exec, but it doesn't handle plain exec, and it looks like this code does that when restart == true.

Fortunately, the environment-handling logic is factored out as base::BuildEnvironmentArray, and it's relatively simple to use that with execve, the way LaunchApp does: https://searchfox.org/mozilla-central/rev/3f17a234769d25fca5144ebb8abc8e1cb3c56c16/ipc/chromium/src/base/process_util_linux.cc#37 (the argument is just the map of env vars to set/replace; everything else is copied from the current environment)

But, is there a case where the updater would launch the new browser?  If so, then we'd also need to do something like save the old library path in another env var and have the updater restore it.

Comment 13

[Molly Howell (she/her) (mostly inactive)]

(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #12)
> But, is there a case where the updater would launch the new browser?  If so,
> then we'd also need to do something like save the old library path in
> another env var and have the updater restore it.

In normal update scenarios, the updater always launches a copy of the updated browser when it's finished; that's https://searchfox.org/mozilla-central/rev/3f17a234769d25fca5144ebb8abc8e1cb3c56c16/toolkit/mozapps/update/updater/updater.cpp#2080. Restoring a saved library path from that function is definitely a thing we could do though.

Comment 14

[Mike Hommey [:glandium]]

Why is setting LD_LIBRARY_PATH necessary in the first place? I know it's necessary for the plugin container, but why is it necessary for the updater?
And the answer is, accortding to readelf -d, that it depends on nss and sqlite. I guess the former is for hash validation, but wtf is sqlite doing there?

It's 2018, though, I wonder if we shouldn't just use rpaths, now.

Comment 15

[Molly Howell (she/her) (mostly inactive)]

The Linux updater uses NSS to validate MAR file signatures. I'm not sure, but I believe NSS pulls in SQLite so it can read its certificate database; the updater doesn't use SQLite directly.

Comment 17

[Robert Strong (they/them - no direct email)]

Attachment: Bug 1434033 - Use ORIGIN to search for NSS on Linux. r?mhowell,glandium

Set the updater LDFLAGS to -Wl,-rpath= so NSS can be found in the binary's directory
Stop changing the LD_LIBRARY_PATH in nsUpdaterDriver.cpp
Load the updater support files before the update begins in progressui_gtk.cpp
Launch the updater from the install directory instead of copying it to the update directory
Remove the skip-if = (os == linux && verify) for the staging tests since this also fixes the ETXTBSY error when calling execv on the copied updater

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ee53ed43d51d
Use ORIGIN to search for NSS on Linux. r=mhowell,glandium

Comment 19

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/ee53ed43d51d