Bug 12011

Steps to reproduce:
On a fresh install (mga4b2+upgrades 2013-12-18), just issue urpmi nspluginwrapper, and you will see two segfaults :

      6/9: nspluginwrapper       #########################################################################################
/var/lib/rpm/filetriggers/nspluginwrapper.script: rad 15:  6130 Segmenteringsfel        nspluginwrapper -a -r
      7/9: libsqlite3_0          #########################################################################################
      8/9: libnspr4              #########################################################################################
/var/lib/rpm/filetriggers/nspluginwrapper.script: rad 15:  6158 Segmenteringsfel        nspluginwrapper -a -r

I don't have x86_64, but I can't reproduce this on i586.  If you find a patch that fixes your issue (or that might), let us know.

I reproduced this on a i586 updated cauldron now.
web seraching on nspluginwrapper segfault give a few hit regarding ubuntu and this particular nspluginwrapper version 1.4.4.

May depend on what is installed:

https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/1111931/comments/7
"Removing gecko-mediaplayer fixes the issue for me"

And later
"
Other distros seem to be able to say something like
export IGNORE_WRAP="libtotem*:libjavaplugin*:gecko-media*"
in /etc/sysconfig/nspluginwrapper
 "

Our /etc/sysconfig/nspluginwrapper do not contain that line.
I added it and also tried edited version without knowing what i am doing really, no change...

On ubuntu this bug is confirmed but open since jan -13.

More info in ubuntu bug no 1105417.

Seem nobody yet have a clue unfortunately.

Hardware: x86_64 => All

Citing me citing an ubuntu user:
> "Removing gecko-mediaplayer fixes the issue for me"

I forgot to say i do not have that package installed.

I will try to set up virtualbox after christmas and do some experiments to try to see if i can see when it works, and when it segfaults...

Ideas what to try?

That's really strange.  Even with gecko-mediaplayer installed I couldn't reproduce.

Thank you for investigating.

I now did a full boot-nonfree.iso 64 bit network install (using local urpmi-proxy), all default, choosed KDE, in a virtual machine in virtualbox.

And when i install nspluginwrapper i get the same as in comment 1, with only difference it installed 71 rpm incl deps:

/var/lib/rpm/filetriggers/nspluginwrapper.script: line 15:  3810 Segmentation fault        nspluginwrapper -a -r


I guess you are not running KDE, or have less installed than default?

I am running KDE, but yes I have customized the installed package set a bit.

With substantially less packages it works OK:
Another fresh install in virtualbox, all default except i chose custom, and only select
 Console tools
 Configuration
 LXDE

After reboot into LXDE i can install and uninstall nspluginwrapper OK.

Also OK after installing task-kde-minimal accepting all firs choice and booting into it.

Same for task-kde: OK.

So i plan to back up this virtual disk and add packages corresponding to a default KDE install (which is not OK with ndiswrapper according to above) and log them until it breaks...  after xmas.

Please do somebody know: Is it just a few task-* packages to add to make a default KDE install?
Which ones?

flash-player-plugin i think is the culprit

On my system where i want to actually use ndiswrapper, i can not uninstall flash-player-plugin because it triggers ndiswrapper to run, which can not be uninstalled...

Iĺl be back with a descrption how to reproduce.

How to replicate: make mga4 64 bit KDE install, all default (not changing any packages.) then urpmi nspluginwrapper. Segfault.

flash-player-plugin is not the lone cause;

All tests in this post on mga4 (cauldron) 64 bit in virtualbox on mga3 64 bit installed by latest 64 bit boot-nonfree.iso.

------------------

Using default KDE install: it contains flash-player-plugin already, so first i remove it, and installing nspluginwrapper *) segfaults as per above.
*) two alternative dependencies: firefox-beta or libnss3, tested each from scratch to same result.

------------------

While in minimal system; at install select Custom and only checkmark at "Console Tools" and "Configuration".  After reboot urpmi nspluginwrapper (using default choice, pulls 100 more packages), then flash-player-plugin: OK. Can also uninstall and reinstall nspluginwrapper.
Still works to uninstall and install nspluginwrapper while flash-player-plugin is installed after installing KDE using urpmi task-KDE --auto.

------------------

Trying gdb in a problematic setup:

