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.
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.