Bug 719153 - nspluginwrapper - PDF's fail to embed in browser window when a PDF link is selected
Summary: nspluginwrapper - PDF's fail to embed in browser window when a PDF link is se...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nspluginwrapper
Version: 15
Hardware: i686
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL: http://forums.adobe.com/message/39411...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-05 22:08 UTC by Randy Berry
Modified: 2011-11-25 02:22 UTC (History)
5 users (show)

Fixed In Version: nspluginwrapper-1.4.4-3.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-24 13:42:30 UTC
Type: ---


Attachments (Terms of Use)

Description Randy Berry 2011-07-05 22:08:49 UTC
Description of problem:

PDF's fail to embed in browser window when a PDF link is selected.

Version-Release number of selected component (if applicable):

firefox-3.6.18-1.fc14.i686
mozplugger-1.14.2-1.fc14.1686
nspluginwrapper-1.3.2-1.fc14.i686
xpdf-3.02-16.fc14.i686

How reproducible:
Always

Steps to Reproduce:
1. Load firefox browser
2. Navigate to a page with a PDF download link.
3. Click the PDF link

Actual results:

Browser page turns white (blank) then briefly turns black, then white again.
PDF is never loaded.

Expected results:

PDF file should load and be viewable from browser window. At least that's the
way it has always worked before. I removed nspluginwrapper-1.3.2-1.fc14.i686 and installed nspluginwrapper-1.3.0-14.fc14.i686 from koji and the problem went away. PDF's now embed in browser.

Additional Info:

I'll try installing nspluginwrapper-1.4.0-1.fc14.i686 from koji later tonight to see if the problem is corrected. If not, I will add details here.

Also; for what it's worth this error also occurs with Spot's Firefox4 for F14.

Comment 1 Randy Berry 2011-07-06 01:45:39 UTC
nspluginwrapper-1.4.0-1.fc14.i686 causes a complete crash of Firefox.

Comment 2 Michal Jaegermann 2011-07-12 21:36:56 UTC
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.

Comment 3 Michal Jaegermann 2011-07-12 21:55:23 UTC
(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.

Comment 4 Orion Poplawski 2011-09-27 19:09:20 UTC
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.

Comment 5 Orion Poplawski 2011-09-27 19:22:22 UTC
Similar talk in Adobe forums.  No solution as of yet.

Comment 6 Michal Jaegermann 2011-09-28 19:37:26 UTC
(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.

Comment 7 Michal Jaegermann 2011-10-04 01:11:22 UTC
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.

Comment 8 Jan Pokorný [poki] 2011-10-10 10:30:18 UTC
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)

Comment 9 Fedora Update System 2011-10-24 13:31:35 UTC
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

Comment 10 Fedora Update System 2011-10-24 13:31:52 UTC
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

Comment 11 Jan Pokorný [poki] 2011-10-24 15:35:07 UTC
Re comment 8:
nspluginwrapper-1.4.4-3.fc16.x86_64 works for me (so far).  Thanks!

Comment 12 Fedora Update System 2011-11-05 01:18:47 UTC
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.

Comment 13 Fedora Update System 2011-11-25 02:22:48 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.