sandboxing-related renderer crash ("Aw, snap") when loading NSS modules

[Mike Hommey]

On Sat, May 26, 2012 at 01:57:34AM -0500, Jonathan Nieder wrote:
> tags 651912 + pending
> quit
> 
> Jonathan Nieder wrote:
> > Vincent Bernat wrote:
> >> 03:19, Jonathan Nieder <jrnieder at gmail.com> disait :
> 
> >>> | SECStatus
> >>> | RNG_RNGInit(void)
> >>> | {
> >>> |     /* Allow only one call to initialize the context */
> >>> |     fprintf(stderr, "about to call rng_init()\n");	<--- reached
> >>> |     PR_CallOnce(&coRNGInit, rng_init);
> >>> |     fprintf(stderr, "not printed\n");		<--- not reached
> >
> > The underlying problem was probably fixed by [1].  Thanks to rsleevi
> > for pointing it out[2].
> 
> Looks like the /dev/urandom guess was wrong.  Based on testing, this
> is fixed by upgrading to libnspr4 2:4.9-2 (4.9-1 still reproduces the
> bug).  Most prominent change from that update:
> 
>    * debian/control, debian/libnspr4*, debian/rules,
>      mozilla/nsprpub/config/rules.mk, mozilla/nsprpub/configure.in,
>      mozilla/nsprpub/lib/ds/Makefile.in,
>      mozilla/nsprpub/lib/libc/src/Makefile.in,
>      mozilla/nsprpub/pr/src/Makefile.in: Move to unversioned library.
>      ABI compatibility is ensured upstream, and the SO version, if it needed
>      a change at any time, would be a change in the library name. There is
>      no reason to keep making compatibility more difficult with other distros
>      and upstream binary releases. While previous versions were one-way
>      compatible (binaries built against other distros or upstream nspr could
>      work on Debian), this approach works both ways.
> 
> I don't understand why this changed anything.  Mike, does this make
> any sense?  (Why would changing the soname of libnspr4 make it easier
> to resolve references from libsoftokn3.so to nspr functions?)

I... don't know :-/

Mike