New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: WontFix
Last visit > 30 days ago
Closed: Feb 2010
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

[gentoo] Startup crash in NSS_InitReadWrite

Reported by, Jan 12 2010

Issue description

Chrome Version       : chromium-bin- and earlier

What steps will reproduce the problem?
1. Just start chromium or chromium-bin
2. Wait for about 5 seconds

What is the expected result?
Should just keep running

What happens instead?
The application runs for about 5 seconds and then gets killed by SIGABRT

Please provide any additional information below. Attach a screenshot if
Gentoo (updated regularyly)
Vanilla (and several earlier versions)
nVidia Corporation G72 [GeForce 7500 LE] (rev a1)
nvidia-drivers-190.53-r1 (and a couple of earlier versions)
Dualhead with Xinerama
xorg-server-1.6.5-r1 (was the same on 1.5)
strace output attached

479 KB View Download
Labels: FeedbackRequested OS-Linux
Are you able to obtain a gdb backtrace (you'd need to make sure you have symbols for 
chromium, see

Also, could you post your emerge --info?
emerge --info output attached

I'll recompile chromium with symbols unstripped und upload the gdb backtrace later
4.6 KB View Download
well, I didn't manage to unset symbol stripping
FEATURES="nostip" didn't work for some reason
neither on the command line nor set in make.conf
so the backtrace output looks a bit unfriendly

here's the gdb backtrace output:
Reading symbols from /usr/lib/chromium-browser/chrome...done.
(gdb) run
Starting program: /usr/lib/chromium-browser/chrome 
[Thread debugging using libthread_db enabled]
Xlib:  extension "RANDR" missing on display ":0.0".
[New Thread 0xb62c5b70 (LWP 24608)]
[New Thread 0xb5ac4b70 (LWP 24609)]
[New Thread 0xb52c3b70 (LWP 24610)]
[New Thread 0xb4ac2b70 (LWP 24611)]
[New Thread 0xb42c1b70 (LWP 24612)]
[New Thread 0xb3ac0b70 (LWP 24613)]
[New Thread 0xb32bfb70 (LWP 24614)]
[New Thread 0xb2abeb70 (LWP 24615)]
[New Thread 0xb2785b70 (LWP 24616)]
[New Thread 0xb1f84b70 (LWP 24617)]
[Thread 0xb1f84b70 (LWP 24617) exited]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb42c1b70 (LWP 24612)]
0xffffe424 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb6f416e0 in raise () from /lib/
#2  0xb6f42f15 in abort () from /lib/
#3  0xb1115867 in ?? () from /usr/lib/nss/
#4  0x09f7e460 in ?? ()
#5  0xb11ff4e4 in ?? () from /usr/lib/nss/
#6  0xb42be868 in ?? ()
#7  0xb74e71ec in PR_Unlock () from /usr/lib/nspr/
#8  0xb1115839 in ?? () from /usr/lib/nss/
#9  0xb1125ff4 in ?? () from /usr/lib/nss/
#10 0xb42be848 in ?? ()
#11 0xb10ebb8b in ?? () from /usr/lib/nss/
#12 0xb11283a8 in ?? () from /usr/lib/nss/
#13 0xb10ec510 in ?? () from /usr/lib/nss/
#14 0x00000201 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I've recompiled nss, nspr and zlib
no changes

Labels: -Area-Undefined -FeedbackRequested Area-Internals Internals-Network
Wan-Teh, could you take a look at this NSPR/NSS related issue? At this moment we 
don't have a good backtrace, but there's some strace data at the top.

fbinski, are you sure you followed the guide carefully? Here are the critical steps:
1. Set CFLAGS="-O1 -pipe -ggdb" in /etc/make.conf
2. enable USE flag "debug"
3. emerge the package with FEATURES="nostrip" (alternatively, splitdebug)

You can later revert these changes. You have to re-emerge www-client/chromium, 
nspr and nss with these settings.
step 1. - yes
step 2. - yes, but the package doesn't seem to know this flag: 
# emerge -av chromium
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R   ] www-client/chromium-  USE="ffmpeg" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB

step 3. yes, but "nostrip" just didn't work, as described in my previous post
I'll try FEATURES="splitdebug" instead and post the results
here we go
backtrace attached
5.4 KB View Download

Comment 7 by, Jan 27 2010

Status: Assigned
Summary: [gentoo] Startup crash in NSS_InitReadWrite

Comment 8 by, Jan 27 2010

fbinski: thanks for the backtrace in comment 6.

Pawel: this is a NSS Gentoo porting bug.  You need to
debug why the FREEBL_InitStubs function in
mozilla/security/nss/lib/freebl/stubs.c doesn't work
successfully on Gentoo.  FREEBL_InitStubs should look
up several NSPR function symbols, including PR_CallOnce,

Comment 9 by Deleted ...@, Feb 5 2010


please do not blame a bug on the distro, unless more then one user can confirm the
problem in gentoo, I would declare this a pebkac. It is most likely the user upgraded
nss and did not issue 'revdep-rebuild --library" to ensure all linking
was consistent on his machine.
dont't blame the user
he does his revdep-rebuild regularily

# revdep-rebuild --library
 * Configuring search environment for revdep-rebuild

 * Checking reverse dependencies
 * Packages containing binaries and libraries using
 * will be emerged.

 * Collecting system binaries and libraries
 * Generated new 1_files.rr
 * Checking dynamic linking
[ 100% ]

 * There are no dynamic links to All done.
Status: WontFix
This is now tracked in, and seem to 
not be chromium-specific.
sorry, it is chromium-specific now

the similar firefox problem was solved with the update to 3.6

Comment 13 by, Feb 6 2010

fbinski: as I described in comment 8, please use gdb to
debug this.  Set a breakpoint in FREEBL_InitStubs and find
out why it fails:
Jory A. Pratt from has suggested to set LD_LIBRARY_PATH properly

it solves the problem

which peace of software is responsible for this variable not been set correctly?

Comment 15 by Deleted ...@, Feb 7 2010

This is gonna fall back to me on gentoo, we will need to debug why your system is not
setting up a proper search path.
my problem is solved:

thanks for the cooperation

Comment 17 by, Feb 8 2010

fbinski: I still think something isn't quite right, because the stack
trace in comment 3 showed that /usr/lib/nspr/ could be

Also the NSPR and NSS .so's should be installed under /usr/lib.

In any case, you may not be motivated to get to the bottom of this
now that this problem is solved.  I'll contact Jory A. Pratt because
I found some issues in the way Gentoo builds and installs NSPR and
NSS while investigating this bug.
#ls /usr/lib/nspr/

may be the path is hardcoded somewhere or it's taken from some other variable
pointing to /usr/lib, it is really a sign, that something is wrong somewhere

I'm not a developer, just an advanced user. I can code a bit javascript, but I can't
tell c from c++, nor do I understand the miracle of gentoo portage deep enough

I can't reproduce the problem anymore cause it's solved for me, but if recompiling
some packages and running the results in gdb can help you, I could do it for you

talk to Jory A. Pratt, he seems to have the gentoo knowledge and the right instinct

Project Member

Comment 19 by, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 20 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network

Sign in to add a comment