673904 - crash in nsFolderCompactState::`scalar deleting destructor'' during compact after deleting mail

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Wayne Mery (:wsmwk)]

bienvenu, this is the crash I am suggesting needs priority. It is not new to version 5, but crashes have very significantly increased. I estimate a couple hundred users (after eliminating the duplicate crashes).

And, this is very strange, the stack does not appear for version 3.1.10 and 3.1.11.  ref: https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=arena_dalloc_small%20%7C%20arena_dalloc%20%7C%20free%20%7C%20nsFolderCompactState%3A%3A%60scalar%20deleting%20destructor%27%27%28unsigned%20int%29&reason_type=contains&date=07%2F25%2F2011%2006%3A02%3A06&range_value=16&range_unit=weeks&hang_type=any&process_type=any&do_query=1&admin=1&signature=arena_dalloc_small%20%7C%20arena_dalloc%20%7C%20free%20%7C%20nsFolderCompactState%3A%3A%60scalar%20deleting%20destructor%27%27%28unsigned%20int%29


[@ arena_dalloc_small | arena_dalloc | free | nsFolderCompactState::`scalar deleting destructor''(unsigned int)]

I have not correlated this to a specific getsatisfaction report. And I haven't checked whether this is related to bug 484550, bug 531568, bug 551428.

bp-0b3a10a4-a2ac-4690-bae6-e6de32110717 (adrians) "When I try to empty the deleted folder, it tries to do a compact, and fails and Thunderbird crashes"

EXCEPTION_ACCESS_VIOLATION_READ
0x5000
0 	mozcrt19.dll 	arena_dalloc_small 	objdir-tb/mozilla/memory/jemalloc/crtsrc/jemalloc.c:4156
1 	mozcrt19.dll 	arena_dalloc 	objdir-tb/mozilla/memory/jemalloc/crtsrc/jemalloc.c:4284
2 	mozcrt19.dll 	free 	objdir-tb/mozilla/memory/jemalloc/crtsrc/jemalloc.c:6124
3 	xul.dll 	nsFolderCompactState::`scalar deleting destructor' 	
4 	xul.dll 	nsSaveMsgListener::Release 	mailnews/compose/src/nsMsgCompose.cpp:3411
5 	xul.dll 	nsRefPtr<nsTypedSelection>::~nsRefPtr<nsTypedSelection> 	objdir-tb/mozilla/dist/include/nsAutoPtr.h:969
6 	xul.dll 	nsMsgLocalMailFolder::Compact 	mailnews/local/src/nsLocalMailFolder.cpp:864
7 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
8 	xul.dll 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2369
9 	xul.dll 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1610
10 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4737
11 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:646
12 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:726
13 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:849
14 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5153
15 	xul.dll 	nsJSContext::CallEventHandler 	dom/base/nsJSEnvironment.cpp:1903
16 	xul.dll 	nsJSEventListener::HandleEvent 	dom/src/events/nsJSEventListener.cpp:224
17 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1136
18 	xul.dll 	nsEventListenerManager::HandleEventInternal 	content/events/src/nsEventListenerManager.cpp:1233
19 	xul.dll 	nsEventListenerManager::HandleEvent 	content/events/src/nsEventListenerManager.h:146
20 	xul.dll 	nsEventTargetChainItem::HandleEvent 	content/events/src/nsEventDispatcher.cpp:213

Comment 1

[David :Bienvenu]

The stacks are weird - the symbols don't match the lines of code referenced. In particular, it refs nsFolderCompactState but points at a line of code that belongs to nsSaveMsgListener. Also, nsRefPtr<nsTypedSelection> is not involved.

Comment 2

[Wayne Mery (:wsmwk)]

the crash may also depend somewhat on folder size(s). perhaps the aggregate? 
In http://getsatisfaction.com/mozilla_messaging/topics/compacting_files#reply_6185247 he writes he no longer crashes after reducing the size of his folders, and doesn't mention having taken any other corrective action.

Comment 3

[Wayne Mery (:wsmwk)]

eg. "can't delete anything" bp-5b912047-016e-4395-b49b-d2fc22110723 
clearly compact-related and (consistent with that) big uptick in thunderbird 5, with numerous reports on gfsn and crash-stats [1]. 

so it goes bust above frame 6?  I find no stacks with crash with nsMsgLocalMailFolder::Compact as top of stack except nsCOMPtr_base::~nsCOMPtr_base | nsMsgLocalMailFolder::CompactAll for 
bp-4567a63a-ca6c-4dea-8b87-89c2f2110724 

I am in contact with one person who says the crash happens in the background, while doing non-compact related activity. I am checking to see if autocompact is enabled (which I would expect)


[1] https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=arena_dalloc_small%20%7C%20arena_dalloc%20%7C%20free%20%7C%20nsFolderCompactState%3A%3A%60scalar%20deleting%20destructor%27%27%28unsigned%20int%29&reason_type=contains&date=07%2F31%2F2011%2010%3A34%3A36&range_value=4&range_unit=weeks&hang_type=any&process_type=all&do_query=1&signature=arena_dalloc_small%20%7C%20arena_dalloc%20%7C%20free%20%7C%20nsFolderCompactState%3A%3A%60scalar%20deleting%20destructor%27%27%28unsigned%20int%29

Comment 4

[Marcia Knous [:marcia]]

Wayne: I don't see this signature showing up in Firefox crash stats - did you mean to nominate it for tracking Firefox 7?

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to Marcia Knous [:marcia] from comment #4)
> Wayne: I don't see this signature showing up in Firefox crash stats - did
> you mean to nominate it for tracking Firefox 7?

oops. removing

Comment 6

[Wayne Mery (:wsmwk)]

reporter of 0b3a10a4-a2ac-4690-bae6-e6de32110717  seems to think this was related to using Empty deleted Folder Button addon https://addons.mozilla.org/en-us/thunderbird/addon/empty-deleted-folder-button-th/

unfortunately Adrian didn't comment here in the bug report

Comment 7

[Wayne Mery (:wsmwk)]

bienvenu, is bp-f11052f7-8967-42e9-a6a0-833d62111219 equally oddball?
bp-f11052f7-8967-42e9-a6a0-833d62111219 is from http://getsatisfaction.com/mozilla_messaging/topics/unable_to_compact_folders_then_crash where the user has crashed through multiple releases.

Comment 8

[David :Bienvenu]

hmm, that seems to be caused by an error enumerating the descendents of a folder. The stack trace is confused, but that could just be the symbol handling for comptrs.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to David :Bienvenu from comment #8)
> hmm, that seems to be caused by an error enumerating the descendents of a
> folder. The stack trace is confused, but that could just be the symbol
> handling for comptrs.

original crash sig* stops in version 9, i.e. after version 8.
* arena_dalloc_small | arena_dalloc | free | nsFolderCompactState::`scalar deleting destructor''(unsigned int)

