For 90 % of all web pages (try e.g. "www.heise.de/ct"), my mozilla reproducibly crashes when I try to print the page: A few moments after I press the print button, mozilla disappears with exit status 11. It obviously gets and catches a SIGSEGV and terminates: The grsec kernel reports a signal 11 delivered to mozilla-bin, but no core file is written. The crash seems to be independent of the printer settings (also for the defaults immediate after a fresh install), it even happens when printing to a file, leaving an incomplete postscript output file. Only very few pages print, and they print reliably. This is mozilla 1.0-r3, gcc 3.1.1-r1 with most optimizations turned on, use gtk2, cups for printing. Any tips welcome. First of all, I have no idea (and want to find out quickly!) if this is a problem specific to my installation, a gentoo mozilla port problem, or a general mozilla issue. By the way: Will a gentoo port of "xprint" become available any time soon (most likely solving the problem and also significantly improving mozilla's print quality), or shouldn't I hold my breath waiting for xprint?
Mozilla 1.1_beta1/gtk1/gcc2.95/cups doesn't seem to have that problem. I think it could be related to gtk2, or else they fixed it between 1.0 and 1.1 :) (I'm actually surprised you find the Mozilla gtk2 port useful. I tried it and rebuilt in disgust) Does it also crash when you do print preview? About the xprint: Any useful URLs?
moz 1.0 r3 / gcc 3.1.1 / gtk1 / cups doesn't have the problem: Printing works, at least 5 of the pages which crashed yesterday print fine now (well, not really fine, but as bad as they usually print with mozilla). Hence, the problem is caused by gtk2. Print preview was also broken yesterday (random crashes, used 100 % cpu), it seems to be ok now. I didn't build mozilla with gtk2 on purpose, I just happened to have gtk2 in my make.conf, and I didn't know that this is a bad idea when building mozilla. For xprint, see xprint.mozdev.org: Basically, this is an X window server with a backend generating Postscript instead of the usual framebuffer backend. However, my new mozilla 1.0 / gtk1 / gcc 3.1.1 is unstable like hell: It crashes randomly every few minutes with sig 11 or sig 4 (!) when opening a new web page (not reproducible, not bound to specific pages). I'm writing this for the third time now... Two hints: * In many cases, it writes "open dsp: no such file or directory" to the terminal before crashing. * At the very end of the emerge (when deleting the prev install?), some netscape program (the error messages started with ns...) issued some error messages (about four or five) about several shared lib's not found (e.g. something like "lib*superwin*.so*"). As the emerge finished successfully in spite of those messages, I didn't care... Are some prerequisites missing?
--------------------------------cut---------------------------------- * In many cases, it writes "open dsp: no such file or directory" to the terminal before crashing. --------------------------------------------------------------------- Could be a plugin problem. Backup and cleanout /usr/lib/mozilla/plugins/ and see if its fixed.
I rerun regxpcom manually (no errors this time): This fixed all but the "open dsp" crashes - no more sig 4. Then I followed your advice. This cured the "open dsp" crashes. Mozilla seems to be 100 % stable for me now. Question: * What do I loose when movin away this directory? * How do I solve the problem without loosing anything? * How do I avoid such surprises in future? Many thanks!!!
You loose plugins. Move them one for one back in, and see which one is causing it. Im guessing its a multimedia one (not flash or java).
The Flash plugin is causing the crashes with the "open dsp" error message. The Acrobat plugin works fine. The Java pluging doesn't cause any problems, but isn't recognized (mozilla brings up the plugin download dialog when hitting a Java applet even when this link is in the plugins directory).
Using esd ?
No, no sound at all. My computer is *silent*! Will it help to re-emerge flash?
No, you can't build flash without sound support because flash is not an open source package. What /might/ work however, is symlinking /dev/null to /dev/dsp, like so: $ ln -s null /dev/dsp I don't know how flash will react to it, but currently I think it complains because it doesn't have a sound device to attach to. otherwise, you'll have to find some dummy driver that implements the linux sound api.
I use gplflash, and it even has a -DNOSOUND compile option, however, the Gentoo ebuild does not use it, even if no sound is present 8-[ The /dev/null trick changes the error message: No more "Open dsp: ...", but several "ioctl SNDCTL_...", and then, it SIGSEGV's anyway ... I'll try the "original" plugin, but I can live without flash if that doesn't work. It worries me more that my Java plugin isn't recognized! Anyway, thanks for your efforts!
Well, the original problem is solved (Pri and Sev reduced accordingly), but some questions remain: * Does printing and print preview work in moz 1.1 built with gtk2, or should I change my make.conf to "-gtk2" for building moz 1.1? * Any chances for an xprint package for Gentoo Linux? * Why isn't the Java plugin recognized by my mozilla at all, although it is installed and linked to the plugins directory? * Could the gplflash ebuild build gplflash with -DNOSOUND when no sound is present (or at least when the "use" flags explicitely state that the machine "refuses to have sound").
1) Should, as it did here. But this is really a mozilla and not Gentoo issue. Also, there *is* a warning in use.desc about using "gtk2", so if you do, you should be prepared to keep the pieces. 2) Why? If you really feel it is needed, submit an ebuild. 3) http://bugzilla.mozilla.org/show_bug.cgi?id=116444. Mozilla/gcc issue. 4) File a report with the proper maintainer of gplflash
1) 3) 4) ok. 2.) Well, I'm using Gentoo for 1 month now (as a user, not as a developer), I don't feel ready yet to submit an ebuild for something as complex as xprint (which is an X server with tons of additions). And for the need: * Mozilla strongly recommends xprint instead of the Postscript printing backend for less trouble and better printing quality in the release notes. * The Release notes warn about more than a dozen bugs in the Postscript printing backend which are not present when printing with xprint (when searching bugzilla, you'll find much more). * This list of Postscript backend bugs has not changed for several releases of mozilla now. Obviously, the Postscript backend is dead code, all the development goes to xprint... * The layout of mozilla printouts is really a mess: Misplaced text and graphics, random spacing, text truncated at the right margin, ...
Our X do build default with Xprt .. that not sufficient ?
Indeed, there's a Xprt and a libXp.so on my system (I'll try them later). However, taken from the xprint faq: Please check the "vendor" string of the Xprt server: % Xprt :10 & % xdpyinfo -display :10 | grep -i "vendor string" If this outputs a line like "vendor string: The XFree86 Project, Inc" then you have the Xprt binary build from Xfree86 sources - which are broken - even the newest version [I'll update this as soon as Xfree86 shipps with a working version]. and 7. KNOWN BUGS: ('P'=Problem, 'S'=Solution) - P: Xprt build from Xfree86 sources is completely broken and unuseable. S: Build Xprt from the CVS tree at http://xprint.mozdev.org/ or the X.org X11R6.5.1 sources (note that the client side Xprint extension library ("libXp.so") from Xfree86 is not broken and do not need to be replaced).
Had a second look into it: Gentoo's xfree86 is lacking the xplsprinter tool and the X11/xserver/C/print configuration directory. Without that dir, Xprt immediately quits after starting. So my first step was to copy the config dir from the xprint distribution. Now the xfree86 Xprt comes up and accepts connections, but I didn't manage to print anything with it: No errors, no output. So I built and installed Xprt from the xprint distribution, and it works fine: mozilla produced nice outputs using it. However, what's perhaps more interesting to you: During testing, I found a page which hangs or SIGSEGV's mozilla reliably after being printed, no matter if xprint or conventional printing is used: www.htl-leonding.com
Hmm, ok .. not really a printing guy myself ;-) I guess a solution could be to add a xprint package, but wont it be better if we replaced the Xprt with X, with the fixed one, and distribute the utils as well? I am not one for doing things twice if not needed.
If somebody has contacts to the xfree people or the xprint people, he should perhaps check if and when xfree will offer a working Xprt. Otherwise, I think a working Xprt would be a nice and useful enhancement for Gentoo if somebody finds time. If not, I'll not insist on it. I agree it should be patched into the Xfree ebuild, otherwise, confusion and version mispatches between X and Xprint could result: They share libraries and directories. Btw: Does the page I mentioned also crash your mozilla version? (after printing it, as soon as one tries to load another page)
Dont have a printer at home, and will have to setup Xprt at work to test, as I only tested it without running a dedicated Xprt.
As I said, this crash happens with both the Xprt backand *and* the PostScript backend!
I'm also having a problem with Mozilla (1.2.1) crashing while trying to print. I can get it to crash every time when trying to print the Gentoo installation instructions. I'm using CUPS as my print daemon. The Print Preview function under Mozilla works fine.
GTK2 on older builds is horrific. I think this bug can be removed as we move away from Mozilla 1.0. Please mark as fixed if a more recent build does not exhibit this problem,
Way too much backlog
To expand on the reason for closing this, Mozilla 1.2.x ebuilds stressed avoidance of GTK+ 2, so it's no surprise that it wouldn't work.
