Yay, I just upgraded my nspluginwrapper and everything broke. Again. Couldn't use youtube or any of my other favorite sites anymore.
Running firefox from the console gave me some feedback:
*** NSPlugin Viewer *** ERROR: NP_Initialize() get args: Message argument mismatch *** NSPlugin Viewer *** ERROR: rpc_end_sync called when not in sync! *** NSPlugin Wrapper *** ERROR: NP_Initialize() wait for reply: Connection closed NOTE: child process received `Goodbye', closing down |
When I google'd around a bit, I found some commands for older/different versions of nspluginwrapper. Finally, I tried the parameters of the old binary on the new binary:
/usr/lib64/nspluginwrapper/npconfig -a -v -i
and got the output:
Auto-install plugins from /usr/lib/mozilla/plugins Looking for plugins in /usr/lib/mozilla/plugins Install plugin /usr/lib/mozilla/plugins/libflashplayer.so into /home/username/.mozilla/plugins/npwrapper.libflashplayer.so Auto-install plugins from /usr/lib64/mozilla/plugins Looking for plugins in /usr/lib64/mozilla/plugins *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/libtotem-gmp-plugin.so: wrong ELF class: ELFCLASS64 Install plugin /usr/lib64/mozilla/plugins/libtotem-gmp-plugin.so into /home/username/.mozilla/plugins/npwrapper.libtotem-gmp-plugin.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/skypebuttons.so: wrong ELF class: ELFCLASS64 Install plugin /usr/lib64/mozilla/plugins/skypebuttons.so into /home/username/.mozilla/plugins/npwrapper.skypebuttons.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/libtotem-cone-plugin.so: wrong ELF class: ELFCLASS64 Install plugin /usr/lib64/mozilla/plugins/libtotem-cone-plugin.so into /home/username/.mozilla/plugins/npwrapper.libtotem-cone-plugin.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/librhythmbox-itms-detection-plugin.so: wrong ELF class: ELFCLASS64 Install plugin /usr/lib64/mozilla/plugins/librhythmbox-itms-detection-plugin.so into /home/username/.mozilla/plugins/npwrapper.librhythmbox-itms-detection-plugin.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/libtotem-narrowspace-plugin.so: wrong ELF class: ELFCLASS64 Install plugin /usr/lib64/mozilla/plugins/libtotem-narrowspace-plugin.so into /home/username/.mozilla/plugins/npwrapper.libtotem-narrowspace-plugin.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/libtotem-mully-plugin.so: wrong ELF class: ELFCLASS64 Install plugin /usr/lib64/mozilla/plugins/libtotem-mully-plugin.so into /home/username/.mozilla/plugins/npwrapper.libtotem-mully-plugin.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/libjavaplugin.so: wrong ELF class: ELFCLASS64 Install plugin /usr/lib64/mozilla/plugins/libjavaplugin.so into /home/username/.mozilla/plugins/npwrapper.libjavaplugin.so Auto-install plugins from /home/username/.mozilla/plugins Looking for plugins in /home/username/.mozilla/plugins Install plugin /home/username/.mozilla/plugins/libflashplayer.so into /home/username/.mozilla/plugins/npwrapper.libflashplayer.so *** NSPlugin Viewer *** ERROR: /home/username/.mozilla/plugins/libnpgoogletalk64.so: wrong ELF class: ELFCLASS64 Install plugin /home/username/.mozilla/plugins/libnpgoogletalk64.so into /home/username/.mozilla/plugins/npwrapper.libnpgoogletalk64.so *** NSPlugin Viewer *** ERROR: /home/username/.mozilla/plugins/libnpgtpo3dautoplugin.so: wrong ELF class: ELFCLASS64 Install plugin /home/username/.mozilla/plugins/libnpgtpo3dautoplugin.so into /home/username/.mozilla/plugins/npwrapper.libnpgtpo3dautoplugin.so |
After this, my Firefox was running as usual.
© GeekLabInfo Reconfigure nspluginwrapper is a post from GeekLab.info. You are free to copy materials from GeekLab.info, but you are required to link back to http://www.geeklab.info
(No Ratings Yet)
Loading...
Hi, I'm the current nspluginwrapper maintainer (I came across your post via Google Alerts). So, I suspect what happened was that your wrapper plugins were not updated after you upgraded nspluginwrapper. Your distribution should run the appropriate command in some update script, but the whole thing is quite fragile. (The problem is that generated wrapper plugins must match in version to the package-manager-updated viewer binaries. I intend to rework the scheme to bypass the system package manager and manage copies of viewers within npconfig, but I haven't had the time to do this.)
For reference, the command you want to run is nspluginwrapper -a -v -u to update existing wrappers. (Although Fedora has some oddball setuid wrapper binary they call in a Firefox wrapper or something. I dunno, I don't maintain the packages.) What you did works, although it actually attempted to install a wrapper for every plugin you have. Turns out Flash was the only 32-bit one, so that's fine.
By the way, Adobe released a stable 64-bit version of Flash about a month ago. I strongly recommend you use that one instead of nspluginwrapper. It will work much much better.
Hi David,
Thanks for your reply! I feel honored that you, being the nspluginwrapper maintainer, are reacting on my post. I think you're doing a pretty good job!
The problem was indeed that the wrapper plugins were not updated. However, I don't have the nspluginwrapper binary you're mentioning. My RPM lists:
So I checked out all binaries to see if I got something working. And I ended up with the command /usr/lib64/nspluginwrapper/npconfig -a -v -i
I just tried to run it using the -a -v -u switches as you said, but that gave me a core dump.
I'm a little frustrated that everytime I upgrade something on Fedora, things fall apart. Not just nspluginwrapper, but Firefox, Thunderbird (had to edit some xpi this morning that was specifically meant for the thunderbird-version installed), KDE as well as the kernel (because X.org depends on nvidia drivers from a third-party repo - though I got this fixed using akmods now).
For now, I'm more than happy that nspluginwrapper is working again. I'll be checking out the x86_64 plugin as well, but if that doesn't work out, running /usr/lib64/nspluginwrapper/npconfig -a -v -i once a month isn't too bad.
Kind regards,
David
Eh, this is a project that had been abandoned for two years before I took over earlier this year. There wasn't a place for people to report problems to, so I ask Google to send anything it can find my way.
Missing binary: Oh, actually that's just a symlink to your npconfig of the appropriate architecture, so I think it's the same. I guess Fedora doesn't install it because they have their own mozilla-plugin-config.
Crash on -u: Ugh. I know what the cause of that is... I've actually fixed it in master, but have yet to make a release with the fix. Probably should do that at some point. A lot of libraries break when you unload them. In your case, I suspect it's because skypebuttons.so loads (and then unloads) Qt. Qt has a bug (I think to be fixed in 4.8) where they can pthread_key_delete someone else's data, causing explosions later. No browser ever dlcloses plugins on Linux because of these sorts of bugs. (Go check /proc/YOURBROWSER/maps. You'll see every plugin and every dependency of that plugin loaded even though you're probably not using any of them. On Linux, you have to dlopen a plugin and run code from it just to probe it. Windows and OS X plugins (mostly) don't require this nonsense. Chrome's going to do this in a utility process for a future release to avoid this.) npconfig didn't know to follow suit. Now it does.
https://github.com/davidben/nspluginwrapper/commit/f3c2b2d1f5ee558ad2f3c7830821d591c8a0f440
In the meantime, -i works too. You can also drop the -a and pass a path to the wrapper directly. (The difference between -a -i and -a -u is that -a -i will regenerate the wrapper for every plugin it can find. -u will only regenerate existing wrappers that need updating.)