Perhaps you’ve had a recent problem with CUPS and Mozilla. I don’t print often and I recently updated my system’s packages. Today I tried to print something from Thunderbird for the first time in years. Thunderbird crashed so I tried it on Mozilla to print from webmail and to my <sarcasm>amazement</sarcasm> it also crashed! I started investigating and I discovered that it was segmentation faulting. I did some research and I found that Apple’s CUPS version 1.4.4 and Mozilla do not get along. There is a resolved CUPS bug for this problem. They basically isolate the problem to the way Mozilla is opening the CUPS library. They say there are two possible solutions, which don’t involve CUPS. Mozilla needs to change the way they’re dlopen() and dlclose() of CUPS or get OpenSSL to fully support threading.
The problem is that the Mozilla apps are dlopen’ing libcups, Apple Writerwhich then initializes the SSL library. They then dlclose libcups after the print dialog goes away which leaves the OpenSSL threading stuff pointing at functions that are no longer in the process address space.
One of two things needs to happen – Firefox/Thunderbird need to stop using dlopen/dlclose (or at least dlclose) for libcups, or OpenSSL and GNU TLS need to actually support threading out of the box and not depend on the application or library to provide threading support.
The nice guys at CUPS now leave us in the hands of third parties to fix the problem. Some solutions I’ve read say to downgrade CUPS to 1.4.3 which apparently doesn’t exhibit this bug, which isn’t CUPS’ introduction. I wasn’t exactly satisfied with this. If you read in to the wording you will realize that there are three solutions. I mean… dlopen() isn’t an SSL command and dlopen() doesn’t provide dependency support. Then who is loading libSSL? CUPS… So if the problem isn’t CUPS, then compiling CUPS without SSL support shouldn’t fix the problem. For you binary guys, have fun… For you non binary guys keep reading…
The configure script for CUPS allows for the use of –disable-ssl. Setting this will fix your problem. Compile then like normal. Keep in mind that this will disable SSL for the CUPS daemon. You wouldn’t be able to do secure printing over the network or provide an encrypted web front end. For most users we use CUPS to just print and by default it isn’t listening on public interfaces.
If you’re using Gentoo then the following should work fine for you…
echo “net-print/cups -ssl” >> /etc/portage/package.use
emerge -av cups
Before I start any flame wars, I am not saying that Mozilla is correct. I’m especially not saying this because I haven’t run in to any other applications with this problem. I am saying that the CUPS developers are diluting the truth about the problem and not exposing a possible solution for people having difficulties. If 1.4.4 has bug fixes, features or hardware support that is required then the user may not be able to downgrade or wait for a third party solution. Compromises are occasionally necessary and CUPS shouldn’t be run in the same manner that Apple is.
