193998 - Crash on exiting Mozilla after using MailNews [@ ntdll.dll] [@ nsRDFResource::~nsRDFResource]

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Jari Ahonen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030216
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030216

(Note: Guessing MailNews/IMAP as problem component, see below why)

I'm seeing this crash on exiting Mozilla fairly regularly now. Seems to only
happen when MailNews is used in the session or at least I haven't seen this yet
after just browsing. Everything goes normally but when closing Mozilla with
File->Exit I get a crash.

Talkback window pops up but cannot send the data. Trying to view the crash
details in talkback just shows up a blank detail page. Stack trace from drWatson
looks like this:
*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012FAC4 77FCB795 00230000 025A5FA0 0012FB3C 00000000 ntdll!RtlFreeHeap 
0012FB6C 7800115C 00230000 00000000 025A5FA8 0259FB00 ntdll!RtlFreeHeap 
0012FBB4 62078389 025A5FA8 0259FB04 0259FB00 6206236A !free 
0012FBC4 6206236A 0259FB00 620783D0 00000001 6170FA2C
msgbsutl!CreateUnicodeStringFromUtf7  (FPO: [0,0,2])
0012FBCC 620783D0 00000001 6170FA2C 0312D818 6162B3FA
msgbsutl!nsMsgFolder::operator=  (FPO: [1,0,1])
0012FBDC 6162B3FA 0259FB00 040BB470 610114F1 02BAF8FC
msgbsutl!CreateUnicodeStringFromUtf7  (FPO: [1,0,2])
0012FBE8 610114F1 02BAF8FC 0312D818 00000001 02BAF8F0 gklayout!NS_NewXMLDocument
 (FPO: [3,0,1])
0012FC0C 6162B4C2 00000029 00000040 00000080 02BAF8F0 plds4!PL_HashTableDestroy
 (FPO: [EBP 0x02BAF8F0] [1,1,4])
0012FC20 6162768C 02BAF850 61627624 03105D88 02BAF850 gklayout!NS_NewXMLDocument
 (FPO: [0,0,1])
0012FC28 61627624 03105D88 02BAF850 61620792 02F75BB8 gklayout!NS_NewXMLDocument
 (FPO: [0,0,1])
0012FC34 61620792 02F75BB8 61627722 00000001 61DF97DC gklayout!NS_NewXMLDocument
 (FPO: [0,0,2])
0012FC3C 61627722 00000001 61DF97DC 02BAF850 61DF8CFE gklayout!NS_NewXMLDocument
 (FPO: [1,0,1])
0012FC44 61DF97DC 02BAF850 61DF8CFE 025EA990 02BAF850 gklayout!NS_NewXMLDocument
 (FPO: [1,0,0])
0012FC4C 61DF8CFE 025EA990 02BAF850 00000000 61E00DF8
xpcom!nsSupportsHashtable::ReleaseElement  (FPO: [3,0,0])
0012FC5C 61E00DF8 02F75BB8 03105D70 00000002 0012FCAC
xpcom!nsHashtable::Enumerate  (FPO: [4,0,0])
02BAF8F0 02CDC710 02CDC738 03027138 02BAF910 02BAF910 xpcom!PL_DHashTableEnumerate 
02CDC6E8 030F37C8 0000001A 6162F391 6162F39A 6169D32E <nosymbols> 
02FD3ED8 02CDC6E8 00380038 00390035 0031002D 00000035 <nosymbols> 
002301C8 02FD3ED8 02672E68 0326A260 0246E650 025F8C00 <nosymbols> 
...
(there are plenty of the <nosymbols> lines after this one.)

Stack trace looks similar every time this crash happens.


Reproducible: Sometimes

Steps to Reproduce:
1. Start mozilla and do some browsing and IMAP mail access
2. Close MailNews window
3. Close Mozilla with File->Exit


Actual Results:  
Sometimes result is Mozilla crashing with drWatson and Talkback popping up.

Expected Results:  
Application closing.


I will attach the full drWatson log file if needed but I guess the stack is the
most important part of it.

Comment 1

[José Jeria]

Dont know if this is the same bug, but i crash without talkback when clicking on
the "mail & newsgroups" icon in the component bar.

Comment 2

[Jari Ahonen]

Turned junk mail controls off to see if this is related. Crash still happens but
the stack looks slightly different, no more UTF7 functions:
FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012FBDC 6162B3FA 01E5C470 03F7E5A0 610114F1 03F1DFAC <nosymbols> 
0012FBE8 610114F1 03F1DFAC 03E70148 00000001 03F1DFA0 gklayout!NS_NewXMLDocument
 (FPO: [3,0,1])
