Bug 719153

nspluginwrapper-1.4.0-1.fc14.i686 causes a complete crash of Firefox.

With nspluginwrapper-1.3.2-1.fc14 I am constantly collecting entries like that in /var/log/messages:

kernel: [274370.758345] npviewer.bin[18894]: segfault at 626220 ip 0000003c0888cfaa sp 00007fff829a41f8 error 6 in libc-2.13.so[3c08800000+191000]
abrt[18904]: saved core dump of pid 18894 (/usr/lib64/nspluginwrapper/npviewer.bin) to /var/spool/abrt/ccpp-1310489988-18894.new/coredump (1822720 bytes)
abrtd: Directory 'ccpp-1310489988-18894' creation detected
abrtd: Blacklisted package 'nspluginwrapper'
abrtd: Corrupted or bad crash /var/spool/abrt/ccpp-1310489988-18894 (res:2), deleting

and indeed nothing in /var/spool/abrt/.  So the whole setup becomes entirely
useless and 'nspluginwrapper' simply stopped working.  In particular PDF files are indeed no longer handled.

(In reply to comment #2)
> With nspluginwrapper-1.3.2-1.fc14 I am constantly collecting entries like that
> in /var/log/messages:

Downgrading to nspluginwrapper-1.3.0-15.fc14 makes this to work again.

I'm getting lots of similar complaints from my users on F14, and I'm seeing similar myself on F15.  Killing old plugin processes like:

orion    30772 30542  0 Sep22 ?        00:00:00 /usr/lib/firefox-6/xulrunner/plugin-container /usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.nppdf.so -greomni /usr/lib/firefox-6/xulrunner/omni.jar -appomni /usr/lib/firefox-6/omni.jar 30542 true plugin
orion    30785 30772  0 Sep22 ?        00:00:00 /usr/lib/nspluginwrapper/npviewer.bin --plugin /usr/lib/mozilla/plugins/nppdf.so --connection /org/wrapper/NSPlugins/nppdf.so/30772-2/1152567071

will allow a pdf to load.

Similar talk in Adobe forums.  No solution as of yet.

(In reply to comment #5)
> Similar talk in Adobe forums.  No solution as of yet.

AFAICT these conversations on Adobe forums, and differences between 32 and 64-bit binaries are utterly irrelevant.  I am not using acroread plugin to handle PDF files but whatever I configured for mozplugger.  This is what I see after installing on a 32-bit machine nspluginwrapper-1.4.4-1.fc15.i686 (the latest one available on koji):


kernel: [  691.013691] npviewer.bin[2523]: segfault at 806b850 ip 002361a6 sp bf9f4718 error 6 in libc-2.13.so[110000+183000]
abrt[2533]: saved core dump of pid 2523 (/usr/lib/nspluginwrapper/npviewer.bin) to /var/spool/abrt/ccpp-1317234671-2523.new/coredump (1482752 bytes)
abrtd: Directory 'ccpp-1317234671-2523' creation detected
abrtd: Blacklisted package 'nspluginwrapper'
abrtd: Corrupted or bad crash /var/spool/abrt/ccpp-1317234671-2523 (res:2), deleting

As mentioned before reverting that back to nspluginwrapper-1.3.0-15.fc14 makes all of this to work again.  In other words any version of nspluginwrapper above 1.3.0-15 qis plain broken.

The only difference between 64 and 32-bits is that in the later case one can find plugins which allow to do an end run around a crashing npviewer.bin.

After removing nspluginwrapper from BlackList in /etc/abrt/abrt.conf, and setting there OpenGPGCheck to "no", I got the following on a 32-bit system with installed nspluginwrapper-1.4.4-1.fc15.i686 from koji (and its nspluginwrapper-debuginfo):

kernel: [ 3602.725425] npviewer.bin[3883]: segfault at 806b850 ip 005771a6 sp bff6b068 error 6 in libc-2.13.so[451000+183000]
abrt[3893]: saved core dump of pid 3883 (/usr/lib/nspluginwrapper/npviewer.bin) to /var/spool/abrt/ccpp-1317683977-3883.new/coredump (1482752 bytes)

It was enough to try to look at some PDF file in a web browser.

A compressed coredump file is 243K in size and can be supplied if needed.
A command executed which generated this core is:

/usr/lib/nspluginwrapper/npviewer.bin --plugin /usr/lib/mozilla/plugins/mozplugger.so --connection /org/wrapper/NSPlugins/mozplugger.so/3836-2/1960583335

Note that below, when printing '*g_rpc_connection', this "/org/wrapper/..." string shows up as 'sun_path' but with a leading null. Looking at the code in rpc.c this is expected if USE_ANONYMOUS_SOCKETS is in force.

(gdb) where
#0  0x005771a6 in __memset_sse2 () from /lib/libc.so.6
#1  0x0013570b in NP_Initialize () from /usr/lib/mozilla/plugins/mozplugger.so
#2  0x0804f6dd in g_NP_Initialize (connection=0x91f9fb8)
    at ../src/npw-viewer.c:3601
#3  handle_NP_Initialize (connection=0x91f9fb8) at ../src/npw-viewer.c:3647
#4  0x08059e63 in _rpc_dispatch_1 (connection=0x91f9fb8, message=0xbff6b380)
    at ../src/rpc.c:1591
#5  0x0805a0b8 in _rpc_dispatch (connection=0x91f9fb8, message=0xbff6b380, 
    expected_msg_tag=-3008) at ../src/rpc.c:1622
#6  _rpc_dispatch_until (connection=0x91f9fb8, message=0xbff6b380, 
    expected_msg_tag=-3008) at ../src/rpc.c:1645
