Comment 65 for bug 226470

Erik, I've been wrestling with trying to get a 3.0 version compiled (not yet but getting there). But briefly on your gdb attachment.

Netscape has two "portable" system library sets, the portable runtime "nspr" [1], and the security "nss" [2]. Presumably so one can share them between Mozilla, Firefox, Seamonkey, Thunderbird, etc. These are usually in subdirectories under /usr/lib, etc.

While, the binary I released has the "nspr" functions, compiled with debugging, loaded into the binary, the "nss" functions are *much* more problematic. Some of them may be compiled into the binary (I'd have to check), but it may try to access others at runtime (from your system libraries). If so then there could quite possibly be problems intermixing the nss libraries. There is also interaction between the nss libraries and the SSL libraries on your system (probably). So there is ample opportunity for difficulties.

Do you run into the problem if you completely avoid https: pages (or anything likely to request a password)?

One possibility - try renaming your nss libraries, e.g. mv /usr/lib/nss /usr/lib/NSS and see if it runs [I've never tried this]. You might be able to run fine and then only get a runtime error at those times that it tried to use encryption. (Or it might fault in a clearer location saying that the NSS libraries are unavailable -- in which case we have another "bug" that the Mozilla code doesn't cleanly handle missing security libraries). [There are lots of examples of this -- you ought to try starting it without the various subdirectories containing the icons, "pseudo-code", etc. under MOZILLA_FIVE_HOME (MOZILLA_LIBDIR) sometime... :-(]

1. http://en.wikipedia.org/wiki/Netscape_Portable_Runtime
2. http://developer.mozilla.org/en/docs/NSS_FAQ