Bug 1403348: Add better diagnostic crash reasons for URLPreloader failure. r?mccr8 data-r?rweiss
The crash reports for this section of code suggest that in some cases, we're
ending up with a null Omnijar archive when trying to pre-load files. Since the
pre-load file list is determined in the previous session, and the startup
cache (where the pre-load list is stored) is cleared whenever the build ID
changes, it should never be possible for the given omnijar archive to be
missing here.
These crashes also tend to appear in conjunction with crashes due to failures
in the GetSharedGlobal function, and may have a similar cause.
This change adds better diagnostic information to these crashes, and should at
least tell us which omnijar archive we're failing to get, and the archive path
that caused us to load that archive. It may not tell us much, but it may point
to data corruption, or provide some other clues.
MozReview-Commit-ID: EKq3r4eG5ii
--- a/js/xpconnect/loader/URLPreloader.cpp
+++ b/js/xpconnect/loader/URLPreloader.cpp
@@ -371,16 +371,21 @@ URLPreloader::BackgroundReadFiles()
// the actual reading and decompression can safely be done off-thread,
// as is the case for thread-retargeted jar: channels.
for (auto entry : pendingURLs) {
if (entry->mType == entry->TypeFile) {
continue;
}
RefPtr<nsZipArchive> zip = entry->Archive();
+ if (!zip) {
+ MOZ_CRASH_UNSAFE_PRINTF(
+ "Failed to get Omnijar %s archive for entry (path: \"%s\")",
+ entry->TypeString(), entry->mPath.get());
+ }
auto item = zip->GetItem(entry->mPath.get());
if (!item) {
entry->mResultCode = NS_ERROR_FILE_NOT_FOUND;
continue;
}
size_t size = item->RealSize();