All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED WORKSFORME

Status

--
critical
RESOLVED WORKSFORME
5 years ago
2 years ago

People

(Reporter: wsmwk, Unassigned)

Tracking

({crash})

x86
Windows XP
crash

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

5 years ago
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()

Comment 1

5 years ago
Are there any more stacks like this?
OS: Windows NT → Windows XP
Version: unspecified → 17
(Reporter)

Comment 2

5 years ago
(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

Comment 3

5 years ago
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

Comment 4

5 years ago
By the way, I get these crashes running Thunderbird 23.0 on Ubuntu Linux 10.04.

Comment 6

5 years ago
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.

Comment 7

5 years ago
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

Updated

3 years ago
Crash Signature: [@ nsMsgSearchSession::~nsMsgSearchSession()] → [@ nsMsgSearchSession::~nsMsgSearchSession()] [@ nsMsgSearchSession::~nsMsgSearchSession]
(Reporter)

Updated

3 years ago
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
Last Resolved: 2 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 → ---
(Reporter)

Comment 10

2 years ago
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
Last Resolved: 2 years ago2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.