0012FC0C 6162B4C2 0000000A 00000040 00000080 03F1DFA0 plds4!PL_HashTableDestroy
 (FPO: [EBP 0x03F1DFA0] [1,1,4])
0012FC20 6162768C 03F1DF00 61627624 03F15620 03F1DF00 gklayout!NS_NewXMLDocument
 (FPO: [0,0,1])
0012FC28 61627624 03F15620 03F1DF00 61620792 03FD7DB0 gklayout!NS_NewXMLDocument
 (FPO: [0,0,1])
0012FC34 61620792 03FD7DB0 61627722 00000001 61DF97DC gklayout!NS_NewXMLDocument
 (FPO: [0,0,2])
0012FC3C 61627722 00000001 61DF97DC 03F1DF00 61DF8CFE gklayout!NS_NewXMLDocument
 (FPO: [1,0,1])
0012FC44 61DF97DC 03F1DF00 61DF8CFE 029DF778 03F1DF00 gklayout!NS_NewXMLDocument
 (FPO: [1,0,0])
0012FC4C 61DF8CFE 029DF778 03F1DF00 00000000 61E00DF8
xpcom!nsSupportsHashtable::ReleaseElement  (FPO: [3,0,0])
0012FC5C 61E00DF8 03FD7DB0 03F155F0 00000001 0012FCAC
xpcom!nsHashtable::Enumerate  (FPO: [4,0,0])
03F1DFA0 03EC91A8 03EC91D0 03F6ED08 03F1DFC0 03F1DFC0 xpcom!PL_DHashTableEnumerate 
03F48210 03F085E0 0000001A 6162F391 6162F39A 6169D32E <nosymbols> 
002301A0 03F48210 04CBA668 0271DA68 03FD4D50 04AE5638 <nosymbols> 
...
[and a lot more lines of <nosymbols>]

Comment 3

[Andrew Hagen]

There have been some recent IMAP fixes checked in. Reporter, do you still see
this in the latest nightly builds? Alternatively, are you still seeing it in
1.3? (It will be released in a few days)

Comment 4

[Jari Ahonen]

Still on same build (2003021608) because I'd rather not go to 1.4 alphas just
yet and the 1.3 builds on ftp site seem to be hosed (bug 195060). The crash only
happens when exiting Mozilla so I can live with it for now.

I have deleted all folder .msf files, history.dat and xul.mfl to see if this
would be data corruption in those but no help. Crash still happens almost every
time I exit Mozilla.

I'll try with a recent 1.3 nightly when the builds are stable again.

Comment 5

[Jari Ahonen]

Still happens with 1.3 nightly build 2003030205.
Stack trace looks the same.

Comment 6

[Jari Ahonen]

Trunk 1.4a 2003030208 crashes as well. Stack from drWatson below:
*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012FBEC 616150BA 02748680 00000000 610014F1 02E1C634 <nosymbols> 
0012FBF8 610014F1 02E1C634 03B89E30 00000001 02E1C628 gklayout!NS_NewXMLDocument
 (FPO: [3,0,1])
0012FC1C 61615182 00000035 00000040 00000080 02E1C628 plds4!PL_HashTableDestroy
 (FPO: [EBP 0x02E1C628] [1,1,4])
0012FC30 616113AA 02E1C588 61611342 02EFF3F8 02E1C588 gklayout!NS_NewXMLDocument
 (FPO: [0,0,1])
0012FC38 61611342 02EFF3F8 02E1C588 6160A4E9 02C54540 gklayout!NS_NewXMLDocument
 (FPO: [0,0,1])
0012FC44 6160A4E9 02C54540 6161144D 00000001 61DD83C9 gklayout!NS_NewXMLDocument
 (FPO: [0,0,2])
0012FC4C 6161144D 00000001 61DD83C9 02E1C588 61DD8D74 gklayout!NS_NewXMLDocument
 (FPO: [1,0,1])
0012FC54 61DD83C9 02E1C588 61DD8D74 0282C9F0 02E1C588 gklayout!NS_NewXMLDocument
 (FPO: [1,0,0])