# urpmi nspluginwrapper-debug
# gdb nspluginwrapper

(gdb) run -l
Starting program: /usr/lib/nspluginwrapper/x86_64/linux/npconfig -l
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff765a036 in __strcmp_ssse3 () from /lib64/libc.so.6

nspluginwrapper install segfaults the same also on default GNOME install.
But it works OK on default GNOME install if i urpme flash-player-plugin first.
(But if then urpmi flash-player-plugin there is a segfault in nspluginwrapper - trigged by installing flash)

Summary: nspluginwrapper segfaults because of something in default KDE install, but not task-kde => nspluginwrapper segfaults because of something in default KDE and GNOME installs

Confirmed now.  It's crashing in dlopen(), trying to open a non-existing file.  I don't think that should cause a crash (indeed dlopen() is used for libraries that may or may not exist), and a quick scan of the manpage doesn't refute this.  I also compiled my own foo.c that just does dlopen("/tmp/foo.so", 1); and it doesn't crash.  It's possible, judging from the backtrace, that glib may be the issue here.

ltrace shows this at the end:
dlopen("/usr/lib/mozilla/plugins/skypebuttons.so", 1 <no return ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

gdb gives this backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xb7e3c5d7 in __strcmp_sse4_2 () from /lib/i686/libc.so.6
Missing separate debuginfos, use: debuginfo-install nspluginwrapper-1.4.4-4.mga3.i586
(gdb) bt
#0  0xb7e3c5d7 in __strcmp_sse4_2 () from /lib/i686/libc.so.6
#1  0xb7ef1513 in g_str_equal () from /lib/libglib-2.0.so.0
#2  0xb7ef0b55 in g_hash_table_lookup () from /lib/libglib-2.0.so.0
#3  0xb7f11242 in g_quark_from_static_string () from /lib/libglib-2.0.so.0
#4  0xb7b427a2 in gobject_init_ctor () from /lib/libgobject-2.0.so.0
#5  0xb7feecbe in call_init.part.0 () from /lib/ld-linux.so.2
#6  0xb7feedb4 in _dl_init_internal () from /lib/ld-linux.so.2
#7  0xb7ff298a in dl_open_worker () from /lib/ld-linux.so.2
#8  0xb7feeb3a in _dl_catch_error () from /lib/ld-linux.so.2
#9  0xb7ff2244 in _dl_open () from /lib/ld-linux.so.2
#10 0xb7fbfcbc in dlopen_doit () from /lib/libdl.so.2
#11 0xb7feeb3a in _dl_catch_error () from /lib/ld-linux.so.2
#12 0xb7fc03bc in _dlerror_run () from /lib/libdl.so.2
#13 0xb7fbfd71 in dlopen () from /lib/libdl.so.2
#14 0x08049397 in is_wrapper_plugin (
    plugin_path=plugin_path@entry=0x806e140 "/usr/lib/mozilla/plugins/skypebuttons.so", out_plugin_info=out_plugin_info@entry=0xbfffa9a5)
    at ../src/npw-config.c:532
#15 0x080495a9 in is_wrapper_plugin_0 (
    plugin_path=plugin_path@entry=0x806e140 "/usr/lib/mozilla/plugins/skypebuttons.so") at ../src/npw-config.c:559
#16 0x08049302 in process_plugin_dir (
    plugin_dir=plugin_dir@entry=0x804bcbd "/usr/lib/mozilla/plugins", 
    test=test@entry=0x8049580 <is_wrapper_plugin_0>, 
    process=process@entry=0x8049660 <remove_plugin_cb>)
    at ../src/npw-config.c:633
#17 0x0804a294 in auto_remove_plugins () at ../src/npw-config.c:813
#18 process_remove (argc=0, argv=0xbfffec60) at ../src/npw-config.c:1047
#19 0x08048eed in main (argc=3, argv=0xbfffec54) at ../src/npw-config.c:1113

CC: (none) => olav, tmb

Here's a better backtrace with glibc-debug and glib2.0-debug installed.

#0  __strcmp_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:229
#1  0xb7ef1513 in g_str_equal (v1=0xb723a3e0, v2=0xb7b7a3e0) at ghash.c:1706
#2  0xb7ef0b55 in g_hash_table_lookup_node (hash_return=<synthetic pointer>, 
    key=0xb7b7a3e0, hash_table=0x8062820 = {...}) at ghash.c:386
