Last Comment Bug 725793 - OOM crash in nsNSSCertificate::Read
: OOM crash in nsNSSCertificate::Read
: crash, regression, topcrash
Product: Core
Classification: Components
Component: Security (show other bugs)
: 12 Branch
: x86 Windows 7
-- critical (vote)
: ---
Assigned To: Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
: David Keeler [:keeler] (use needinfo?)
Depends on:
  Show dependency treegraph
Reported: 2012-02-09 13:21 PST by Scoobidiver (away)
Modified: 2012-04-09 10:10 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Scoobidiver (away) 2012-02-09 13:21:23 PST
It's currently #52 top crasher in 12.0a2.

It first appeared in 12.0a1/20120126. The regression range might be:

Signature 	mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsNSSCertificate::Read(nsIObjectInputStream*) More Reports Search
UUID	8a0948ca-73b3-4613-b20f-adab52120209
Date Processed	2012-02-09 19:33:15
Uptime	18
Last Crash	46.5 minutes before submission
Install Age	46.8 minutes since version was first installed.
Install Time	2012-02-09 18:43:42
Product	Firefox
Version	12.0a2
Build ID	20120208042017
Release Channel	aurora
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 15 stepping 13
Crash Address	0x73bc195f
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2a02, AdapterSubsysID: 02731028, AdapterDriverVersion:
D3D10 Layers? D3D10 Layers-
D3D9 Layers? D3D9 Layers+
EMCheckCompatibility	True

Frame 	Module 	Signature [Expand] 	Source
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:79
1 	mozalloc.dll 	mozalloc_handle_oom 	memory/mozalloc/mozalloc_oom.cpp:60
2 	mozalloc.dll 	moz_xrealloc 	
3 	xul.dll 	nsNSSCertificate::Read 	security/manager/ssl/src/nsNSSCertificate.cpp:1812
4 	xul.dll 	nsNSSSocketInfo::Read 	security/manager/ssl/src/nsNSSIOLayer.cpp:772
5 	xul.dll 	nsBinaryInputStream::ReadObject 	xpcom/io/nsBinaryStream.cpp:795
6 	xul.dll 	NS_DeserializeObject 	netwerk/base/src/nsSerializationHelper.cpp:106
7 	xul.dll 	nsDiskCacheEntry::CreateCacheEntry 	
8 	xul.dll 	nsDiskCacheDevice::FindEntry 	netwerk/cache/nsDiskCacheDevice.cpp:551
9 	xul.dll 	nsCacheService::SearchCacheDevices 	netwerk/cache/nsCacheService.cpp:1912
10 	xul.dll 	nsCacheService::ActivateEntry 	netwerk/cache/nsCacheService.cpp:1813
11 	xul.dll 	nsCacheService::ProcessRequest 	netwerk/cache/nsCacheService.cpp:1658
12 	xul.dll 	nsProcessRequestEvent::Run 	netwerk/cache/nsCacheService.cpp:1021
13 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:657
14 	xul.dll 	nsThreadStartupEvent::Run 	xpcom/threads/nsThread.cpp:218
15 	nspr4.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:426
16 	nspr4.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:122
17 	msvcr80.dll 	_endthreadex 	
18 	msvcr80.dll 	_endthreadex 	
19 	kernel32.dll 	BaseThreadInitThunk 	
20 	ntdll.dll 	__RtlUserThreadStart 	
21 	ntdll.dll 	_RtlUserThreadStart 

More reports at:*%20const%29%20|%20mozalloc_handle_oom%28unsigned%20int%29%20|%20moz_xrealloc%20|%20nsNSSCertificate%3A%3ARead%28nsIObjectInputStream*%29
Comment 1 User image Ed Morley [:emorley] 2012-02-09 14:15:22 PST
(Removed CC, since I just merged inbound, none of the changesets were mine)
Comment 2 User image Scoobidiver (away) 2012-03-23 07:58:51 PDT
It's #28 top browser crasher in 12.0b1.
Comment 3 User image Alex Keybl [:akeybl] 2012-03-26 14:57:28 PDT
Assigning to Brian to start since there's nothing in the pushlog that jumps out at me.

Brian - please let us know if there's any information the crash-kill team can pull for you or anything QA can help test.
Comment 4 User image Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-03-28 14:30:42 PDT

1. Maybe the entry is corrupted on disk and we read an invalid "len" which is very large; then we try to allocate a very large amount of memory and crash. This shouldn't cause a top-crasher though!

2. Maybe there is an uninitialized memory read

3. Maybe there is a race condition where another thread is corrupting the memory.
Comment 5 User image Sheila Mooney 2012-03-30 10:05:26 PDT
Hey Brian, anything we can do here? It's significant enough volume on beta at this point.
Comment 6 User image Robert Kaiser 2012-04-04 05:16:58 PDT
Apparently there's some problem with Socorro and URLs that contain * characters that are not escaped (which they actually should be): The working URL for the reports is
Comment 7 User image Benjamin Smedberg [:bsmedberg] 2012-04-04 05:53:10 PDT
The reports I checked all said: OOMAllocationSize=4294901763

Which is 0xFFFF0003. So we're definitely getting garbage from somewhere.

This appears to be a straight dup of bug 716594 which was fixed in 13, and the infallible NS_Alloc was backed out of 11, but nothing was done with FF12 apparently.
Comment 8 User image Alex Keybl [:akeybl] 2012-04-04 15:40:22 PDT
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #7)
> This appears to be a straight dup of bug 716594 which was fixed in 13, and
> the infallible NS_Alloc was backed out of 11, but nothing was done with FF12
> apparently.

Let's move forward with  backing bug 680556 from Beta again. This will finally be fixed in FF13 when bug 716594 lands.
Comment 9 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-04-05 11:21:17 PDT
Comment 10 User image Alex Keybl [:akeybl] 2012-04-09 10:10:35 PDT
(In reply to Kyle Huey [:khuey] ( from comment #9)

Thanks Kyle. This'll land in Beta 5 - we'll make sure to check to make sure that the crash #s drop off as part of crash-kill.

Note You need to log in before you can comment on or make changes to this bug.