Closed Bug 725793 Opened 9 years ago Closed 9 years ago
OOM crash in ns
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: 18.104.22.1680 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.
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsNSSCertificate::Read(nsIObjectInputStream*)] → [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsNSSCertificate::Read(nsIObjectInputStream*)] [@ mozalloc_abort(char cons…
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.
See Also: → 712914
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(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.
You need to log in before you can comment on or make changes to this bug.