Bugzilla – Bug 116389
problem with pdf
Last modified: 2006-04-07 15:27:48 UTC
Firefox (suse version, fresh install of firefox) crashes when trying to open a pdf file (no problem with seamonkey). I think there is a real problem. This arise even on a new user (default config file) acroread is selected, but if I select kpdf I hit the same crash. I don't know where are the firefox logs :-( the pdf is from openoffice and open in konqueror or seamonkey without problem
Do you open via a plugin or did you chose to open the file with a certain application?
Well. It's not so easy. My config of firefox is pretty old and went from many FF updates. right now id did an RC1 update and got in firefox: * helper app pointing to acroread. Changing this to kpdf don't change nothing (firefox keep crashing), probably because of the second * * there is a plugin installed. When I *delete* the helper part, ff keep crashing. there is no pdf plugin in the plugin folder. *this is the bug. FF keep thinking it has a pdf plugin and it doesn't, so it's crashes.* in fact, I righ now reinstall acrobat and it's plugins and all works well.
I can reproduce this too. The install is 10.0, upgraded from preview1 to rc1 or 2, MozillaFirefox-1.0.6-13 and /home contains Firefox configs from previous SUSE versions. If I try to open some random PDFs found in google, opening with plugin, no dialog appears to ask what action to take, * For a newly created user, the PDF downloads but the acrobat plugin is not displayed. * For an existing user, the PDF downloads and firefox crashes: /usr/bin/firefox: line 251: 17199 Segmentation fault I can't see any special policy for PDF in the File Types preferences list. The Plug-Ins dialog shows there is a plugin active for PDF. Tried installing debuginfo and running firefox-bin, but it wouldn't start in gdb. Is there a trick for getting a backtrace out of firefox?
Created attachment 50262 [details] pluginreg.dat for an existing user This is the pluginreg.dat from an existing user where Firefox crashes on trying to open any pdf.
As long as there are plugins for pdf no URI handling will be performed. Please remove the dragonegg plugin from /opt/MozillaFirefox/lib/plugins and start the browser again. Can you still reproduce? You can get a backtrace via LD_LIBRARY_PATH=/opt/MozillaFirefox/lib gdb /opt/MozillaFirefox/lib/firefox-bin
I have the same issue. This is on a system that had a 9.3 - 10.0 RC1 upgrade. The problem occurs shortly after a second window is drawn, presumably for the PDF display. I hope the following helps. program received signal SIG33, Real-time event 33. [Switching to Thread 1105066928 (LWP 15971)] 0xffffe410 in __kernel_vsyscall () (gdb) backtrace #0 0xffffe410 in __kernel_vsyscall () #1 0x401b2cec in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x40198cdf in PR_Lock () from /usr/lib/libnspr4.so #3 0x401990b1 in PR_WaitCondVar () from /usr/lib/libnspr4.so #4 0x080ec6ce in nsAdoptingCString::nsAdoptingCString () #5 0x080ec7e0 in nsAdoptingCString::nsAdoptingCString () #6 0x4019ec5c in PR_Select () from /usr/lib/libnspr4.so #7 0x401b0297 in start_thread () from /lib/tls/libpthread.so.0 #8 0x40c5733e in clone () from /lib/tls/libc.so.6 #9 0x41ddfbb0 in ?? () (gdb)
I have this problem too on a fresh 10.0 RC1 install. Here is what i see when I launch Firefox from a terminal NPP_SetWindow original_x_errhandler: (nil) NPP_SetWindow NPP_SetWindow /usr/bin/firefox: line 251: 17254 Erreur de segmentation $MOZ_PROGRAM $MOZ_LANG
again to all: Does it still happen if the dragonegg plugin is removed?
Removing /opt/MozillaFirefox/lib/plugins/libdragonegg.so appears to resolve the problem. Thanks!
*** Bug 119044 has been marked as a duplicate of this bug. ***
Dirk, this looks like a conflict between dragonegg and acroread. could you check this, please?
*** Bug 128893 has been marked as a duplicate of this bug. ***
Unlike RC1, removing libdragonegg.so does NOT resolve the issue with 10.0 final!
*** Bug 118466 has been marked as a duplicate of this bug. ***
After replacing the soft link /opt/MozillaFirefox/lib/plugins/nppdf.so by the link target /usr/X11R6/lib/Acrobat7/Browser/intellinux/nppdf.so (i.e. just cp it, like the way /usr/X11R6/lib/Acrobat7/Browser/install_browser_plugin installs the plugin) firefox will display pdf again (embedded, via acrobat plugin). BTW, SUSE LINUX 9.2 MozillaFirefox-1.0.7 works with the original setup (i.e. /opt/MozillaFirefox/lib/plugins/nppdf.so as a soft link).
This problem does not occur in mozilla and SUSE 10
comment #16: Mozilla doesn't include libdragonegg.so on SUSE Linux 10.0. comment #13: removing the dragonegg RPM always helped on every system I saw. Maybe the link was reinstalled if you just removed it. Dirk, have you found out what happens, if we have two application/pdf handlers? On SUSE Linux 10.1 we mustn't have the same problem. If we can't resolve it easily we have to find a workaround to make sure that not both plugins are installed. Worst case would be to separate the Acrobat plugin to a subpackage and let it conflict with dragonegg.
on 10.1alpha4 I found that - dragonegg and acroread installed -> I get a PDF displayed with dragonegg help w/o a crash or empty page But still this isn't the expected behaviour, because the user has no choice what should be used without removing one or the other package. (Firefox displays in its preferences window that for PDF the acrobat plugin is used; so that's also wrong)
*** Bug 141983 has been marked as a duplicate of this bug. ***
Dirk, what is the status here? We will have a problem with this in 10.1 if we don't come up with a solution. If Firefox doesn't crash it doesn't show anything if acroread and dragonegg is installed. (I think that's the default.) Any suggestions/ideas?
The following statement indicates that dragonegg may be broken. Firefox should choose (randomly) one plugin as mimehandler but still displays something. So Firefox doesn't show anything w/o acroread and just dragonegg installed. From: Silviu Marin-Caea <silviu_marin-caea@fieldinsights.ro> Reply-To: opensuse-factory@opensuse.org To: opensuse-factory@opensuse.org Date: Sun, 5 Feb 2006 09:56:17 +0200 Subject: Re: [opensuse-factory] Firefox plugins: where are they now, in 10.1beta3? On Saturday 04 February 2006 20:32, Wolfgang Rosenauer wrote: > Could you please check, if removing acroread fix the problem or only the > removal of dragonegg works? Removing nppdf does not fix the problem. PDFs are not displayed in Firefox. Removing libdragonegg does. Acrobat is loaded in Firefox and the page is displayed.
I'll look at it today. the problem is that mozilla caches mime associations of plugins even though the plugin disappeared or changed its exported mime list. Thats a known bug.
I'm unsure what to do with this bugreport. First of all it was relabled against 10.1 which doesn't have "the" Mozilla bug anymore that occured when the cache was stale and pointing to a plugin handler that got meanwhile uninstalled. Also, the statement "nppdf removing does not work" is unclear to me. The issue is that mozilla caches the destination of a symlink. so surprise, removing %_libdir/nppdf.so does not change anything because Mozilla cached the place the symlink points to. uninstalling the acrobat rpm would have made the difference of switching to dragonegg instead. Also, there is no way to influence the priority in which mozilla chooses competing plugins. it doesn't even have a way to disable a plugin if there are conflicts, even though it theoretically should support it (via the enabledPlugins attribute, which is however always true). Even worse, even if you deinstall the acroread plugin (and it picked that one before), it won't notice the stale cache and redo the mime type resolve. Anyway, I've tried all possible combinations of installing/uninstalling acroread, dragonegg and kpdf and seemed to have found a couple of issues along the way, the biggest one being that the error message of dragonegg wasn't being displayed properly, instead an empty window was created. Besides that I cannot find an issue with current 10.1 betas anymore.
Besides that uninstalling dragonegg can cause mozilla to reevaluate some mimetype exports of installed plugins (and as a side effect can fix whatever setup issue people are experiencing), I don't think it deserves the blame it gets ;) for me I'd mark this as FIXED for 10.1. I'll try backporting the fixes to a 10.0 tree and see if it doesn't look too bad there either. then we can release that as a YOU.
At least for me it worked perfect just to uninstall dragonegg...maybe a change in the default setup to not install dragonegg could be sufficient.
Axel, what did work perfect? What did you have installed? 10.0 or 10.1 ? acroread or no acroread? kpdf or no kpdf? dragonegg or no dragonegg? which issue did you see? a crash? an empty window? kpdf being used even though acroread was installed?
My (double) bug was 141983, pls see bug description there. I run 10.0, I've deinstalled dragonegg, installed is MozillaFirefox-1.5.0.1-5.1 acroread kdegraphics3-pdf-3.5.1-6 (for kpdf) *no* dragonegg ...no probs anymore.
ok, that crash has been fixed.
I guess this can be closed now and does not need to be in NEEDINFO anymore?
I still see one issue that I'd like to address before closing the report.
I would like to add my experiences here. My SUSE version is: cat /etc/SuSE-release SUSE LINUX 10.0 (i586) OSS VERSION = 10.0 My Firefox version is (from about firefox): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060126 SUSE/1.5.0.1-5.1 Firefox/1.5.0.1 My version of Adobe (from Yast) acroread - Adobe Reader for PDF Files Version: 7.0.1-4 Installed: 7.0.1-4 Size: 93.2 MB Media No.: 1 Observation 1. ============== As root start firefox. Check Edit -> Preferences -> Downloads -> View&Edit actions I see extension PDF is set to "Open with Adobe Reader 7.0" Find a site with a pdf link - click it, the pdf opens in the browser using the KDE Parts (libdragonegg.so) Plugin. Observation 2. ============== Repeat the steps from Observation 1. as a non-privileged user. The result is that the pdf fails to display, a blank grey browser window is shown instead. Observation 3. ============== move or remove libdragonegg.so mv /usr/lib/browser-plugins/libdragonegg.so /root/ Again as non-privileged user run firefox and click on a pdf link. The document opens within the browser successfully in the Adobe 7.0 plugin viewer. Hope this helps, Warren.
ok, fixed.