Closed
Bug 564898
Opened 14 years ago
Closed 14 years ago
crash [@ nsMsgAccountManager::RemoveFolderFromSmartFolder(nsIMsgFolder*, unsigned int)] [Mac]
Categories
(MailNews Core :: Backend, defect)
Tracking
(blocking-thunderbird3.1 rc1+, thunderbird3.1 rc1-fixed)
RESOLVED
FIXED
People
(Reporter: wsmwk, Assigned: Bienvenu)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file, 2 obsolete files)
11.79 KB,
patch
|
standard8
:
review+
standard8
:
superreview+
|
Details | Diff | Splinter Review |
crash [@ nsMsgAccountManager::RemoveFolderFromSmartFolder(nsIMsgFolder*, unsigned int)] [Mac]only #9 crash for 3.1b2. Doesn't happen in 3.0 branch. Earliest crash found is 20100419062134 3.2a1pre most appear to be startup crashes. one of the few not, that has almost no extensions is bp-883f292f-7b9a-477c-b47f-b96c42100506 bp-ad3f3c1a-ddca-4c21-9c31-e75fc2100505 I had started Lanikai and it asked to be updated to Beta 2. I allowed it. It updated successfully and I just saw the UI for Lanikai appear on screen then >BAM< it crashed. bp-c2f6bc98-ad9b-47af-b275-f406d2100419 (clint) trying to start up 0 thunderbird-bin nsMsgAccountManager::RemoveFolderFromSmartFolder mailnews/base/src/nsMsgAccountManager.cpp:3618 1 thunderbird-bin nsMsgAccountManager::OnItemIntPropertyChanged mailnews/base/src/nsMsgAccountManager.cpp:3574 2 thunderbird-bin nsMsgMailSession::OnItemIntPropertyChanged mailnews/base/src/nsMsgMailSession.cpp:164 3 thunderbird-bin nsMsgDBFolder::NotifyIntPropertyChanged mailnews/base/util/nsMsgDBFolder.cpp:4817 4 thunderbird-bin nsMsgDBFolder::OnFlagChange mailnews/base/util/nsMsgDBFolder.cpp:4189 5 thunderbird-bin nsMsgDBFolder::ClearFlag mailnews/base/util/nsMsgDBFolder.cpp:4149 6 thunderbird-bin nsImapIncomingServer::DiscoveryDone mailnews/imap/src/nsImapIncomingServer.cpp:1530 7 libxpcom_core.dylib NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 8 libxpcom_core.dylib nsProxyObjectCallInfo::Run xpcom/proxy/src/nsProxyEvent.cpp:181 9 libxpcom_core.dylib nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:527 10 libxpcom_core.dylib NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 11 thunderbird-bin XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2722 12 thunderbird-bin XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1740 13 libmozjs.dylib js_Invoke js/src/jsinterp.cpp:1360 14 libmozjs.dylib js_Interpret js/src/jsops.cpp:2240 15 libmozjs.dylib js_Invoke js/src/jsinterp.cpp:1368 16 thunderbird-bin nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1696 17 thunderbird-bin nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:570 18 libxpcom_core.dylib PrepareAndDispatch xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93 19 libxpcom_core.dylib nsXPTCStubBase::Stub3 20 thunderbird-bin nsStreamLoader::OnStopRequest netwerk/base/src/nsStreamLoader.cpp:125
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → bienvenu
blocking-thunderbird3.1: --- → rc1+
Assignee | ||
Comment 1•14 years ago
|
||
add null check. Not sure why one of these is null, but we shouldn't crash...
Attachment #444485 -
Flags: superreview?(bugzilla)
Attachment #444485 -
Flags: review?(bugzilla)
Reporter | ||
Comment 2•14 years ago
|
||
likely to also kill #19 crash bp-bb63dea6-0384-4346-bba3-dcb9d2100508 ? also mac-only and same stack except frame 0 0 @0x89078b0c 1 thunderbird-bin nsMsgAccountManager::OnItemIntPropertyChanged mailnews/base/src/nsMsgAccountManager.cpp:3574 2 thunderbird-bin nsMsgMailSession::OnItemIntPropertyChanged mailnews/base/src/nsMsgMailSession.cpp:164 3 thunderbird-bin nsMsgDBFolder::NotifyIntPropertyChanged mailnews/base/util/nsMsgDBFolder.cpp:4817 4 thunderbird-bin nsMsgDBFolder::OnFlagChange mailnews/base/util/nsMsgDBFolder.cpp:4189 5 thunderbird-bin nsMsgDBFolder::ClearFlag mailnews/base/util/nsMsgDBFolder.cpp:4149 6 thunderbird-bin nsImapIncomingServer::DiscoveryDone mailnews/imap/src/nsImapIncomingServer.cpp:1530
Assignee | ||
Comment 3•14 years ago
|
||
d'oh, looks like I need to fix this in two places...
Assignee | ||
Comment 4•14 years ago
|
||
I've looked through the code and I can't figure out how we're getting this crash, and I'm not convinced it's a null crash, but I'm not sure what else to try. If this fixes it, we might be able to tell from crash-stats.
Attachment #444485 -
Attachment is obsolete: true
Attachment #444510 -
Flags: superreview?(bugzilla)
Attachment #444510 -
Flags: review?(bugzilla)
Attachment #444485 -
Flags: superreview?(bugzilla)
Attachment #444485 -
Flags: review?(bugzilla)
UUID c2f6bc98-ad9b-47af-b275-f406d2100419 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x7bc202b7 These aren't null crashes.
Assignee | ||
Comment 6•14 years ago
|
||
some are much closer to null than that one. But you're right that this is unlikely to be a null issue.
Assignee | ||
Comment 7•14 years ago
|
||
Clint, I don't suppose you can reproduce this issue?
Assignee | ||
Comment 8•14 years ago
|
||
from the stack trace, we're hitting the code that removes the trash flag from imap folders that should no longer be marked as trash, either because a different folder is marked as the trash, or the gmail server has told us about a different trash folder.
Assignee | ||
Comment 9•14 years ago
|
||
I'm reasonably sure the issue is that we're altering the listener array while iterating over it. So we need a safe way of doing that, like nsTObserverArray's iterator.
Whiteboard: [working on a patch]
Assignee | ||
Comment 10•14 years ago
|
||
I think this will fix it. I switched over everything to use nsTObserverArray and its safe iterators. We have a mozmill test that exercises this code (folder-tree-modes/test-smart-folders.js) but it wasn't crashing before so I need to concoct a test that fails with the old code.
Attachment #444510 -
Attachment is obsolete: true
Attachment #444795 -
Flags: superreview?(bugzilla)
Attachment #444795 -
Flags: review?(bugzilla)
Attachment #444510 -
Flags: superreview?(bugzilla)
Attachment #444510 -
Flags: review?(bugzilla)
Comment 11•14 years ago
|
||
Comment on attachment 444795 [details] [diff] [review] proposed fix Yeah, I think this is the right thing to try here.
Attachment #444795 -
Flags: superreview?(bugzilla)
Attachment #444795 -
Flags: superreview+
Attachment #444795 -
Flags: review?(bugzilla)
Attachment #444795 -
Flags: review+
Assignee | ||
Comment 12•14 years ago
|
||
I've landed this on the trunk - I'll land on the branch if all looks well.
Whiteboard: [working on a patch] → [pushed to trunk, needs branch landing]
Assignee | ||
Comment 13•14 years ago
|
||
fixed on trunk and 1.9.2 branch for 3.1
Status: NEW → RESOLVED
Closed: 14 years ago
status-thunderbird3.1:
--- → rc1-fixed
Resolution: --- → FIXED
Whiteboard: [pushed to trunk, needs branch landing]
Comment 14•14 years ago
|
||
(In reply to comment #7) > Clint, I don't suppose you can reproduce this issue? I think this was one where it was crashing on startup right after an update. Update had applied, and then it failed to come up. Because my computer never really shuts down Lanikai I was a couple of days off (I habitually put off updating) of the current nightly so I leapfrogged up to the current nightly at that time and it worked. So, if you try starting Lanikai nightlies from a couple of days (2-3) prior to my crash you might hit the startup issue again. But, it looks like you fixed it, so all's well.
Updated•13 years ago
|
Crash Signature: [@ nsMsgAccountManager::RemoveFolderFromSmartFolder(nsIMsgFolder*, unsigned int)]
You need to log in
before you can comment on or make changes to this bug.
Description
•