Mozilla crash on Print

[Joe Marcus Clarke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Don Lewis wrote:
| On 27 Nov, Joe Marcus Clarke wrote:
|
|>On Sat, 2004-11-27 at 15:47 -0800, Don Lewis wrote:
|>
|>>On 27 Nov, Joe Marcus Clarke wrote:
|>>
|>>>On Sat, 2004-11-27 at 13:40 -0800, Don Lewis wrote:
|>>
|>>>>I just got a crash with this Firefox 1.0_3,1 running on 4.10-STABLE.  I
|>>>>am using CUPS.  Here's the stack trace:
|>>>>
|>>>
|>>>I'm not sure what more I can do.  The crash ends up in CUPS, then in
|>>>OpenSSL.  I have yet to see a stack trace with those components built
|>>>with debugging symbols.  It looks like a CUPS problem to me, but I don't
|>>>use CUPS, so I don't really have any other ideas except to uninstall it.
|>>
|>>I rebuilt the libraries with debugging symbols, but at the moment, I
|>>can't reproduce the crash.  Pointing gdb at the old core file, I get:
|>
|>I'm thinking either the stack is corrupt, or you have a different
|>version of CUPS.  I'm looking at the source for 1.2.22, and this trace
|>doesn't fit.
|
|
| New core dump.  The trigger appears to be printing secure web pages
| (https urls).
|

Good news and bad news.  The good news is, thanks to this report, I have
found the problem.  The bad news is, I don't see an ideal fix.

The problem is, once the SSL subsystem has been initialized in
Firefox/Thunderbird, the NSS libraries are dynamically loaded into the
running image.  Later, when one chooses to print, libcups is also
loaded.  Libcups brings with it OpenSSL.  Both OpenSSL and NSS share a
SHA1_Update() symbol.  These symbols conflict in the running image of
Firefox/Thunderbird.  What ends up happening is that the SHA1_Update
from NSS gets called by CUPS instead of the SHA1_Update from OpenSSL.
Thus, when SHA1_Final gets called from OpenSSL, bad things happen.

As I understand it, the rtld will look for symbols in the following
order in the following places:

* Search the referencing object itself if linked with -Bsymbolic
* Search all libraries loaded at program startup
* Search all DAGs whose roots are RTLD_GLOBAL objects
* Search all dlopen'd DAGs that contain the referenced object
* Search the linker itself

Since NSS is linked symbolically, it won't conflict with OpenSSL, but
OpenSSL, dynamically loaded, will conflict with NSS.  As we can see,
that sucks.  So, here are my proposed solutions:

* Use GnuTLS instead of OpenSSL with CUPS (tested: This works
flawlessly, but adds a new dependency for CUPS, and this may not be
desired).  I've copied the CUPS maintainer to get his take.

* Link Firefox/Thunderbird (and soon Mozilla) against libcups.  While
this should work given the load order above, I have not tested this, and
this would involve adding a LIB_DEPENDS on cups-base.

* Remove CUPS support from all affected ports.  This will definitely
work, but CUPS users will lose functionality.

I'm open to any other suggestions, too.  Linux doesn't seem to have this
problem since most likely, they build CUPS with GnuTLS, and I don't
think their linker has this same problem.

Joe

- --
PGP Key : http://www.marcuscom.com/pgp.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBtducb2iPiv4Uz4cRAoM5AKCDEYzTrvnrc+ruSJFXkDpujkYDDwCfdFU0
585IDWfnc9Sc0KmSmJjY1wI=
=gA+Y
-----END PGP SIGNATURE-----