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
Date Processed 2012-02-09 19:33:15
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
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
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2a02, AdapterSubsysID: 02731028, AdapterDriverVersion: 188.8.131.520
D3D10 Layers? D3D10 Layers-
D3D9 Layers? D3D9 Layers+
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:
(Removed CC, since I just merged inbound, none of the changesets were mine)
It's #28 top browser crasher in 12.0b1.
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.
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.
Hey Brian, anything we can do here? It's significant enough volume on beta at this point.
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
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.
(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
Let's move forward with backing bug 680556 from Beta again. This will finally be fixed in FF13 when bug 716594 lands.
(In reply to Kyle Huey [:khuey] (email@example.com) 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.