1606102 - Intermittent assertion failure on debug build: MOZ_ASSERT(!lookup(aLookup).found());

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Emilio Cobos Álvarez (:emilio)]

I've seen this multiple times on clean local debug builds, generally when the previous session was killed by Ctrl+C, but not sure 100% that's needed to reproduce or not.

#0  mozilla::detail::HashTable<mozilla::HashMapEntry<nsTString<char>, mozilla::scache::StartupCacheEntry>, mozilla::HashMap<nsTString<char>, mozilla::scache::StartupCacheEntry, mozilla::scache::nsCStringHasher, mozilla::MallocAllocPolicy>::MapHashPolicy, mozilla::MallocAllocPolicy>::putNewInfallible<nsTString<char>&, mozilla::scache::StartupCacheEntry>(nsTString<char> const&, nsTString<char>&, mozilla::scache::StartupCacheEntry&&)
    (this=0x7f3f69f6da88, aLookup=..., aArgs=..., aArgs=...) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/HashTable.h:2147
#1  0x00007f3f6462a9cd in mozilla::detail::HashTable<mozilla::HashMapEntry<nsTString<char>, mozilla::scache::StartupCacheEntry>, mozilla::HashMap<nsTString<char>, mozilla::scache::StartupCacheEntry, mozilla::scache::nsCStringHasher, mozilla::MallocAllocPolicy>::MapHashPolicy, mozilla::MallocAllocPolicy>::putNew<nsTString<char>&, mozilla::scache::StartupCacheEntry>(nsTString<char> const&, nsTString<char>&, mozilla::scache::StartupCacheEntry&&)
    (this=0x7f3f69f6da88, aLookup=..., aArgs=..., aArgs=...) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/HashTable.h:2165
#2  0x00007f3f646264a1 in mozilla::HashMap<nsTString<char>, mozilla::scache::StartupCacheEntry, mozilla::scache::nsCStringHasher, mozilla::MallocAllocPolicy>::putNew<nsTString<char>&, mozilla::scache::StartupCacheEntry>(nsTString<char>&, mozilla::scache::StartupCacheEntry&&) (this=<optimized out>, aKey=..., aValue=...) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/HashTable.h:267
#3  mozilla::scache::StartupCache::LoadArchive() (this=<optimized out>) at /home/emilio/src/moz/gecko/startupcache/StartupCache.cpp:322
#4  0x00007f3f64624d8f in mozilla::scache::StartupCache::Init() (this=0x7f3f69f6da70) at /home/emilio/src/moz/gecko/startupcache/StartupCache.cpp:226
#5  0x00007f3f64624a36 in mozilla::scache::StartupCache::InitSingleton() () at /home/emilio/src/moz/gecko/startupcache/StartupCache.cpp:126
#6  0x00007f3f646249d2 in mozilla::scache::StartupCache::GetSingleton() () at /home/emilio/src/moz/gecko/startupcache/StartupCache.cpp:113
#7  0x00007f3f6034f467 in NS_InitXPCOM(nsIServiceManager**, nsIFile*, nsIDirectoryServiceProvider*, bool) (aResult=<optimized out>, aBinDirectory=0x7f3f69f63a00, aAppFileLocationProvider=<optimized out>, aInitJSContext=false)
    at /home/emilio/src/moz/gecko/xpcom/build/XPCOMInit.cpp:464
#8  0x00007f3f645d7bcd in ScopedXPCOMStartup::Initialize(bool) (this=0x7f3f69f1ce20, aInitJSContext=false) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:1259
#9  0x00007f3f645e0fbc in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=<optimized out>, argc=<optimized out>, argv=<optimized out>, aConfig=...) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:4733
#10 0x00007f3f645e16d1 in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=0, argv=0x1, aConfig=...) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:4818
#11 0x00005627fa8ba390 in do_main(int, char**, char**) (argc=0, argv=0x7ffe302ad708, envp=<optimized out>) at /home/emilio/src/moz/gecko/browser/app/nsBrowserApp.cpp:217
#12 main(int, char**, char**) (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /home/emilio/src/moz/gecko/browser/app/nsBrowserApp.cpp:339

Comment 1

[Emilio Cobos Álvarez (:emilio)]

key is the empty string.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: startupCache.8.little

This is the file (mFile) that was opened at the time of the crash, I hope it didn't change since then.

Comment 3

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

Hmm, yeah, the file you linked looks like we just didn't make it all the way through writing the startupcache file, so essentially it's just corrupt, and this is a common way that corruption manifests.

Given the possibility of a corrupt startupcache file, we shouldn't be calling putNew. If we are not in a debug build, this means we will end up with multiple entries in the hashtable with the same key (in our case, the empty string). I can't see any deeply troubling consequences from that state, so I don't think it's a cause for alarm, but it's obviously a bug and should be fixed.

Comment 4

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

Attachment: Bug 1606102 - Don't use putNew in StartupCache::LoadArchive r?froydnj

We can't guarantee uniqueness of the keys here because the file might
be corrupt. So we should check if the key exists and if it does, bail
out.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ea5efd3adfb3
Don't use putNew in StartupCache::LoadArchive r=froydnj

Comment 6

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/ea5efd3adfb3