Startup Crash in [@ nsMsgFolderCache::GetCacheElement] with uninitialised nsMsgFolderCache
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
People
(Reporter: wsmwk, Unassigned)
Details
(Keywords: crash, Whiteboard: [rare])
Crash Data
Vast majority of crashes are in the range 1-6 seconds of uptime.
Version 68 and 78.
Crash report: https://crash-stats.mozilla.org/report/index/b3d85a04-a813-42c6-ac52-73f3d0200823
Top 10 frames of crashing thread:
0 xul.dll nsMsgFolderCache::GetCacheElement comm/mailnews/base/src/nsMsgFolderCache.cpp:239
1 xul.dll nsMsgDBFolder::WriteToFolderCache comm/mailnews/base/util/nsMsgDBFolder.cpp:1290
2 xul.dll nsMsgDBFolder::FlushToFolderCache comm/mailnews/base/util/nsMsgDBFolder.cpp:1268
3 xul.dll nsMsgDBFolder::UpdateSummaryTotals comm/mailnews/base/util/nsMsgDBFolder.cpp:3818
4 xul.dll nsMsgLocalMailFolder::GetSubFolders comm/mailnews/local/src/nsLocalMailFolder.cpp:219
5 xul.dll NS_InvokeByIndex
6 xul.dll static XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1140
7 xul.dll XPC_WN_GetterSetter js/xpconnect/src/XPCWrappedNativeJSOps.cpp:986
8 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:585
9 xul.dll js::Call js/src/vm/Interpreter.cpp:665
Comment 1•4 years ago
|
||
GetStore() returns null I suppose, getting cleaned out from underneath? Maybe it (https://searchfox.org/comm-central/rev/68e09f5b6f83daeee9db9955de2d3334fe45d19a/mailnews/base/src/nsMsgFolderCache.h#40) should use a smart pointer and for this call a local reference should be kept?
Comment 3•4 years ago
|
||
There are a couple of different crashes here, but I think both are due to being called on an uninitialised nsMsgFolderCache
.
In the GetStore()
one above, it looks like m_mdbStore
is null, which implies nsMsgFolderCache::Init()
hasn't been called (which calls the internal OpenMDB(), which sets m_mdbStore
).
In the other crash signature I saw, it looks like m_mdbAllFoldersTable
is null:
This implies neither of the internal InitNewDB()
or InitExistingDB()
functions have been called. These are called from OpenMDB(). This might mean that nsMsgFolderCache::Init()
wasn't called, or that OpenMDB() didn't complete...
So, I think something somewhere is calling methods on an uninitialised cache...
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 4•3 years ago
|
||
(In reply to Ben Campbell from comment #3)
There are a couple of different crashes here, but I think both are due to being called on an uninitialised
nsMsgFolderCache
.In the
GetStore()
one above, it looks likem_mdbStore
is null, which impliesnsMsgFolderCache::Init()
hasn't been called (which calls the internal OpenMDB(), which setsm_mdbStore
).In the other crash signature I saw, it looks like
m_mdbAllFoldersTable
is null:This implies neither of the internal
InitNewDB()
orInitExistingDB()
functions have been called. These are called from OpenMDB(). This might mean thatnsMsgFolderCache::Init()
wasn't called, or that OpenMDB() didn't complete...So, I think something somewhere is calling methods on an uninitialised cache...
Does this match to a nasty bug you are currently working on? (Or I wonder, one of Magnus' coverity patches)
bp-7092c249-83ab-4d9a-9e4f-6a6130211028 is a recent crash (not mine)
Reporter | ||
Comment 5•3 years ago
|
||
Magnus, does this intersect with any of the many coverity issues you've touched?
Comment 6•3 years ago
|
||
Probably not. It looks like m_mdbAllFoldersTable doesn't exist anymore after bug 418551.
This crash is rare, and it's unlikely we'll find a solution for it especially now that things changed a lot on trunk. So probably best to just close.
Reporter | ||
Comment 7•3 years ago
|
||
Thanks for the info
Description
•