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: 22.214.171.1240 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
(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.
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.
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 > apparently. 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) > 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.