0012FC5C 61DD8D74 0282C9F0 02E1C588 00000000 61DE0E07
xpcom!nsSupportsHashtable::ReleaseElement  (FPO: [3,0,0])
0012FC6C 61DE0E07 02C54540 02EFF338 00000000 0012FCBC
xpcom!nsHashtable::Enumerate  (FPO: [4,0,0])
02E1C628 02AB7708 02AB8808 02ECBEF8 02E1C648 02E1C648 xpcom!PL_DHashTableEnumerate 
02ABA268 02EA25C8 0000001A 61619044 6161904D 6168452C <nosymbols> 
02C58D00 02ABA268 00000003 00000002 00030003 00080005 <nosymbols>
...
[and a lot more of <nosymbols> lines]

Comment 7

[grylchan]

looking through bugzilla and talkback. One crash report w/NS_NewXMLDocument

talkback id 17308843. Not quite sure it's the same crash. Similar.

First couple of lines of stack trace:
NS_NewXMLDocument  
[d:\builds\seamonkey\mozilla\content\xml\document\src\nsXMLDocument.cpp, line
208]         
CreateXMLDocument  
[d:\builds\seamonkey\mozilla\content\build\nsContentModule.cpp, line 322]         
nsGenericFactory::CreateInstance  
[d:\builds\seamonkey\mozilla\xpcom\glue\nsGenericFactory.cpp, line 78]         
nsComponentManagerImpl::CreateInstance  
[d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1731]
        
nsComponentManager::CreateInstance  
[d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManagerObsolete.cpp,
line 103]         
nsXBLService::FetchBindingDocument  
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLService.cpp, line 1293]         
nsXBLService::LoadBindingDocumentInfo  
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLService.cpp, line 1143]  

This ocurred on 2/18.

Checked nsXMLDocument.cpp and 2 changes made
on feb 24 and feb 27 but looking at the comments I don't think
they caused crash.

Comment 8

[Jari Ahonen]

I see this crash also on a different machine with WinXP SP1 so it's unlikely
that it's caused by something in my Win2000 SP3 box. However, drWatson on XP
could not do a proper stack trace so maybe the problem is stack corruption.

It could be something in my Mozilla user profile which I copy between these two
machines but I've already deleted and recreated most of the profile files that I
think might be corrupt (xul.mfl, history.dat, registry.dat, pluginreg.dat,
folder.msf files) so I think profile corruption is unlikely to cause this.

I'll wait until 1.3 is released and will use the released version to create a
profile from scratch to rule out profile corruption.

Comment 9

[Jari Ahonen]

Looks like talkback is actually sending something with build 2003030205. Some
talkback IDs of this crash are TB17723777K, TB17748405H and TB17759255X.

Comment 10

[Andrew Hagen]

Stackwanted to determine if those Talkback IDs are for this bug.

Comment 11

[Jari Ahonen]

Recreated user profile from scratch with 1.3 nightly build 20030308.

Just crashed on exiting again but this time stack looks corrupted (drwatson
trace looks meaningless).

Comment 12

[Jari Ahonen]

Still hapens with 1.4a nightly build 2003032708. Talkback ID TB18552007Z is from
the crash that generated this drWatson stack trace. Note that this trace does
not have any of the <nosymbols> lines like all previous ones. Maybe this is the
first one that shows where the problem really might be:
*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012FC64 77FC96CB 00230000 02A21410 0012FCDC 00000000 ntdll!RtlZeroHeap 
0012FD0C 7800115C 00230000 00000000 02A21418 02A21468 ntdll!RtlFreeHeap 
0012FD54 620588C5 02A21418 02A2146C 02A21468 62042349 !free 
0012FD64 62042349 02A21468 6205890C 00000001 00000000
msgbsutl!nsAdapterEnumerator::GetNext  (FPO: [0,0,2])
0012FD6C 6205890C 00000001 00000000 01F36F70 61E00D6D
msgbsutl!nsMsgFolder::operator=  (FPO: [1,0,1])
0012FD7C 61E00D6D 02A21468 61B235D8 00000000 02A238F0
msgbsutl!nsAdapterEnumerator::GetNext  (FPO: [1,0,2])
0012FDA4 61E009C7 02A238F0 02A238F0 61E00795 02A238F0
xpcom!nsCOMPtr_base::assign_with_AddRef  (FPO: [1,0,2])
0012FDB8 61DE9596 00000001 80000000 02A23728 61DE8F17 xpcom!NS_NewGenericFactory
 (FPO: [0,0,3])
