startup crash in nsNSSComponent::ConfigureInternalPKCS11Token @ ld-2.16.so@0xb8a3 mainly on ArchLinux

RESOLVED FIXED in Firefox 14

Status

()

Core
Build Config
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Scoobidiver (away), Assigned: glandium)

Tracking

({crash, topcrash})

14 Branch
mozilla16
x86_64
Linux
crash, topcrash
Points:
---

Firefox Tracking Flags

(firefox13 wontfix, firefox14+ verified, firefox15+ verified, firefox-esr1014+ verified)

Details

(Whiteboard: [startupcrash], crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
It's #1 top crasher in 14.0b10 and 15.0a2 on Linux.
It first appeared on these builds on July 4 at 11H UTC.

Signature 	ld-2.16.so@0xb8a3 More Reports Search
UUID	4930288d-ab0e-4e10-af75-c73bb2120706
Date Processed	2012-07-06 15:50:13
Uptime	1
Last Crash	4.8 hours before submission
Install Age	1 seconds since version was first installed.
Install Time	2012-07-06 15:49:32
Product	Firefox
Version	15.0a2
Build ID	20120706042008
Release Channel	aurora
OS	Linux
OS Version	0.0.0 Linux 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47 CEST 2012 x86_64
Build Architecture	amd64
Build Architecture Info	family 15 model 12 stepping 0
Crash Reason	SIGSEGV
Crash Address	0x7fbb1380f1f8
Processor Notes 	WARNING: JSON file missing Add-ons
EMCheckCompatibility	False

Frame 	Module 	Signature 	Source
0 	ld-2.16.so 	ld-2.16.so@0xb8a3 	
1 	libc-2.16.so 	libc-2.16.so@0x6ca7 	
2 	libnspr4.so 	pr_LoadLibraryByPathname 	nsprpub/pr/src/linking/prlink.c:803
3 	ld-2.16.so 	ld-2.16.so@0x12a07 	
4 	ld-2.16.so 	ld-2.16.so@0xe785 	
5 	ld-2.16.so 	ld-2.16.so@0x1281f 	
6 	libnspr4.so 	PR_Unlock 	nsprpub/pr/src/pthreads/ptsynch.c:208
7 	libxul.so 	nsNSSComponent::ConfigureInternalPKCS11Token 	security/manager/ssl/src/nsNSSComponent.cpp:910
8 	libxul.so 	nsNSSComponent::InitializeNSS 	security/manager/ssl/src/nsNSSComponent.cpp:1747
9 	libxul.so 	nsNSSComponent::Init 	security/manager/ssl/src/nsNSSComponent.cpp:1984
10 	libxul.so 	nsNSSComponentConstructor 	security/manager/ssl/src/nsNSSModule.cpp:175
11 	libxul.so 	nsComponentManagerImpl::CreateInstanceByContractID 	xpcom/components/nsComponentManager.cpp:1032
12 	libxul.so 	nsComponentManagerImpl::GetServiceByContractID 	xpcom/components/nsComponentManager.cpp:1434
13 	libxul.so 	nsGetServiceByContractID::operator 	obj-firefox/xpcom/build/nsComponentManagerUtils.cpp:62
14 	libxul.so 	nsCOMPtr_base::assign_from_gs_contractid 	obj-firefox/xpcom/build/nsCOMPtr.cpp:99
15 	libxul.so 	EnsureNSSInitialized 	security/manager/ssl/src/nsNSSComponent.cpp:303
16 	libxul.so 	nsRandomGeneratorConstructor 	security/manager/ssl/src/nsNSSModule.cpp:218
17 	libxul.so 	nsComponentManagerImpl::CreateInstance 	xpcom/components/nsComponentManager.cpp:945
18 	libxul.so 	nsJSCID::CreateInstance 	js/xpconnect/src/XPCJSID.cpp:736
19 	libxul.so 	NS_InvokeByIndex_P 	xptcinvoke_x86_64_unix.cpp:163
20 	libxul.so 	XPCWrappedNative::CallMethod 	js/xpconnect/src/XPCWrappedNative.cpp:3107
21 	libxul.so 	XPC_WN_CallMethod 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1500
22 	libxul.so 	js::InvokeKernel 	js/src/jscntxtinlines.h:395
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=ld-2.16.so%400xb8a3

Comment 1

5 years ago
Also using archlinux here. Glibc 2.16 upgrade is guilty. See my - duplicate ? - bug #770819.

http://www.archlinux.org/packages/core/x86_64/glibc/ => glibc 2.16 went into core (stable repository) on 4 or 5 july.

Comment 2

5 years ago
Another crash report, using latest official aurora  build : https://crash-stats.mozilla.com/report/index/2b575399-c677-4936-bd4f-443802120709
(Assignee)

Updated

5 years ago
status-firefox-esr10: --- → affected
status-firefox13: --- → affected
Component: Security → Build Config
(Assignee)

Updated

5 years ago
Duplicate of this bug: 770819
(Assignee)

Comment 4

5 years ago
This is due to a glibc bug that breaks elfhack. :(
Assignee: nobody → mh+mozilla
(Assignee)

Comment 5

5 years ago
Created attachment 640155 [details] [diff] [review]
glibc fix

For the record, this fixes the glibc bug. I'll file a glibc bug.
(Assignee)

Updated

5 years ago
(Assignee)

Comment 6

5 years ago
Created attachment 640177 [details] [diff] [review]
Move elfhack sections before .rel{,a}.dyn to work around glibc 2.16 bug
Attachment #640177 - Flags: review?(nfroyd)
Comment on attachment 640177 [details] [diff] [review]
Move elfhack sections before .rel{,a}.dyn to work around glibc 2.16 bug

Works for me.
Attachment #640177 - Flags: review?(nfroyd) → review+
(Assignee)

Comment 8

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/61038a15b7b7
Target Milestone: --- → mozilla16
(Assignee)

Comment 9

5 years ago
Created attachment 640224 [details] [diff] [review]
Move elfhack sections before .rel{,a}.dyn to work around glibc 2.16 bug.
Attachment #640224 - Flags: review?(nfroyd)
(Assignee)

Updated

5 years ago
Attachment #640177 - Attachment is obsolete: true
Attachment #640224 - Flags: review?(nfroyd) → review+
(Assignee)

Comment 10

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/c0f7c33713b3

Updated

5 years ago
tracking-firefox14: ? → +
tracking-firefox15: ? → +
(Assignee)

Comment 11

5 years ago
Comment on attachment 640224 [details] [diff] [review]
Move elfhack sections before .rel{,a}.dyn to work around glibc 2.16 bug.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: Startup crash on Linux systems with glibc 2.16 (latest glibc release, known to be used on current arch linux).
Fix Landed on Version: Currently on m-i only.
Risk to taking this patch (and alternatives if risky): The patch doesn't intrinsically modify how elfhack works, it only moves the insertion point it uses. This had an impact when landing the first time because the check to know whether to actually elfhack or not became wrong because of the insertion point change, and this was fixed in the second landing. With the build not being red, it's pretty low risk.
String or UUID changes made by this patch: None
Attachment #640224 - Flags: approval-mozilla-esr10?
Attachment #640224 - Flags: approval-mozilla-beta?
Attachment #640224 - Flags: approval-mozilla-aurora?
Comment on attachment 640224 [details] [diff] [review]
Move elfhack sections before .rel{,a}.dyn to work around glibc 2.16 bug.

[Triage Comment]
Low risk startup topcrash fix, and we should know if the signature swaps in the beta going to build today.

Please land ASAP, we're going to build in a matter of hours. Thanks!
Attachment #640224 - Flags: approval-mozilla-esr10?
Attachment #640224 - Flags: approval-mozilla-esr10+
Attachment #640224 - Flags: approval-mozilla-beta?
Attachment #640224 - Flags: approval-mozilla-beta+
Attachment #640224 - Flags: approval-mozilla-aurora?
Attachment #640224 - Flags: approval-mozilla-aurora+

Updated

5 years ago
tracking-firefox-esr10: --- → 14+
https://hg.mozilla.org/releases/mozilla-aurora/rev/20640a6e52ae
https://hg.mozilla.org/releases/mozilla-beta/rev/a4c255b99ba1
https://hg.mozilla.org/releases/mozilla-esr10/rev/2ffb11d8b2f8
status-firefox-esr10: affected → fixed
status-firefox13: affected → wontfix
status-firefox14: affected → fixed
status-firefox15: affected → fixed
https://hg.mozilla.org/mozilla-central/rev/c0f7c33713b3
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Frederic, would you mind checking if this is fixed for you now with the latest Nightly and 10.0.6esrpre builds?
(Assignee)

Comment 16

5 years ago
Nightlies were not affected because they have --enable-profiling, and that disables elfhack. M-C debug builds were affected, but we don't have nightlies for that, so it would be best to test beta or aurora, and esr.

Comment 17

5 years ago
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #15)
> Frederic, would you mind checking if this is fixed for you now with the
> latest Nightly and 10.0.6esrpre builds?

I'm not at home right now, but I will test and report asap, at least for 10.0.6 esr pre build.

Comment 18

5 years ago
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #15)
> Frederic, would you mind checking if this is fixed for you now with the
> latest Nightly and 10.0.6esrpre builds?

Some results :

10.0.6 esr pre : revision 2ffb11d8b2f8 => OK
aurora : revision 23c1df05027f => OK
beta : revision 8b97fc666642 => OK

Hope it helps ;)
Thanks Frederic, calling this verified.
status-firefox-esr10: fixed → verified
status-firefox14: fixed → verified
status-firefox15: fixed → verified
You need to log in before you can comment on or make changes to this bug.