Closed Bug 871622 Opened 12 years ago Closed 2 years ago

Crash when manually running filter with a rule Copy To an imap folder [@ nsImapMailFolder::SetUrlState] trying to use freed memory

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: kloor68373, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [needs retest])

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 20130409194949 Steps to reproduce: I caused a filter to move a message from a rss to an imap account. This message has a content so that it is considered spam for thunderbird. The target folder in the imap tree view is selected so that the list of items in this folder is listed Actual results: TB crashes Expected results: No Crash. Future crash reports will be labeled with this issues id
ImportAttachment::`scalar deleting destructor''(unsigned int) bp-a18e4f3a-425f-4827-856e-cf04d2130513 0 xul.dll ImportAttachment::`scalar deleting destructor' 1 xul.dll nsTArray<nsRefPtr<mozilla::dom::Element>,nsTArrayDefaultAllocator>::DestructRang objdir-tb/mozilla/dist/include/nsTArray.h:1225 2 xul.dll nsTArray<nsCOMPtr<nsIDBChangeListener>,nsTArrayDefaultAllocator>::RemoveElements objdir-tb/mozilla/dist/include/nsTArray.h:945 3 xul.dll nsAutoTObserverArray<nsCOMPtr<nsIAccessiblePivotObserver>,0>::Clear objdir-tb/mozilla/dist/include/nsTObserverArray.h:234 4 xul.dll nsMsgMailNewsUrl::SetUrlState mailnews/base/util/nsMsgMailNewsUrl.cpp:105 5 xul.dll nsImapMailFolder::SetUrlState mailnews/imap/src/nsImapMailFolder.cpp:6838 6 xul.dll `anonymous namespace'::SyncRunnable5<nsIImapMailFolderSink,nsIImapProtocol*,nsIM mailnews/imap/src/nsSyncRunnableHelpers.cpp:250 7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:624 dupe of bug 861661?
Crash Signature: [@ ImportAttachment::`scalar deleting destructor''(unsigned int) ]
i also got a crash in recreating the OPs 'filter copy to imap' problem. in this case the imap folder being copied to (manual filter run) was also previously selected. the same filter worked fine when invoked on Checking Mail. http://crash-stats.mozilla.com/report/index/bp-94181dd3-2dd8-48bb-a74e-ad4f22130515 http://crash-stats.mozilla.com/report/index/bp-b520dd18-6328-4658-81ca-7a94c2130515 it's a different crash sig, but the trace in both seems similar. the crash happens to (feed) messages regardless of whether they have attachments.
Status: UNCONFIRMED → NEW
Component: Untriaged → Folder and Message Lists
Ever confirmed: true
Summary: spam detection in the course of filter's message copying causes crash when target folder list view is opened → Crash when manually running filter with a rule Copy To an imap folder
Does this happen with Thunderbird 20 or newer?
Severity: normal → critical
Crash Signature: [@ ImportAttachment::`scalar deleting destructor''(unsigned int) ] → [@ ImportAttachment::`scalar deleting destructor''(unsigned int) ] [@0x0 | nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, unsigned int)
Flags: needinfo?(kloor68373)
Flags: needinfo?(alta88)
Keywords: crash
* Still happening on my TB 17.0.7 on Linux (this the newest version in Ubuntu 12.04 packages, don't have a TB 20 yet) * I will check TB on Windows tomorrow when back in my office
Answer to "Does this happen with Thunderbird 20 or newer?" According to https://wiki.mozilla.org/Releases next Version after TB 17 will be TB 24 (on September 17, 2013). Should I wait unil then or run my test on some candidate (which one)?
I regret, bug persists with 24.0a2 (2013-07-21) from https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-aurora-l10n/thunderbird-24.0a2.de.win32.installer.exe * Same behaviour: ** Message is copied successfully to IMAP folder ** Immediately crashs with bug report Bug reports were sent: * before installation of nightly on TB 17 http://crash-stats.mozilla.com/report/index/bp-a5459c36-558d-48d2-83e3-f3b542130722 * after installation of nightly 24.0a2 (2013-07-21) http://crash-stats.mozilla.com/report/index/bp-c79db1bd-7f78-4e78-8a78-828b22130722
Flags: needinfo?(kloor68373)
There is another open bug about crash involving nsImapMailFolder::SetUrlState in bug 650615.
Component: Folder and Message Lists → Filters
Product: Thunderbird → MailNews Core
(In reply to kloor68373 from comment #8) > I regret, bug persists with 24.0a2 (2013-07-21) ... > Bug reports were sent: > * before installation of nightly on TB 17 > http://crash-stats.mozilla.com/report/index/bp-a5459c36-558d-48d2-83e3- > f3b542130722 nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, unsigned int) > * after installation of nightly 24.0a2 (2013-07-21) > http://crash-stats.mozilla.com/report/index/bp-c79db1bd-7f78-4e78-8a78- > 828b22130722 nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult)
Crash Signature: [@ ImportAttachment::`scalar deleting destructor''(unsigned int) ] [@0x0 | nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, unsigned int) → [@ ImportAttachment::`scalar deleting destructor''(unsigned int) ] [@0x0 | nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, unsigned int)] [@ nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, …
Flags: needinfo?(alta88)
bug 650615 comment 6 also has "steps" user gthiel has several crash signatures - @0x0 | nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult) bp-4e57e2c9-2aa7-40e0-93b3-448ef2140121 - nsRefPtr<mozilla::css::GroupRule>::`scalar deleting destructor''(unsigned int) | nsTArray_Impl<nsRefPtr<mozilla::css::GroupRule>, nsTArrayInfallibleAllocator>::DestructRange(unsigned int, unsigned int) bp-3ac90821-955c-40b4-bea7-564782140131 - NS_InvokeByIndex bp-a96d643f-625e-40f6-bf72-360ee2140130 - nsMsgFilterList::GetFilterNamed(nsAString_internal const&, nsIMsgFilter**) bp-0c0c0521-7473-4ea5-b86a-db48e2140130 which may be related to bug 963362 (and perhaps others) Another such user with many crashes is gabriel bp-65220d60-2069-494e-a168-d03842140130
Blocks: 650615
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=963362
Summary: Crash when manually running filter with a rule Copy To an imap folder → Crash when manually running filter with a rule Copy To an imap folder [@ nsImapMailFolder::SetUrlState]
bp-934ee38c-4a2c-4a25-95db-5413e2140327 has a reporter who writes Running a filter using the Custom header option. Using "Sender" contains "Google Calendar". Do we need more data before generating fix? Or should we await the efforts of aceman and others in bug 963362?
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(acelists)
(In reply to Wayne Mery (:wsmwk) from comment #12) > bp-934ee38c-4a2c-4a25-95db-5413e2140327 has a reporter who writes > Do we need more data before generating fix? I don't think that stack is useful (http://hg.mozilla.org/releases/comm-esr24/annotate/a5ac6f0c9785/mailnews/imap/src/nsImapMailFolder.cpp#l6804)
Flags: needinfo?(mkmelin+mozilla)
Sorry, no idea about this. Try Neil.
Flags: needinfo?(acelists)
(In reply to Wayne Mery from comment #12) > bp-934ee38c-4a2c-4a25-95db-5413e2140327 has a reporter who writes > Running a filter using the Custom header option. > Using "Sender" contains "Google Calendar". > > Do we need more data before generating fix? The main thread appears to have crashed in the line if (aUrl && !aSuspend) return aUrl->SetUrlState(isRunning, statusCode); The crash reason is execution violation, which suggests that aUrl is pointing into dead memory. Unfortunately thread 20 is still waiting for its sync runnable call to complete, and it has aUrl stored in an nsCOMPtr: nsCOMPtr<nsIMsgMailNewsUrl> mailnewsurl = do_QueryInterface(m_runningUrl, &rv); We know aURl is not null, since we just null-checked it (and we would probably get a read violation rather than an execute violation in that case), so we would therefore expect it to be pointing to live memory, since it appears to have been returned from do_QueryInterface here. Someone with access to both the crash dump and symbols could presumably verify that the two values are the same, but that wouldn't explain the access violation. (I don't think a crash dump would contain enough information to diagnose that.)
are these crashes along the same lines? bp-376035f6-1a7c-4413-86b4-d38322140801 TB31 (chris smith) nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult) bp-1da224e7-633a-469c-b44e-32d5a2140809 TB31 (chris smith) nsRefPtr<mozilla::dom::workers::SharedWorker>::`scalar deleting destructor''(unsigned int) | nsTArray_Impl<nsRefPtr<mozilla::dom::file::ArchiveItem>, nsTArrayInfallibleAllocator>::DestructRange(unsigned int, unsigned int)
Flags: needinfo?(neil)
(In reply to Wayne Mery from comment #16) > are these crashes along the same lines? > > bp-376035f6-1a7c-4413-86b4-d38322140801 TB31 (chris smith) > nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, > bool, tag_nsresult) Looks like the same crash as comment #12, assuming comment #15 is valid. > bp-1da224e7-633a-469c-b44e-32d5a2140809 TB31 (chris smith) > nsRefPtr<mozilla::dom::workers::SharedWorker>::`scalar deleting > destructor''(unsigned int) | > nsTArray_Impl<nsRefPtr<mozilla::dom::file::ArchiveItem>, > nsTArrayInfallibleAllocator>::DestructRange(unsigned int, unsigned int) Might be the same crash; we manage to call SetUrlState, and even manage to call GetStatusFeedback, but then we crash clearing the mUrlListeners, so it could be trying to use freed memory.
Flags: needinfo?(neil)
Crash Signature: [@ ImportAttachment::`scalar deleting destructor''(unsigned int) ] [@0x0 | nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, unsigned int)] [@ nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, … → [@ ImportAttachment::`scalar deleting destructor''(unsigned int) ] [@0x0 | nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, unsigned int) ] [@ nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool,…
A user with this signature [1] also sees mozilla::dom::OwningNonNull<mozilla::dom::TelephonyCallGroup>::`scalar deleting destructor''(unsigned int) (started appearing in version 31.3.0) nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult) nsCOMPtr<nsIRDFObserver>::`scalar deleting destructor''(unsigned int) | nsTArray_Impl<nsRefPtr<mozilla::dom::indexedDB::IDBDatabase>, nsTArrayInfallibleAllocator>::DestructRange(unsigned int, unsigned int) OOM | small nsMsgHdr::~nsMsgHdr() XPCIncrementalReleaseRunnable::ReleaseNow(bool) nsMsgIncomingServer::ConfigureTemporaryReturnReceiptsFilter(nsIMsgFilterList*) nsMsgFilterList::GetFilterNamed(nsAString_internal const&, nsIMsgFilter**) nsMsgFilterList::GetFilterAt(unsigned int, nsIMsgFilter**) arena_dalloc_small | arena_dalloc | je_free | mozilla::dom::HTMLParagraphElement::`vector deleting destructor''(unsigned int) @0x0 | XPCIncrementalReleaseRunnable::ReleaseNow(bool) [1] f.friedmann https://crash-stats.mozilla.com/report/index/b7d40fa6-d1e2-4a0f-ad21-0286d2141218
Blocks: 1116502
Depends on: 818305
Blocks: 1145983
Mac equivalents? nsMsgMailNewsUrl::SetUrlState(bool, nsresult) bp-2b7917cf-6a68-4af2-be58-e18d62150617 TB38 nsMsgMailNewsUrl::SetUrlState(bool, tag_nsresult) bp-4280a68f-69a6-49a9-9cd6-75c492150617 TB31
perhaps also nsMaybeWeakPtr<T>::`scalar deleting destructor''(unsigned int) bp-64499db8-abee-4f16-9b49-eeaed2150723
Crash Signature: , unsigned int) ] [@ nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult) ] → , unsigned int) ] [@ nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult) ] [@ nsMaybeWeakPtr<T>::`scalar deleting destructor''(unsigned int) ]
Crash Signature: , unsigned int) ] [@ nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult) ] [@ nsMaybeWeakPtr<T>::`scalar deleting destructor''(unsigned int) ] → , unsigned int) ] [@ nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, tag_nsresult) ] [@ nsMaybeWeakPtr<T>::`scalar deleting destructor''(unsigned int) ] [@ ImportAttachment::`scalar deleting destructor'' ] [@0x0 | nsIma…

Can you still reproduce, and provide steps?

Manual filter to imap, or automatic?

Example crashes are rather infrequent

Flags: needinfo?(kloor68373)
Flags: needinfo?(alta88)
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=610472, https://bugzilla.mozilla.org/show_bug.cgi?id=849585
Summary: Crash when manually running filter with a rule Copy To an imap folder [@ nsImapMailFolder::SetUrlState] → Crash when manually running filter with a rule Copy To an imap folder [@ nsImapMailFolder::SetUrlState] trying to use freed memory
Crash Signature: [@ ImportAttachment::`scalar deleting destructor''(unsigned int) ] [@0x0 | nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool, unsigned int) ] [@ nsImapMailFolder::SetUrlState(nsIImapProtocol*, nsIMsgMailNewsUrl*, bool, bool,… → [@ nsMaybeWeakPtr<T>::`scalar deleting destructor'' ] [@ ImportAttachment::`scalar deleting destructor'' ] [@0x0 | nsImapMailFolder::SetUrlState ] [@ nsImapMailFolder::SetUrlState ]

A copy to IMAP now works when signed into the folder, and shows an error dialog when not (when manually run). So this is wfm on trunk.

Flags: needinfo?(alta88)

(In reply to alta88 from comment #22)

A copy to IMAP now works when signed into the folder, and shows an error dialog when not (when manually run). So this is wfm on trunk.

The behavior isn't correct though, and I thought it was once fixed; ie on manual run, a non logged in IMAP folder should offer a login dialog if necessary. And of course the filter log only shows the filter successfully applied message, and not the far more useful async final result failure or success message.

wsm, if you'd like me to look at fixing things like this, send a pm.

Crashes do not occur with 68.2.2 on Windows 64

  • on manual and automatic filtering
  • when target folder is opened

I was not able to reproduce the reported situation that TB's spam filter moves the filtered message from the target folder to spam folder because I do not have a spam mail at hand. Is there a special signature (which is always classified as spam) to be used in a mail for testing purpose? Manually tagging a mail as spam in the origin folder of the filter does not work since the filter won't be applied in the target folder and the mail will not be removed from it to the configured spam target folder. I do not remember how to reproduce the error.

Flags: needinfo?(kloor68373)

(In reply to kloor68373 from comment #24)

I do not have a spam mail at hand. Is there a special signature (which is always classified as spam) to be used in a mail for testing purpose?

Aceman, what is best way to construct a message that would likely be labeled as spam?

Severity: critical → normal
Crash Signature: [@ nsMaybeWeakPtr<T>::`scalar deleting destructor'' ] [@ ImportAttachment::`scalar deleting destructor'' ] [@0x0 | nsImapMailFolder::SetUrlState ] [@ nsImapMailFolder::SetUrlState ] → [@0x0 | nsImapMailFolder::SetUrlState ] [@ nsImapMailFolder::SetUrlState ]
Flags: needinfo?(acelists)

In a test profile, you should be able to train TB on any message to be considered spam by marking it as spam manually a few times. Then it should be marked as spam automatically upon receipt.

Flags: needinfo?(acelists)
Whiteboard: [needs retest]

I am not able any more to re-test because the bug occurred on my company computer. To my great regret, my company switched from a self hosted mail server (supporting IMAP) to a provider in Redmond where IMAP is not supported and thus I have to use their ugly proprietary mail client. On my home computer I operate on Linux and do not use RSS feeds, so this is not a suitable test environment.

kloor, thank you for that information.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1749276
You need to log in before you can comment on or make changes to this bug.