1652140 - Crash in [@ mozilla::CacheAwareZipReader::GetPersistentHandle]

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

This bug is for crash report bp-779d13af-48c0-48d9-ab76-cf3f80200710.

Top 10 frames of crashing thread:

0 xul.dll mozilla::CacheAwareZipReader::GetPersistentHandle xpcom/build/Omnijar.cpp:367
1 xul.dll nsJARInputStream::InitFile modules/libjar/nsJARInputStream.cpp:70
2 xul.dll nsJAR::GetInputStreamWithSpec modules/libjar/nsJAR.cpp:283
3 xul.dll nsJARInputThunk::Init modules/libjar/nsJARChannel.cpp:107
4 xul.dll nsJARChannel::CreateJarInput modules/libjar/nsJARChannel.cpp:274
5 xul.dll nsJARChannel::Open modules/libjar/nsJARChannel.cpp:844
6 xul.dll NS_MaybeOpenChannelUsingOpen netwerk/base/nsNetUtil.cpp:2543
7 xul.dll ReadScript js/xpconnect/loader/mozJSComponentLoader.cpp:681
8 xul.dll mozJSComponentLoader::ObjectForLocation js/xpconnect/loader/mozJSComponentLoader.cpp:804
9 xul.dll mozJSComponentLoader::Import js/xpconnect/loader/mozJSComponentLoader.cpp:1275

This looks like a regression from bug 1627075.

Comment 1

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: crash regression

Comment 2

[Andrew McCreight [:mccr8]]

These have the crash reason MOZ_RELEASE_ASSERT((!elements && extentSize == 0) || (elements && extentSize != dynamic_extent))

Comment 3

[Alex Thayer [:alexical] (she/her)]

Rather strange. Trying to find where a Span<...> is anywhere around here - can't find one.

Comment 4

[Alex Thayer [:alexical] (she/her)]

Ah - think it's actually here - and it's likely getting null data with a non-zero size due to fault reading the memory mapped file here? EDIT: or due to a corrupt omnijar or whatever else. In any case we just need to be checking for null before making a span.

Comment 5

[Alex Thayer [:alexical] (she/her)]

Attachment: Bug 1652140 - Check for null data from zip before trying to cache it r?froydnj

We're crashing occasionally here due to an assertion in Span.h. We would
also likely have problems down the road if we tried to cache nullptrs in
the startup cache. I think this is all we need to handle this as gracefully
as we are able - at least, this should make it so the recent StartupCache
changes are no longer making failure any less graceful.

Comment 7

[Pascal Chevrel:pascalc]

Tracking for 80 given the crash volume (release owner CCed)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/70fe46e4a0b3
Check for null data from zip before trying to cache it r=froydnj

Comment 9

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/70fe46e4a0b3