version 9 seems to pick up with  arena_dalloc_small | arena_dalloc | je_free | nsFolderCompactState::`scalar deleting destructor''(unsigned int)

Comment 10

[Wayne Mery (:wsmwk)]

#48 crash for TB17.0.2.
many crashes mention slowness is common

But signature for bug 781654 seems to be gone in TB17.0.2

Comment 11

[Scoobidiver (away)]

It's #36 top crasher in TB 17.0.2 so not a top crasher according to https://wiki.mozilla.org/CrashKill/Topcrash

Comment 12

[Wayne Mery (:wsmwk)]

#4 crash for Thunderbird 17.0.6, so very much a topcrash. I don't know at when the crash rate went back up or why.  There are dup crashes - it's hard to say to what extent. But even if the dup rate is 80% this would still be a top 20 crash.

I  temporarily gave up on this bug because McAfee crashes make dealing with this more complicated. But McAfee are still thrashing without a fix, and it looks like most current crashes don't involve McAfee. 

I have 4-5 users who might assist us, out of 30+ that I mailed in February and March.  Also we have a reporter in https://getsatisfaction.com/mozilla_messaging/topics/compact_folders_causes_tb_to_crash whose crash is bp-672fc950-1cc6-4d32-b5d4-fb28a2130620  

Deleting mail is involved of course.  But more good info is needed.I think most (perhaps all?) are pop users.  Need to find out whether most or all get the compact prompt, vs no prompt.

Comment 13

[Scoobidiver (away)]

(In reply to Wayne Mery (:wsmwk) from comment #12)
> I don't know at when the crash rate went back up or why.
Between four weeks ago (see https://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/17.0.6/28/browser) and two weeks ago (see https://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/17.0.6/14/browser).

According to comments, it's related to compacting folders.

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to Scoobidiver from comment #13)
> (In reply to Wayne Mery (:wsmwk) from comment #12)
> > I don't know at when the crash rate went back up or why.
> Between four weeks ago (see
> https://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/17.0.6/28/
> browser) and two weeks ago (see
> https://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/17.0.6/14/
> browser).

I suspect that's in the period where 17.0.6 release was still rolling out. one week crash counts:
 289 5/29
1094 6/5
2229 6/12

Comment 15

[Wayne Mery (:wsmwk)]

#3 crash - 17.0.8. 

In the last 8 months the only crash of this signature in beta builds is version 12!
eg bp-9a195c00-14af-4295-8134-9cc032130329 12.0.1 beta

very, very odd to not see this signature in beta, earlybird and development build crashes. So either 
- it's been fixed for a very long time, in TB18 for example, but not gotten to TB17.0.x (or perhaps even in TB17 but something prevents the fix from being effective)
- no one using beta, earlybird, daily does compacts (improbable)
- something in our code changed that causes us to not hit the failing code

Comment 16

[Wayne Mery (:wsmwk)]

so far, no crashes in TB24. But leaving open until more users on TB24

Comment 17

[Wayne Mery (:wsmwk)]

For Gary https://getsatisfaction.com/mozilla_messaging/topics/compact_folders_causes_tb_to_crash the crashing stopped after an update

Comment 18

[Wayne Mery (:wsmwk)]

rechecked crash-stats -- signature totally gone for version 24.0 and 24.0.1. 
ANd also confirmed with contact from a few users who crash in 17 and not in 24.

I believe this was fixed by Hiro's patch in bug 786487. 
Yay Hiro! Fixed our #3 crash.

crash bug 406851 remains