0012FDC8 61DE8F17 02A238F0 02A23728 61DE8891 0023C8E0
xpcom!nsIThread::IsMainThread  (FPO: [1,0,2])
0012FDD4 61DE8891 0023C8E0 0023E740 0023C280 00000000
xpcom!nsServiceManager::UnregisterService  (FPO: [0,0,1])
0012FDA4 61E009C7 02A238F0 02A238F0 61E00795 02A238F0
xpcom!nsServiceManager::UnregisterService 
0012FDB8 61DE9596 00000001 80000000 02A23728 61DE8F17 xpcom!NS_NewGenericFactory
 (FPO: [0,0,3])
0012FDC8 61DE8F17 02A238F0 02A23728 61DE8891 0023C8E0
xpcom!nsIThread::IsMainThread  (FPO: [1,0,2])
0012FDD4 61DE8891 0023C8E0 0023E740 0023C280 00000000
xpcom!nsServiceManager::UnregisterService  (FPO: [0,0,1])
0012FDF4 61DE8A0B 00000000 00000000 00000003 61DC78D4
xpcom!nsServiceManager::UnregisterService 
0012FE04 61DC78D4 02A23928 02A23728 0012FE7C 61DD0287
xpcom!nsServiceManager::UnregisterService  (FPO: [3,0,0])
0012FE14 61DD0287 0023E740 0023C280 0000001A 0012FE64
xpcom!nsHashtable::Enumerate  (FPO: [4,0,0])
0012FE48 61DC78B5 0000001B 61DC78C1 0012FE64 00000002 xpcom!PL_DHashTableEnumerate 
0012FE6C 61DE89E0 61DE89E6 0012FE7C 00000000 00000003 xpcom!nsHashtable::Enumerate 
0012FE84 61DE5EF0 0023E710 00000003 0023E1C8 0023E1A0
xpcom!nsServiceManager::UnregisterService 
0012FEA8 61DE32FC 00000000 00000003 80000000 00000000
xpcom!nsCreateInstanceFromCategory::operator() 
0012FEC0 61DC47E6 80000000 00000000 61E04B20 61E033E8
xpcom!nsCreateInstanceFromCategory::operator()  (FPO: [0,0,3])
0012FEF0 00410373 00000000 00401A04 00000000 780419E0 xpcom!NS_ShutdownXPCOM 
0012FEF8 00401A04 00000000 780419E0 00000001 00000000
mozilla!CBufDescriptor::CBufDescriptor  (FPO: [0,0,0])
0012FF14 00402F1D 00000001 00233898 00133413 00410E22 mozilla!nsCString::Length 
0012FF24 00410E22 00400000 00000000 00133413 00000001
mozilla!nsDependentCString::nsDependentCString  (FPO: [4,0,1])
0012FFC0 77EA847C 00000000 00000000 7FFDF000 C0000005
mozilla!nsCString::GetFlatBufferHandle 
0012FFF0 00000000 00410CEE 00000000 000000C8 00000100 kernel32!ProcessIdToSessionId 

Comment 13

[Jari Ahonen]

I'm back on 1.3 due to other instability in 1.4a. Tested if profile switching
triggers the crash to find out if this has something to do with the user profile.

- Created a new user profile.
- Ran Mozilla with my regular profile for about 1/2 day browsing and using IMAP
mail. No problems.
- Did a Tools->Switch profile and changed to the test profile. Worked fine, no
crash and the browser loaded the homepage of the test profile.
- Did a File->Exit and the result was a crash. Stack looks somewhat corrupted
again. Talkback ID TB18640405Z.

Comment 14

[Jari Ahonen]

Changed summary.

Bug 200541 is likely a duplicate of this one, at least it looks very simlar to me.
Bug 201230 seems similar as well.

Comment 15

[Jari Ahonen]

Attachment: Yet another drWatson stack trace

Attached a recent stack trace of build 2003042708 crashing.

The common thing I see in the various drWatson traces is the lines
msgbsutl!nsAdapterEnumerator::GetNext
msgbsutl!nsMsgFolder::operator=
msgbsutl!nsAdapterEnumerator::GetNext

The rest of the stack trace seems to vary a lot even though I always tend to
close the browser in the same way.

Comment 16

[Jari Ahonen]

Changed from Win2000 to XP. Now most of the drwatson stack traces are really
meaningless, usually there is only the raw stack dump or only one or two
functions in the trace.

Bug 200541 is almost certainly the same thing, I've seen a couple of traces like
in that bug as well.