#3  g_hash_table_lookup (hash_table=0x8062820 = {...}, 
    key=key@entry=0xb7b7a3e0) at ghash.c:1076
#4  0xb7f11242 in quark_from_string (duplicate=0, 
    string=0xb7b7a3e0 "-g-type-private--GTypeFlags") at gquark.c:173
#5  g_quark_from_static_string (
    string=string@entry=0xb7b7a3e0 "-g-type-private--GTypeFlags")
    at gquark.c:239
#6  0xb7b427a2 in gobject_init_ctor () at gtype.c:4341
#7  0xb7feecbe in call_init (l=<optimized out>, argc=argc@entry=3, 
    argv=argv@entry=0xbffff184, env=env@entry=0xbffff194) at dl-init.c:84
#8  0xb7feedb4 in call_init (env=0xbffff194, argv=0xbffff184, argc=3, 
    l=<optimized out>) at dl-init.c:36
#9  _dl_init (main_map=main_map@entry=0x805c688, argc=3, argv=0xbffff184, 
    env=0xbffff194) at dl-init.c:132
#10 0xb7ff298a in dl_open_worker (a=0xbfffacac) at dl-open.c:566
#11 0xb7feeb3a in _dl_catch_error (objname=objname@entry=0xbfffaca4, 
    errstring=errstring@entry=0xbfffaca8, 
    mallocedp=mallocedp@entry=0xbfffaca3, 
    operate=operate@entry=0xb7ff25e0 <dl_open_worker>, 
    args=args@entry=0xbfffacac) at dl-error.c:177
#12 0xb7ff2244 in _dl_open (
    file=0x806e140 "/usr/lib/mozilla/plugins/skypebuttons.so", 
    mode=-2147483647, caller_dlopen=0x8049397 <is_wrapper_plugin+39>, 
    nsid=<optimized out>, argc=3, argv=0xbffff184, env=0xbffff194)
    at dl-open.c:650
#13 0xb7fbfcbc in dlopen_doit (a=0xbfffae60) at dlopen.c:66
#14 0xb7feeb3a in _dl_catch_error (objname=0x80501b4, errstring=0x80501b8, 
    mallocedp=0x80501b0, operate=0xb7fbfc30 <dlopen_doit>, args=0xbfffae60)
    at dl-error.c:177
#15 0xb7fc03bc in _dlerror_run (
    operate=operate@entry=0xb7fbfc30 <dlopen_doit>, args=args@entry=0xbfffae60)
    at dlerror.c:163
#16 0xb7fbfd71 in __dlopen (
    file=0x806e140 "/usr/lib/mozilla/plugins/skypebuttons.so", mode=1)
---Type <return> to continue, or q <return> to quit---
    at dlopen.c:87
#17 0x08049397 in is_wrapper_plugin (
    plugin_path=plugin_path@entry=0x806e140 "/usr/lib/mozilla/plugins/skypebuttons.so", out_plugin_info=out_plugin_info@entry=0xbfffaed5)
    at ../src/npw-config.c:532
#18 0x080495a9 in is_wrapper_plugin_0 (
    plugin_path=plugin_path@entry=0x806e140 "/usr/lib/mozilla/plugins/skypebuttons.so") at ../src/npw-config.c:559
#19 0x08049302 in process_plugin_dir (
    plugin_dir=plugin_dir@entry=0x804bcbd "/usr/lib/mozilla/plugins", 
    test=test@entry=0x8049580 <is_wrapper_plugin_0>, 
    process=process@entry=0x8049660 <remove_plugin_cb>)
    at ../src/npw-config.c:633
#20 0x0804a294 in auto_remove_plugins () at ../src/npw-config.c:813
#21 process_remove (argc=0, argv=0xbffff190) at ../src/npw-config.c:1047
#22 0x08048eed in main (argc=3, argv=0xbffff184) at ../src/npw-config.c:1113

So, the issue comes when kopete is installed and it's trying to dlopen() skypebuttons.so, and it appears the crash is when it's trying to load the libraries that skypebutton.so is linked to.  g_str_equal gets called with two values as arguments, called node_key and key in ghash.c.  key is "-g-type-private--GTypeFlags", but node_key is an address that's out of bounds, hence the crash.  I'm not sure why it's looking something up in a hash table.

