Closed Bug 915107 Opened 11 years ago Closed 8 years ago

crash in nsMsgSearchSession::~nsMsgSearchSession() via nsMsgFilterAfterTheFact::~nsMsgFilterAfterTheFact

Categories

(MailNews Core :: Search, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: crash)

Crash Data

all stacks I examined contain nsMsgFilterAfterTheFact::~nsMsgFilterAfterTheFact This bug was filed from the Socorro interface and is report bp-9a7ff160-d630-4ef4-8ce1-11d702130624. ============================================================= 0 xul.dll nsMsgSearchSession::~nsMsgSearchSession() mailnews/base/search/src/nsMsgSearchSession.cpp 1 xul.dll nsMsgSearchSession::`scalar deleting destructor'(unsigned int) 2 xul.dll nsMsgSearchSession::Release() mailnews/base/search/src/nsMsgSearchSession.cpp 3 xul.dll nsMsgFilterAfterTheFact::~nsMsgFilterAfterTheFact() mailnews/base/search/src/nsMsgFilterService.cpp 4 xul.dll nsMsgFilterAfterTheFact::`vector deleting destructor'(unsigned int) 5 xul.dll nsCommandHandler::Release() content/base/src/nsReferencedElement.cpp 6 xul.dll nsRefPtr<nsNavHistoryFolderResultNode>::`scalar deleting destructor'(unsigned int) 7 xul.dll nsTArray<nsCOMPtr<nsIMsgSendLaterListener>,nsTArrayDefaultAllocator>::DestructRange(unsigned int,unsigned int) objdir-tb/mozilla/dist/include/nsTArray.h 8 xul.dll nsTArray<nsCOMPtr<nsIDBChangeListener>,nsTArrayDefaultAllocator>::RemoveElementsAt(unsigned int,unsigned int) objdir-tb/mozilla/dist/include/nsTArray.h 9 xul.dll nsAutoTObserverArray<nsCOMPtr<nsIThreadObserver>,2>::Clear() objdir-tb/mozilla/dist/include/nsTObserverArray.h 10 xul.dll nsMsgMailNewsUrl::SetUrlState(bool,unsigned int) mailnews/base/util/nsMsgMailNewsUrl.cpp 11 xul.dll nsImapMailFolder::SetUrlState(nsIImapProtocol *,nsIMsgMailNewsUrl *,bool,bool,unsigned int) mailnews/imap/src/nsImapMailFolder.cpp 12 xul.dll `anonymous namespace'::SyncRunnable5<nsIImapMailFolderSink,nsIImapProtocol *,nsIMsgMailNewsUrl *,bool,bool,unsigned int>::Run() mailnews/imap/src/nsSyncRunnableHelpers.cpp perhaps related is bp-2d52c557-951f-4d9d-ba02-d5bbc2130722 jemalloc_crash | arena_dalloc | moz_free | nsSupportsArray::DeleteArray()
Are there any more stacks like this?
OS: Windows NT → Windows XP
Version: unspecified → 17
(In reply to :aceman from comment #1) > Are there any more stacks like this? do you mean with nsMsgFilterAfterTheFact::~nsMsgFilterAfterTheFact on stack? hard to say - we don't yet have the ability to search crash-stats for frames 1-* perhaps correlates to bug 555539 or SyncRunnable5? and FWIW https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=short_desc&bug_severity=critical&bug_severity=major&bug_severity=normal&type0-0-1=substring&field0-0-1=keywords&query_format=advanced&short_desc_type=allwordssubstr&value0-0-1=crash&type0-0-0=anywordssubstr&value0-0-0=crash%20segfault&short_desc=nsMsgFilterAfterTheFact&list_id=7880342
I get similar stacks to this one (see example below) in a reproducible fashion. I have two IMAP accounts (accounts 1 and 2) and I have setup one message filter in account 2 that simply moves every e-mail from its inbox to the inbox of account 1. If I run the filter and, while it is still running, I open account 1 inbox, Thunderbird crashes. However, if I first wait for the filter to finish its job, and only then I open account 1 inbox, I never get a crash. I am currently running the filters manually always, to avoid crashes. But I can reproduce the crash at will, by doing as stated above. The report of the last one is here: https://crash-stats.mozilla.com/report/index/3716c3fd-5af0-4eb9-96a6-14cea2131128 This is the crash stack: 0 @0xe7a614c0 1 libxul.so nsMsgSearchSession::DestroyTermList() mailnews/base/search/src/nsMsgSearchSession.cpp 2 libxul.so nsMsgSearchSession::~nsMsgSearchSession mailnews/base/search/src/nsMsgSearchSession.cpp 3 libxul.so nsMsgSearchSession::~nsMsgSearchSession mailnews/base/search/src/nsMsgSearchSession.cpp 4 libxul.so nsMsgSearchSession::Release() mailnews/base/search/src/nsMsgSearchSession.cpp 5 libxul.so nsCOMPtr_base::~nsCOMPtr_base objdir-tb/mozilla/dist/include/nsCOMPtr.h 6 libxul.so nsMsgFilterAfterTheFact::~nsMsgFilterAfterTheFact objdir-tb/mozilla/dist/include/nsCOMPtr.h 7 libxul.so nsMsgFilterAfterTheFact::~nsMsgFilterAfterTheFact mailnews/base/search/src/nsMsgFilterService.cpp 8 libxul.so nsMsgFilterAfterTheFact::Release() mailnews/base/search/src/nsMsgFilterService.cpp 9 libxul.so nsCOMPtr_base::~nsCOMPtr_base objdir-tb/mozilla/dist/include/nsCOMPtr.h 10 libxul.so nsTArray_Impl<nsCOMPtr<nsIUrlListener>, nsTArrayInfallibleAllocator>::DestructRange(unsigned int, unsigned int) objdir-tb/mozilla/dist/include/nsCOMPtr.h 11 libxul.so nsTArray_Impl<nsCOMPtr<nsIUrlListener>, nsTArrayInfallibleAllocator>::RemoveElementsAt(unsigned int, unsigned int) objdir-tb/mozilla/dist/include/nsTArray.h 12 libxul.so nsTArray_Impl<nsCOMPtr<nsIUrlListener>, nsTArrayInfallibleAllocator>::Clear() objdir-tb/mozilla/dist/include/nsTArray.h 13 libxul.so nsAutoTObserverArray<nsCOMPtr<nsIUrlListener>, 0u>::Clear() objdir-tb/mozilla/dist/include/nsTObserverArray.h 14 libxul.so nsMsgMailNewsUrl::SetUrlState(bool, tag_nsresult) mailnews/base/util/nsMsgMailNewsUrl.cpp 15 libxul.so nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult) mailnews/imap/src/nsImapMailFolder.cpp 16 libxul.so SyncRunnable5<nsIImapMailFolderSink, nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult>::Run mailnews/imap/src/nsSyncRunnableHelpers.cpp 17 libxul.so nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 18 libxul.so NS_ProcessNextEvent(nsIThread*, bool) objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp 19 libxul.so mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 20 libxul.so MessageLoop::RunInternal() ipc/chromium/src/base/message_loop.cc 21 libxul.so MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 22 libxul.so nsBaseAppShell::Run() widget/xpwidgets/nsBaseAppShell.cpp 23 libxul.so nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp 24 libxul.so XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp 25 libxul.so XREMain::XRE_main(int, char**, nsXREAppData const*) toolkit/xre/nsAppRunner.cpp 26 libxul.so XRE_main toolkit/xre/nsAppRunner.cpp 27 thunderbird main mail/app/nsMailApp.cpp 28 libc-2.11.1.so libc-2.11.1.so@0x16bf6 29 thunderbird thunderbird@0x2b01 30 thunderbird nsGetterAddRefs<nsIFile>::operator nsIFile**() objdir-tb/mozilla/dist/include/nsCOMPtr.h 31 @0x1 32 ld-2.11.1.so ld-2.11.1.so@0xeb90 33 ld-2.11.1.so ld-2.11.1.so@0x1d900 34 @0x1
By the way, I get these crashes running Thunderbird 23.0 on Ubuntu Linux 10.04.
For anyone that may know what this means: I don't get the crash right when I open the inbox of account 1. When I do, and the message filter is still running on account 2, I can see the contents of account 1 inbox, without having been updated yet. It is when the filter finishes its job on account 2, and the contents of account 1 inbox are updated when the crash happens.
Just installed Thunderbird 24.1.1 and I still can reproduce the crash: https://crash-stats.mozilla.com/report/index/dceb7348-8620-4206-a32e-a47092131128
Crash Signature: [@ nsMsgSearchSession::~nsMsgSearchSession()] → [@ nsMsgSearchSession::~nsMsgSearchSession()] [@ nsMsgSearchSession::~nsMsgSearchSession]
Depends on: 537017
I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Ups, my bad and due to ( bug #1348631 ) looks like there are sill crashes, so reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The very few stacks that exist for current verions don't match, so I don't think it is worth keeping this open.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → WORKSFORME
Depends on: 1666115
You need to log in before you can comment on or make changes to this bug.