#7  0x0805b6dd in rpc_sync (connection=0x91f9fb8) at ../src/rpc.c:1788
#8  0x0804b23a in do_main (argc=<value optimized out>, argv=0xbff6d504)
    at ../src/npw-viewer.c:4977
#9  main (argc=<value optimized out>, argv=0xbff6d504)
    at ../src/npw-viewer.c:5160
(gdb) f 8
#8  0x0804b23a in do_main (argc=<value optimized out>, argv=0xbff6d504)
    at ../src/npw-viewer.c:4977
4977              rpc_sync(g_rpc_connection);
(gdb) l
4972
4973            /* DISPATCH */
4974            if (ready) {
4975              // Before we dispatch, sync with the browser. We don't need to
4976              // check for RPC requests as the rpc_sync will handle them.
4977              rpc_sync(g_rpc_connection);
4978              g_main_context_dispatch(context);
4979              rpc_end_sync(g_rpc_connection);
4980            } else if (rpc_fd.revents & rpc_fd.events) {
4981              // We don't have anything, but there is an incoming RPC
(gdb) p *g_rpc_connection
$3 = {type = 0, refcnt = 1, status = 1, socket = 8, socket_path = 
    0x91fa0a8 "", socket_addr = {sun_family = 1, sun_path = 
    "\000/org/wrapper/NSPlugins/mozplugger.so/3836-2/1960583335", '\000' <repeats 52 times>}, socket_addr_len = 57, server_socket = 7, server_thread_active = 
    0, server_thread = 0, types = 0x91fa078, methods = 0x91fa090, 
  error_callback = 0x804b5c0 <rpc_error_callback_cb>, error_callback_data = 
    0x0, dispatch_depth = 1, invoke_depth = 0, handle_depth = 1, is_sync = 
    false, pending_sync_depth = 0}
(gdb) f 2
#2  0x0804f6dd in g_NP_Initialize (connection=0x91f9fb8)
    at ../src/npw-viewer.c:3601
3601      NPError ret = g_plugin_NP_Initialize(&mozilla_funcs, &plugin_funcs);
(gdb) l
3596      // Initialize function tables
3597      // XXX: remove the local copies from this file
3598      NPW_InitializeFuncs(&mozilla_funcs, &plugin_funcs);
3599
3600      D(bugiI("NP_Initialize version=%d\n", version));
3601      NPError ret = g_plugin_NP_Initialize(&mozilla_funcs, &plugin_funcs);
3602      *plugin_version = plugin_funcs.version;
3603
3604      if (plugin_capabilities) {
3605            int num = 0;
(gdb) p plugin_funcs
$4 = {size = 80, version = 22, newp = 0, destroy = 0, setwindow = 0, 
  newstream = 0, destroystream = 0, asfile = 0, writeready = 0, write = 0, 
  print = 0, event = 0, urlnotify = 0, javaClass = 0x0, getvalue = 0, 
  setvalue = 0, gotfocus = 0, lostfocus = 0, urlredirectnotify = 0, 
  clearsitedata = 0, getsiteswithdata = 0}

Function g_plugin_NP_Initialize is dynamically assigned on line 5144 of npw-viewer.c, making this more "interesting".  In any case I am not sure how to debug this and what is really wrong here but this is definitely broken.

With mozplugger-debuginfo.i686 added to the picture gdb reports frame 1 above as

#1  0x0013570b in NP_Initialize (nsTable=0x806aaa0, pluginFuncs=0x806aa40)
    at /usr/include/bits/string3.h:86

and a segfault happens in  __NTH (memset (void *__dest, int __ch, size_t __len))
from that header.  So it looks like that nspluginwrapper scribbles over a random memory.

The same problem with fully updated Fedora 16:

firefox-7.0.1-1.fc16.x86_64
mozplugger-1.14.2-1.fc15.x86_64
nspluginwrapper-1.4.4-1.fc16.x86_64
(evince-3.2.0-2.fc16.x86_64 <-- mozplugger configured to open pdf with this)

While reloading the PDF url opened in Firefox tab, I am getting lines
in /var/log/messages like these (excluding ABRT ones):

Oct 10 12:05:09 jptux kernel: [56537.399990] npviewer.bin[23218]:
    segfault at 6262c0 ip 000000361588954a sp 00007fff1b85aee8 error 6
    in libc-2.14.90.so[3615800000+1ab000]


BTW, these bugs seem to discuss the same or a very similar issue:
 * bug 451610 (Fedora 14, was Fedora 13)
 * bug 719159 (Fedora 15)

nspluginwrapper-1.4.4-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/nspluginwrapper-1.4.4-3.fc15

nspluginwrapper-1.4.4-3.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/nspluginwrapper-1.4.4-3.fc16

Re comment 8:
nspluginwrapper-1.4.4-3.fc16.x86_64 works for me (so far).  Thanks!

nspluginwrapper-1.4.4-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

nspluginwrapper-1.4.4-3.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.