Closed Bug 657892 Opened 15 years ago Closed 3 years ago

Start-up crash [@ nsZipArchive::OpenArchive ]

Categories

(Core :: Networking: JAR, defect)

Product:
Core
Component:
Networking: JAR
Version:
2.0 Branch
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED INACTIVE
Tracking Flags:
Tracking Status
firefox47 --- affected
firefox48 --- affected

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, csectype-wildptr, sec-moderate, Whiteboard: [necko-backlog])

Crash Data

It is #76 top crasher in 4.0.1 over the last 3 days. It happens at startup. All comments are in Russian. Signature nsZipArchive::OpenArchive(nsIFile*) UUID e622be56-f4d4-4df2-a598-3d4912110517 Uptime Last Crash 2 seconds before submission Install Age 2795054 seconds (4.6 weeks) since version was first installed. Install Time 2011-04-16 20:42:14 Product Firefox Version 4.0.1 Build ID 20110413222027 Release Channel unknown Branch 2.0 OS Windows NT OS Version 5.1.2600 Service Pack 3 CPU x86 CPU Info AuthenticAMD family 16 model 5 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION_EXEC Crash Address 0x2e Frame Module Signature [Expand] Source 0 @0x2e 1 xul.dll nsZipArchive::OpenArchive modules/libjar/nsZipArchive.cpp:298 2 xul.dll SetupReader xpcom/build/Omnijar.cpp:61 3 xul.dll nsComponentManagerImpl::Init xpcom/components/nsComponentManager.cpp:399 4 xul.dll NS_InitXPCOM2_P xpcom/build/nsXPComInit.cpp:527 5 xul.dll ScopedXPCOMStartup::Initialize toolkit/xre/nsAppRunner.cpp:1186 6 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3546 7 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:128 8 firefox.exe __tmainCRTStartup obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591 9 kernel32.dll BaseProcessStart More reports at: https://crash-stats.mozilla.com/report/list?signature=nsZipArchive%3A%3AOpenArchive%28nsIFile*%29
Rather rude Russian at that. I say we don't fix this bug until they learn some manners. On a more serious note. Looks like omni.jar got corrupted somehow.
Note this also crashes in 4.0. Still only russians are affected.
Crash Signature: [@ nsZipArchive::OpenArchive(nsIFile*) ]
Stack traces are now various: Frame Module Signature [Expand] Source 0 @0xf3f2bcd0 1 xul.dll nsZipArchive::OpenArchive modules/libjar/nsZipArchive.cpp:296 2 xul.dll nsJAR::Open 3 xul.dll LoadExtensionDirectories 4 xul.dll nsXREDirProvider::LoadExtensionBundleDirectories toolkit/xre/nsXREDirProvider.cpp:557 5 xul.dll nsXREDirProvider::DoStartup toolkit/xre/nsXREDirProvider.cpp:734 6 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3417 Frame Module Signature [Expand] Source 0 @0xbb045b9 1 xul.dll nsZipArchive::OpenArchive modules/libjar/nsZipArchive.cpp:296 2 xul.dll mozilla::Omnijar::InitOne xpcom/build/Omnijar.cpp:112 3 xul.dll mozilla::Omnijar::Init xpcom/build/Omnijar.cpp:126 4 xul.dll NS_InitXPCOM2_P xpcom/build/nsXPComInit.cpp:455 5 xul.dll ScopedXPCOMStartup::Initialize toolkit/xre/nsAppRunner.cpp:1144 6 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3307 7 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:107 Frame Module Signature [Expand] Source 0 @0x5642d20 1 xul.dll nsZipArchive::OpenArchive modules/libjar/nsZipArchive.cpp:296 2 xul.dll nsJAR::Open 3 xul.dll nsZipReaderCache::GetZip modules/libjar/nsJAR.cpp:1138 4 xul.dll nsLocalFile::Clone xpcom/io/nsLocalFileWin.cpp:841 5 xul.dll nsJARChannel::CreateJarInput modules/libjar/nsJARChannel.cpp:304 6 xul.dll nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener> obj-firefox/dist/include/nsAutoPtr.h:969 7 xul.dll nsJARChannel::AsyncOpen modules/libjar/nsJARChannel.cpp:728 Frame Module Signature [Expand] Source 0 @0xf30ebcd0 1 xul.dll nsZipArchive::OpenArchive modules/libjar/nsZipArchive.cpp:296 2 xul.dll mozilla::scache::StartupCache::LoadArchive startupcache/StartupCache.cpp:225 3 xul.dll mozilla::scache::StartupCache::Init startupcache/StartupCache.cpp:201 4 xul.dll mozilla::scache::StartupCache::InitSingleton startupcache/StartupCache.cpp:111 5 xul.dll NS_InitXPCOM2_P xpcom/build/nsXPComInit.cpp:519 6 xul.dll ScopedXPCOMStartup::Initialize toolkit/xre/nsAppRunner.cpp:1144 7 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3307 8 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:107
Crash Signature: [@ nsZipArchive::OpenArchive(nsIFile*) ] → [@ nsZipArchive::OpenArchive(nsIFile*) ] [@ @0x0 | nsZipArchive::OpenArchive(nsIFile*) ]
Crash Signature: [@ nsZipArchive::OpenArchive(nsIFile*) ] [@ @0x0 | nsZipArchive::OpenArchive(nsIFile*) ] → [@ nsZipArchive::OpenArchive(nsIFile*) ] [@ @0x0 | nsZipArchive::OpenArchive(nsIFile*) ] [@ nsZipArchive::OpenArchive ] [@ @0x0 | nsZipArchive::OpenArchive ]
Whiteboard: [necko-active] → [necko-backlog]
Crash volume for signature 'nsZipArchive::OpenArchive': - nightly (version 50): 0 crash from 2016-06-06. - aurora (version 49): 0 crash from 2016-06-07. - beta (version 48): 39 crashes from 2016-06-06. - release (version 47): 37 crashes from 2016-05-31. - esr (version 45): 0 crash from 2016-04-07. Crash volume on the last weeks: Week N-1 Week N-2 Week N-3 Week N-4 Week N-5 Week N-6 Week N-7 - nightly 0 0 0 0 0 0 0 - aurora 0 0 0 0 0 0 0 - beta 8 3 3 1 8 8 1 - release 4 11 0 7 5 8 0 - esr 0 0 0 0 0 0 0 Affected platforms: Windows, Mac OS X
status-firefox47: --- → affected
status-firefox48: --- → affected
See Also: → 603070
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
QA Whiteboard: qa-not-actionable