This crash happens most of the time when I close Mozilla. I'm not sure but I
have a feeling that moving lots of messages between IMAP folders is the thing
that triggers this.

Comment 17

[Jari Ahonen]

Still happening with 1.5b (build 2003082704).

Last sent talkback ID is TB23159040X.

Comment 18

[David :Bienvenu]

confirming - I'll try to get some info from talkback.

Comment 19

[Adam Hauner]

TB23159040X is empty.

Comment 20

[Jari Ahonen]

I have sent more. Most recent ones are TB23228584G and TB23159496G. I have
written "bug 193998" in the comments field of most talkbacks I have sent so
maybe you can search with that.

Comment 21

[Jari Ahonen]

I have sent TB23288607X and TB2328934M today. For those I also have drWatson
traces if they also happen to be empty. However, it does not look very good as
in the drWatson stack trace the first crash looks like complete stack corruption
and the second one only has this:

*----> Stack Back Trace <----*
WARNING: Stack unwind information not available. Following frames may be wrong.
ChildEBP RetAddr  Args to Child              
0012fff4 00411534 00000000 78746341 00000020 0x0
00000000 00000000 00000000 00000000 00000000 mozilla!nsString__Length+0x269

Comment 22

[Adam Hauner]

In Crash Analysis one crash with comment "Bug 193998" has this stack:

