725793 - OOM crash in nsNSSCertificate::Read

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Scoobidiver (away)]

It's currently #52 top crasher in 12.0a2.

It first appeared in 12.0a1/20120126. The regression range might be:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=005488525c43&tochange=402b394b6623

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 Reason	EXCEPTION_BREAKPOINT
Crash Address	0x73bc195f
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2a02, AdapterSubsysID: 02731028, AdapterDriverVersion: 8.15.10.1930
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:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char%20const*%20const%29%20|%20mozalloc_handle_oom%28unsigned%20int%29%20|%20moz_xrealloc%20|%20nsNSSCertificate%3A%3ARead%28nsIObjectInputStream*%29

Comment 1

[Ed Morley [:emorley]]

(Removed CC, since I just merged inbound, none of the changesets were mine)

Comment 2

[Scoobidiver (away)]

It's #28 top browser crasher in 12.0b1.

Comment 3

[Alex Keybl [:akeybl]]

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

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Possibilities:

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

[Sheila Mooney]

Hey Brian, anything we can do here? It's significant enough volume on beta at this point.

Comment 6

[Robert Kaiser]

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 https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char%20const%2A%20const%29%20%7C%20mozalloc_handle_oom%28unsigned%20int%29%20%7C%20moz_xmalloc%20%7C%20nsNSSCertificate%3A%3ARead%28nsIObjectInputStream%2A%29

Comment 7

[Benjamin Smedberg]

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

[Alex Keybl [:akeybl]]

(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

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

https://hg.mozilla.org/releases/mozilla-beta/rev/6323a689d6f1

Comment 10

[Alex Keybl [:akeybl]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #9)
> https://hg.mozilla.org/releases/mozilla-beta/rev/6323a689d6f1

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.