Date: Tue, 07 Dec 2004 11:34:36 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Don Lewis <truckman@FreeBSD.org> Cc: shinjii@virusinfo.rdksupportinc.com Subject: Re: Mozilla crash on Print Message-ID: <41B5DB9C.9060902@marcuscom.com> In-Reply-To: <200411290122.iAT1MYUR008915@gw.catspoiler.org> References: <200411290122.iAT1MYUR008915@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41B5DB9C.9060902>