Unassigning bugs owned by Patrick.

Assignee: mcmanus → nobody
Severity: critical → S2

clear wildptr crashes, ongoing at a low rate. spike oct 6 seems to be a single client reporting N times
removing automatic/old priority

Group: core-security
Keywords: csectype-wildptr
Priority: P3 → --
Group: core-security → network-core-security

This is not a useful bug right now. In the past 3 months, looking at only "recent" Firefox versions (110 and higher) there were a total of 42 crashes from 7 distinct individuals. 14 of those were two Fenix users, and 28 were Desktop. 3 of the desktop users crashed once each (two null derefs and a EXCEPTION_ILLEGAL_INSTRUCTION), another had 11 EXCEPTION_PRIV_INSTRUCTION crashes, and the last had 14 crashes spread over 6 weeks that were a mix of read and write violations. I don't see any that looked like UAF

All 42 were start-up crashes, not influenced by any potentially malicious web code. The bad instruction crashes should definitely be corruption (of memory, or the firefox executable). Maybe the others are memory problems, too, since only a few individuals are crashing but all Firefox users should be opening the same omni.jar files using the same start-up code.

Group: network-core-security
Status: NEW → RESOLVED
Closed: 3 years ago
Keywords: sec-high → sec-moderate
Resolution: --- → INACTIVE
Summary: Start-up crash [@ nsZipArchive::OpenArchive(nsIFile*) ] → Start-up crash [@ nsZipArchive::OpenArchive ]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.

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