0x00000000
nsConflictSet::FreeBindingEntry
[c:/builds/seamonkey/mozilla/content/xul/templates/src/nsConflictSet.h line 405]
PL_HashTableDestroy [c:/builds/seamonkey/mozilla/nsprpub/lib/ds/plhash.c line 172]
nsConflictSet::Destroy
[c:/builds/seamonkey/mozilla/content/xul/templates/src/nsConflictSet.cpp line 117]
nsConflictSet::~nsConflictSet
[c:/builds/seamonkey/mozilla/content/xul/templates/src/nsConflictSet.h]
nsXULTemplateBuilder::~nsXULTemplateBuilder
[c:/builds/seamonkey/mozilla/content/xul/templates/src/nsXULTemplateBuilder.cpp]
nsXULContentBuilder::`scalar deleting destructor'
nsXULTemplateBuilder::Release
[c:/builds/seamonkey/mozilla/content/xul/templates/src/nsXULTemplateBuilder.cpp
line 209]
nsSupportsHashtable::ReleaseElement
[c:/builds/seamonkey/mozilla/xpcom/ds/nsHashtable.cpp line 797]
hashEnumerate [c:/builds/seamonkey/mozilla/xpcom/ds/nsHashtable.cpp line 121]
PL_DHashTableEnumerate [c:/builds/seamonkey/mozilla/xpcom/ds/pldhash.c line 620]
0x00080005
0x00e00000 

Comment 23

[David :Bienvenu]

What theme are you using? Does this happen with a new profile?

Cc'ing Brendan since he knows what things might be null and what things won't be
null in a PLDHash destroy callback like the back of his hand :-) From the
talkback stack, it looks like aPool might be null, which doesn't seem likely.

400     static void PR_CALLBACK FreeBindingEntry(void* aPool, PLHashEntry*
aHashEntry, PRUintn aFlag) {
401         if (aFlag == HT_FREE_ENTRY) {
402             nsIRDFResource* key = NS_STATIC_CAST(nsIRDFResource*,
NS_CONST_CAST(void*, aHashEntry->key));
403             NS_RELEASE(key);
404             nsFixedSizeAllocator* pool =
NS_STATIC_CAST(nsFixedSizeAllocator*, aPool);
405             BindingEntry::Destroy(*pool, NS_REINTERPRET_CAST(BindingEntry*,
aHashEntry));
406         } }

Comment 24

[Jari Ahonen]

Using the Modern theme. I have re-created the profile from scratch in the past
and this error persists. I only see the crash after using MailNews for a while,
i.e. if I just start it up and view a few messages Mozilla does not ususally
crash but after a couple of hours running the crash happens most of the time.
Always crashes  when Mozilla is exiting (Closing the last window or selecting
File->Exit), I don't usually see crashes during normal use.

Comment 25

[Brendan Eich [:brendan]]

bienvenu: this is plhash.c, not pldhash.c.  Looks like heap corruption.  Someone
find a reproducible test case, use purify or valgrind.

/be

Comment 26

[David :Bienvenu]

d'oh! I guess I need to go look at plhash.c - it could be heap corruption, but
the 0x00000000 value is suspicous.

Comment 27

[Brendan Eich [:brendan]]

Something jumped thru null, or the stack-saved return pc was null'ed.  Cc'ing
dbaron in case he has an idea.

/be

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stacks for talkback ids mentioned in comment 20 and comment 21

I didn't get the last one because the talkback server stopped responding while
I was looking them up.

Comment 29

[David :Bienvenu]

the crashes in nsRDFResource::~nsRDFResource() look like crashes freeing mURI,
which would imply either some sort of mem corruption or a double free. I've
never seen this crash myself. 

Jari, do you start up with just the browser, and then launch mailnews? Is
QuickLaunch enabled? In the distant past, problems like this have been related
to shut-down order but I don't see how that could be in this case. Oh, 

Comment 30

[Jari Ahonen]

I usually start with the browser and then start mailnews with ctrl-2. When
closing I usually close MailNews and then the browser. But not always like this
and at least the closing order does not seem to make a differece. Quicklaunch is
not enabled (In fact I think this crash might not occur with QL since I can
change profile without crashing, it only crashes when Mozilla exits for good).

Comment 31

[Jari Ahonen]

Just in case it makes any difference, TB23349619Z is a crash where the browser
window was closed first and MailNews last.

Comment 32

[timeless]

there's another bug about the rdf crash. i might xref it later.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack from talkback id in comment 31

Comment 34

[David :Bienvenu]

I have no idea how to reproduce this. Does anyone see this after only use mail
for a few minutes? Or does everyone who sees this run for several hours before
seeing it?

Comment 35

[Adam Hauner]

Bug 155192 had same signature.

Comment 36

[David :Bienvenu]

I suppose it's possible that the fix for Bug 155192 will fix this - anyone who
sees this regularly, if you try a 1.6 build from 09/11 or later, let us know if
you still see this crash. thx.

Comment 37

[Jari Ahonen]

David,

I don't have to run for a really long time to get the crash. I still haven't
foind any truly reproducible way to get the crash but it seems more likely the
more mesasges you deal with in MailNews. If I download a few hundred messages
from IMAP and filter them into different folders, this usually does it. But not
always.

I will give a recent 1.6a a go to see if I still see this crash.

Comment 38

[Jari Ahonen]

1.6a build 2003091510 crashes as well. TB23633527Z.

This crash happened as follows:
- Start Mozilla
- Start MailNews and open IMAP account.
- Go into folder where there are about 700 unread messages.
- Use find (shift-ctrl-F) to filter some messages into another imap folder and
delete some others.
- Compact the folder, go into another folder, do shift-ctrl-C on that folder and
compact it as well.
- Close MailNews
- Close browser. This resulted the crash.

Comment 39

[David :Bienvenu]

thx, I see the crash with those steps. I think this is an rdf or a xul template
builder problem, actually, but I'll see what I can figure out.

Comment 40

[David :Bienvenu]

this looks to be a ref-counting problem with the folder resource. When we
destroy the mClusters hash table, the folder resource is freed. But, the
mBindingDependencies hash table also has a reference to the folder resource, and
at this point, it's dangling. The XULTemplateBuilder code looks OK in terms of
its ref-counting, so my guess is that the problem is caused by a ref-counting
problem in one of the operations (either the msg delete or the msg move). I'll
try to narrow it down. It could also be a problem in the search view.

    [E] FMR: Free memory read in nsConflictSet::FreeBindingEntry(void
*,PLHashEntry *,UINT) {1 occurrence}
        Reading 4 bytes from 0x165eed78 (4 bytes at 0x165eed78 illegal)
        Address 0x165eed78 is at the beginning of a 280 byte block
        Address 0x165eed78 points to a C++ new block in heap 0x02440000
        Thread ID: 0x310
        Error location
        nsConflictSet::FreeBindingEntry(void *,PLHashEntry *,UINT)
[nsConflictSet.h:403]
            static void PR_CALLBACK FreeBindingEntry(void* aPool, PLHashEntry*
aHashEntry, PRUintn aFlag) {
                if (aFlag == HT_FREE_ENTRY) {
                    nsIRDFResource* key = NS_STATIC_CAST(nsIRDFResource*,
NS_CONST_CAST(void*, aHashEntry->key));
     =>             NS_RELEASE(key);
                    nsFixedSizeAllocator* pool =
NS_STATIC_CAST(nsFixedSizeAllocator*, aPool);
                    BindingEntry::Destroy(*pool,
NS_REINTERPRET_CAST(BindingEntry*, aHashEntry));
                } }
        PL_HashTableDestroy [plhash.c:166]
        nsConflictSet::Destroy(void) [nsConflictSet.cpp:116]
        {
            PL_HashTableDestroy(mSupport);
            PL_HashTableDestroy(mClusters);
     =>     PL_HashTableDestroy(mBindingDependencies);
            return NS_OK;
        }
        
        nsConflictSet::~nsConflictSet(void) [nsConflictSet.h:136]
        nsXULTemplateBuilder::~nsXULTemplateBuilder(void)
[nsXULTemplateBuilder.cpp:169]
        nsXULContentBuilder::~nsXULContentBuilder(void)
[nsXULContentBuilder.cpp:339]
        nsXULContentBuilder::`vector deleting destructor'(UINT) [gklayout.dll]
        nsXULTemplateBuilder::Release(void) [nsXULTemplateBuilder.cpp:209]
        nsSupportsHashtable::ReleaseElement(nsHashKey *,void *,void *)
