Upgrade Storage[5.0 Beta] - error on linux related to libnss3.so
Tip: For anyone using Linux, if you get the error "Failed to load backend for 'application/pdf': libnss3.so: failed to map segment from shared object" when trying to open a PDF attachment, then it is easy to fix: Just re-download zotero.
This has happened to me three times already, and re-downloading zotero has fixed it for me every time. (Just re-download the standalone application folder, you don't need to touch the settings or storage.)
I guess something about libnss3.so gets messed up by the auto-updater sometimes.
This has happened to me three times already, and re-downloading zotero has fixed it for me every time. (Just re-download the standalone application folder, you don't need to touch the settings or storage.)
I guess something about libnss3.so gets messed up by the auto-updater sometimes.
Failed to load backend for 'application/pdf': libnss3.so: failed to map segment from shared object
"Failed to load backend for 'application/pdf': libnss3.so: failed to map segment from shared object"
Operating System is Ubuntu Gnome 17.04
Looks like it's caused by evince, so simply install another PDF viewer to avoid this error.
I installed foxit reader, and its working flawlessly. you can try others like xpdf or okular.
To install okular on ubuntu run following command.
sudo apt-get install okular
The problem continues to recur for me, after some but not every update. The fix I proposed above (replacing my "Zotero_linux-x86_64" folder with a freshly-downloaded one) is still working for me.
For example:
https://github.com/docker/compose/issues/1339
https://support.datastax.com/hc/en-us/articles/115000550123-Graph-loader-throws-failed-to-map-segment-from-shared-object-warning
Well, I do notice that zotero seems to use /tmp during updating (via the "mktemp -d" command) if I'm reading the code right. But then I'm stuck. My /tmp is not mounted at all, it's just a normal directory in /, which is a normal ext4 filesystem with normal settings, and also the /tmp permissions look correct ("drwxrwxrwt"). (But I'm not an expert!) So maybe it's something else? I dunno, I'm stuck. Any ideas?
...But, when I quit and restart zotero again, it's fixed!! (And it continues to work on future restarts.) That's nice! The easiest workaround I've ever seen :-) . I hope it continues to work that way on future updates, where I merely have to quit and restart zotero one extra time per update. But I will post again if I see (and can reproduce) the nastier version where the error persists even after opening and closing zotero many times.
Unfortunately I doubt this is something we're going to be able to fix with the current updater (and I'm not sure it's actually new in 5.0 or there are just more people on the standalone app on Linux now), so people on Linux may have to put up with the extra restart for a while. (Obviously there won't be daily updates once things settle down a bit.)
I believe that the root cause of this problem is that the zotero startup script on Linux sets LD_LIBRARY_PATH to point to the zotero install's own library directory. For me it gets set to:
LD_LIBRARY_PATH=/home/njs/bin/Zotero_linux-x86_64
Then, when zotero tries to run a subprocess – for example, starting a PDF viewer – the subprocess *inherits* this environment variable setting, so it *also* ends up trying to use zotero's own libraries. (I confirmed this by examining /proc/$PID/environ for one of the broken evince processes.)
In particular, if you look in that directory, you'll see that zotero ships a copy of libnss3.so for its own use. Then my system-installed evince tries to load libnss3.so, and expects that it will get the system-installed libnss3.so... but instead it gets zotero's version, and these aren't necessarily compatible. (After all, that's why zotero ships its own copy in the first place! It doesn't trust that the system copy will match what it needs.) This might also explain why some people above report that the problem comes and goes with upgrades: if zotero and your system are both using the same version of libnss3.so, then things will end up working out by chance; whenever they get out of sync, the problem comes back.
To verify that this is the problem, I made a script called "zotero-evince" with the following contents:
#!/bin/sh
unset LD_LIBRARY_PATH
exec evince "$@"
When I tell zotero to use this as my PDF viewer (Edit -> Preferences -> Open PDFs using -> Custom...), then viewing PDFs always works. When zotero uses regular evince, then it always fails. So it's definitely the LD_LIBRARY_PATH that's causing the problem.
This script works as a workaround. But it would be good if zotero could fix this to make the workaround unnecessary.
I think the simplest solution would be: whenever zotero goes to spawn a subprocess like a PDF viewer, it should first restore the original LD_LIBRARY_PATH setting. Doing this reliably is a little tricky, since it's possible that users will have set their own custom LD_LIBRARY_PATH. One solution would be for the startup script to set an envvar ZOTERO_ORIGINAL_LD_LIBRARY_PATH, and then whenever zotero goes to launch a process, it could check if this envvar is set, and if so use it to overwrite the regular LD_LIBRARY_PATH for the child process.
Another option would be to change how you distribute binaries so that you can stop setting LD_LIBRARY_PATH entirely, for example by giving the libraries unique names ("libnss3-zotero.so"), or by building the zotero binary with a custom DT_RUNPATH configuration. This is rather more technical and may require tools like patchelf, though; probably it's easier to change LD_LIBRARY_PATH before spawning children.
$ sudo apt install libnss3-dev
To clarify, I get an "libnss3.so: failed to map segment from shared object" error randomly, even if I just opened Zotero. Rebooting Zotero and trying to open a paper again usually fixes it, but I can't figure out why it is happening.