Anyway, it looks like kopete is broken.  Maybe it needs to be rebuilt for some reason, or maybe there's some other bug.

Morgan, does ltrace show it's also crashing for you on skypebuttons.so?

Summary: nspluginwrapper segfaults because of something in default KDE and GNOME installs => nspluginwrapper segfaults because of (at least) kopete
CC: (none) => balcaen.john, lmenut, mageia

Unfortunately i have to say I uninstalled every package whose name contain kopete, do not have skypebuttons.se, while i still get the nspluginwrapper segfaults when i try to install it.

If you think it would help i can install it and read up on ltrace.

If it's crashing without kopete installed, let's figure out what is crashing yours.

Simply run:
ltrace -s 64 nspluginwrapper -a -r

and you should see something like this at the end:
dlopen("/usr/lib/mozilla/plugins/skypebuttons.so", 1 <no return ...>

Ah, OK.  I get
dlopen("/usr/lib64/mozilla/plugins/libtotem-narrowspace-plugin.so", 1 <no return ...>

so i uninstalled totem-mozilla, and nspluginwrapper finally works on the machine i am on writning this.

On my wifes machine i get
dlopen("/usr/lib64/mozilla/plugins/libtotem-gmp-plugin.so", 1 <no return ...>

which is *another!* file in libtotem-mozilla. I uninstalled that, and got:
dlopen("/usr/lib64/mozilla/plugins/libflashplayer.so", 1 <no return ...>

uninstalled flash-player-plugin (that hurts...), and got:
dlopen("/usr/lib64/mozilla/plugins/libgnome-shell-browser-plugin.so", 1 <no return ...>

uninstalled gnome-shell (and dependencies... we only actually use KDE anyway)
and finally nspluginwrapper works.

Loosely related comment, not directly answering the actual issue you are facing: the last release of nspluginwrapper is dated from 30/06/2011, meaning 2 years and a half. For something moving as fast as browsers, I wouldn't rely on it for anything important.

Despite the fact than you can't install both 32 and 64 bits versions of the same application, by packaging constraints, nothing prevents you to install another 32bits browser for running your 32bits-only plugins, instead of trying to mix everything in a single one. With the associated risks you just faced.

CC: (none) => guillomovitch

Guillaume, that's a very good point, and perhaps we should remove nspluginwrapper for mga5.

Morgan, it does not segfault for me with flash-player-plugin, which is why I couldn't reproduce this initially.  It does crash with totem-mozilla or gnome-shell, with the same backtrace.

It is also on ubuntu launchpad:
https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/1203964
https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/1105417

Summary: nspluginwrapper segfaults because of (at least) kopete => nspluginwrapper segfaults because of kopete, totem-mozilla, or gnome-shell (possible glib2.0 issue)

My wifes machine is due for reinstall this weekend as it have many odd problems our other mga4 systems do not have.  After that i think nspluginwrapper will work without removing too much, like on my other system above.

It would be sad to loose nspluginwrapper as it is a neat solution - when it works.  Possibly add in the package description and maybe add a post install message telling nspluginwrapper segfaults with some plugins, and tell to install a 32 bit browser instead.

I do not know how many plugins that are still 32-bit only.

My bank demand firefox, and that we use their crappy 32 bit security plugin.
Maybe we can make a wiki page that explains how to have both 32 and 64 bit firefox installed.  It is possible by installing firefox from mozilla "manually" i think, possibly even in users home if needed.  Well i have not tried... yet...

That said, yes we can probably use only 32 bit firefox, can not be that very much slower, and Opera for 99% of the other sites.

A year ago I discussed another bug with the he author of nspluginwrapper, and he said say he will probably not do more development on it.
https://github.com/davidben/nspluginwrapper/issues/47

Yes maybe it is best to let nspluginwrapper go.

I think we should just let this rest for a while.
Maybe it magically works later, like when kwrite will be able to launch normally again...  I also have another thing that also independent of nspluginwrapper sometimes silently exits om mga4-64 but not mga3-64, namely the BankID kludge i wanted nspluginwrapper for... also some printing issues.... I think something is not yet optimal in glib2/kernel/KDE/whatever.  Waiting, hoping... (in mean time we use a virtual machine with mga3 for old stuff that dont work in mga4)

Lowering priority and severity, as the real issue is that reliable and modern software should work on modern systems. If nspluginwrapper will work, good, but not critical.

Whiteboard: (none) => MGA4TOO
Severity: critical => major
Priority: High => Normal

This is substantially more severe. I have a vexing and severe situation on my hands dealing with the Adobe Acrobat Reader. I recently migrated my systems from Mageia 3 to Mageia 4. The change in glib and gtk-pixbuf has created some sort of CPU spiking condition in certain instances when an Adobe PDF with FireFox.

Before I go into a huge amount of detail. I want to lay down the following: Due to the nature of my employment, and the technical requirements of the tasks I preform using Adobe Reader for Linux, no alternative PDF Readers will be entertained The requirements of this application are that forms be filled out online and submitted to a website using the Oracle JRE and Adobe Acrobat Reader via the NPAPI Plugin. None of the Alternative readers have this online submission capability. Evince is close, but it's NPAPI Plugin is not packaged and in a very Alpha state. This did work under Mageia 2 and 3.

With that out of the way. Under Mageia 4, there exists a situation where the Acrobat Reader can freeze the Browser tab. This is seemingly random, and unpredictable, and can be affected by exactly what PDF you open. When this happens, acroread spikes the CPU to 100% and the browser must be closed, and sometimes the acroread process terminated by a kill -9

When running acroread stand alone, Acroread displays the following errors extremely commonly. Acrobat Reader 9.5.5, the last version they made. nspluginwrapper 1.4.4. All other updates are current for Mageia 4 from main/updates and contrib/updates. This can also be reproduced under Rosa 2012.1 but CAN NOT Be reproduced under Fedora 20.

ADditionally, the problem does not happen if the NPAPI wrapper is not used. If in preferences you tell FireFox to merely launch the acroread executable with %f or %u, the lock up never occurs.

I tried disabling the NPAPI Plugin, and just using Acroread directly. Its as I feared, the PDF is submitting information back via https to a CGI, without the NPAPI layer, the PDF can't communicate with the Javascripting via CGI, and thus, can't save the Document. The document opens, but you cannot save it back to the CGI.

CC: (none) => zombie_ryushu

reassinging to BugSquad, because nobody maintains nspluginwrapper now.

Also, there was no action in this report since over a year ago. Is this bug still valid? If so, in which Mga version (cauldron and/or Mga5) do you still see it?

Not yet CC'ing the nspluginwrapper-committers, that can still be done when we know this issue didn't get fixed.

CC: (none) => marja11
Whiteboard: MGA4TOO => NEEDINFO
Assignee: mageia => bugsquad

(In reply to Marja van Waes from comment #24)
> reassinging to BugSquad, because nobody maintains nspluginwrapper now.
> 
> Also, there was no action in this report since over a year ago. Is this bug
> still valid? If so, in which Mga version (cauldron and/or Mga5) do you still
> see it?
> 
> Not yet CC'ing the nspluginwrapper-committers, that can still be done when
> we know this issue didn't get fixed.

Closing as old since there was no reply in one year. Reopen if needed.

Resolution: (none) => OLD
Status: NEW => RESOLVED

This is still valid, in fact its worse, in Mageia 5, attempting to use 32 bit Acroread with nspluginwrapper results in FireFox locking up the tab.

32 bit Acroread is the only application where nsplugin is used anymore, as there is no other Linux PDF Reader with  XFA Support unless you use Pipelight and run the Windows version.

Status: RESOLVED => REOPENED
Resolution: OLD => (none)

Assigning to all packagers collectively since nspluginwrapper has no registered maintainer.

Whiteboard: NEEDINFO => (none)
Assignee: bugsquad => pkg-bugs

I opened this three years ago because needed by the secure authentication " BankID " .  Generally that app is nowadays run in smartphones instead and as "everybody" nowadays seem happy with that, it is less important.  I have not even tried to install it since the fail above in feb 2014.

Plugins are dead, closing this.

Resolution: (none) => OLD
Status: REOPENED => RESOLVED