[nsHashtable.cpp:796]
        hashEnumerate  [nsHashtable.cpp:115]
        Allocation location
        new(UINT)      [new.cpp:23]
        nsMsgLocalMailFolderConstructor [nsMsgLocalFactory.cpp:73]
        NS_GENERIC_FACTORY_CONSTRUCTOR(nsMovemailService)
        #endif /* HAVE_MOVEMAIL */
        NS_GENERIC_FACTORY_CONSTRUCTOR(nsNoneService)
     => NS_GENERIC_FACTORY_CONSTRUCTOR(nsMsgLocalMailFolder)
        NS_GENERIC_FACTORY_CONSTRUCTOR(nsParseMailMessageState)
        NS_GENERIC_FACTORY_CONSTRUCTOR(nsPop3IncomingServer)
        #ifdef HAVE_MOVEMAIL
        nsGenericFactory::CreateInstance(nsISupports *,nsID const&,void * *)
[nsGenericFactory.cpp:86]
        RDFServiceImpl::GetResource(nsACString const&,nsIRDFResource * *)
[nsRDFService.cpp:1095]
        nsMsgLocalMailFolder::AddSubfolder(nsAutoString *,nsIMsgFolder * *)
[nsLocalMailFolder.cpp:296]
        nsMsgLocalMailFolder::CreateSubFolders(nsFileSpec&)
[nsLocalMailFolder.cpp:231]
        nsMsgLocalMailFolder::GetSubFolders(nsIEnumerator * *)
[nsLocalMailFolder.cpp:526]
        nsMsgFolderDataSource::createFolderOpenNode(nsIMsgFolder *,nsIRDFNode *
*) [nsMsgFolderDataSource.cpp:1386]
        nsMsgFolderDataSource::createFolderNode(nsIMsgFolder *,nsIRDFResource
*,nsIRDFNode * *) [nsMsgFolderDataSource.cpp:1002]
        nsMsgFolderDataSource::GetTarget(nsIRDFResource *,nsIRDFResource
*,int,nsIRDFNode * *) [nsMsgFolderDataSource.cpp:379]
        GetTargetHasAssertion(nsIRDFDataSource *,nsIRDFResource *,nsIRDFResource
*,int,nsIRDFNode *,int *) [nsMsgRDFUtils.cpp:99]
        nsMsgFolderDataSource::DoFolderHasAssertion(nsIMsgFolder
*,nsIRDFResource *,nsIRDFNode *,int,int *) [nsMsgFolderDataSource.cpp:2220]
        nsMsgFolderDataSource::HasAssertion(nsIRDFResource *,nsIRDFResource
*,nsIRDFNode *,int,int *) [nsMsgFolderDataSource.cpp:537]
        nsXULTreeBuilder::IsContainerOpen(nsIRDFResource *,int *)
[nsXULTreeBuilder.cpp:1838]
        nsXULTreeBuilder::OpenSubtreeOf(Subtree::nsTreeRows *,int,nsIRDFResource
*,int *) [nsXULTreeBuilder.cpp:1672]
        nsXULTreeBuilder::OpenContainer(int,nsIRDFResource *)
[nsXULTreeBuilder.cpp:1560]
        nsXULTreeBuilder::RebuildAll(void) [nsXULTreeBuilder.cpp:1383]
        nsXULTemplateBuilder::Rebuild(void) [nsXULTemplateBuilder.cpp:238]
        Free location
        delete(void *) [delop.cpp:6]
        nsMsgLocalMailFolder::`vector deleting destructor'(UINT) [msglocal.dll]
        nsRDFResource::Release(void) [nsRDFResource.cpp:89]
        nsMsgDBFolder::Release(void) [nsMsgDBFolder.cpp:127]
        nsMsgLocalMailFolder::Release(void) [nsLocalMailFolder.cpp:157]
        Value::Clear(void) [nsRuleNetwork.cpp:275]
                break;
        
            case eISupports:
                 =>         NS_IF_RELEASE(mISupports);
                            break;
                    
                        case eString:
                Value::~Value(void) [nsRuleNetwork.cpp:262]
                nsClusterKey::~nsClusterKey(void) [nsClusterKey.h:95]
                nsConflictSet::ClusterEntry::~ClusterEntry(void)
[nsConflictSet.h:239]
                    
                        public:
                            ClusterEntry() {
MOZ_COUNT_CTOR(nsConflictSet::ClusterEntry); }
                 =>         ~ClusterEntry() {
MOZ_COUNT_DTOR(nsConflictSet::ClusterEntry); }
                    
                            static ClusterEntry*
                            Create(nsFixedSizeAllocator& aPool) {
                nsConflictSet::ClusterEntry::`scalar deleting destructor'(UINT)
[gklayout.dll]
               
nsConflictSet::ClusterEntry::Destroy(nsFixedSizeAllocator&,ClusterEntry::nsConflictSet
*) [nsConflictSet.h:248]
                nsConflictSet::FreeClusterEntry(void *,PLHashEntry *,UINT)
[nsConflictSet.h:277]
                PL_HashTableDestroy [plhash.c:166]
                nsConflictSet::Destroy(void) [nsConflictSet.cpp:115]
                    nsConflictSet::Destroy()
                    {
                        PL_HashTableDestroy(mSupport);
                 =>     PL_HashTableDestroy(mClusters);
                        PL_HashTableDestroy(mBindingDependencies);
                        return NS_OK;
                    }
                nsConflictSet::~nsConflictSet(void) [nsConflictSet.h:136]
                nsXULTemplateBuilder::~nsXULTemplateBuilder(void)
[nsXULTemplateBuilder.cpp:169]
                nsXULContentBuilder::~nsXULContentBuilder(void)
[nsXULContentBuilder.cpp:339]
                nsXULContentBuilder::`vector deleting destructor'(UINT)
[gklayout.dll]
    [E] IPR: Invalid pointer read in nsConflictSet::FreeBindingEntry(void
*,PLHashEntry *,UINT) {1 occurrence}
    [E] EXU: Unhandled exception in nsConflictSet::FreeBindingEntry(void
*,PLHashEntry *,UINT) {1 occurrence}

Comment 41

[David :Bienvenu]

Attachment: proposed fix

found problem in search view - it was using getter_AddRefs to assign a raw ptr
to a comptr, producing a ref underflow. This patch fixes the problem. This was
a long standing problem, and I believe an occasional top-crasher.

Comment 42

[David :Bienvenu]

Comment on attachment 137705 [details] [diff] [review]
proposed fix

the first couple changes are just formatting changes - it's the last change
that fixes the problem.

Comment 43

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Geeeez, I have just created a new message filter and k-boom.... I tried it
again, k-boom again. Should be blocking 1.6 imho.

Comment 44

[David :Bienvenu]

Daniel, not sure how that's related to this. Did you see the same stack trace or
something?

Comment 45

[David :Bienvenu]

fix checked into the trunk. I agree that this should be fixed in 1.6final, since
it's such a trivial fix for such a long-standing crasher. But I don't think it
has anything to do with message filters.

Comment 46

[chris hofmann]

yeah, looks like a good one to pich up.

Comment 47

[David :Bienvenu]

fix checked in, r/a=sspitzer, on 1.6 branch.

Comment 48

[Jari Ahonen]

Looks like the fix works. Have now been running 20031220 build for a day without
crashing once. Will let you know if I crash again.

Comment 49

[David :Bienvenu]

Comment on attachment 137705 [details] [diff] [review]
proposed fix

this fixes a long standing crasher, and is a simple ref-counting fix.

Comment 50

[Mike Kaply [:mkaply]]

Comment on attachment 137705 [details] [diff] [review]
proposed fix

a=mkaply for 1.4.2 - please mark fixed1.4.2 when it is in.

Thanks!