65838 - M09 & Trunk crashes [@ morkRowObject::CloseRowObject]

Status: VERIFIED FIXED

(MailNews Core :: Database, defect, P1)

Description

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

I'm filing this as a separate bug since it seems, from comments on bug 56643,
that bug 56643 is fixed but there are additional places that need to be fixed.

This crash is currently the #8 crash in the current trunk talkback data.
See ftp://ftp.mozilla.org/pub/data/crash-data/

The common stack is:

morkRowObject::CloseRowObject
[d:\builds\seamonkey\mozilla\db\mork\src\morkRowObject.cpp line 110]
morkRowObject::CloseMorkNode
[d:\builds\seamonkey\mozilla\db\mork\src\morkRowObject.cpp line 63]
morkNode::cut_use_count [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp
line 535]
morkNode::CutStrongRef [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp
line 552]
morkNode::SlotStrongNode [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp
line 447]
morkHandle::CloseHandle [d:\builds\seamonkey\mozilla\db\mork\src\morkHandle.cpp
line 122]
morkHandle::CloseMorkNode
[d:\builds\seamonkey\mozilla\db\mork\src\morkHandle.cpp line 59]
morkNode::cut_use_count [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp
line 535]
morkNode::CutStrongRef [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp
line 552]
morkHandle::Handle_CutStrongRef
[d:\builds\seamonkey\mozilla\db\mork\src\morkHandle.cpp line 395]
orkinRow::CutStrongRef [d:\builds\seamonkey\mozilla\db\mork\src\orkinRow.cpp
line 267]
nsMsgHdr::~nsMsgHdr
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgHdr.cpp line 134]
nsMsgHdr::`scalar deleting destructor'

Comment 1

[David :Bienvenu]

accepting - will need a reproducible case, however. I think this may be getting
worse because xul documents are leaking horribly, which keeps these msg headers
around much longer than they should.

Comment 2

[David :Bienvenu]

*** Bug 66002 has been marked as a duplicate of this bug. ***

Comment 3

[scottputterman]

dbaron or jpatel do you have the list of talkback reports that show this is a
top crasher on the trunk?  I did a query and it looks like all of the stacks are
coming up on Netscape 6.  The link provided in this bug report doesn't seem to
point to the data I'm looking for.

Comment 4

[Jay Patel [:jay]]

Talkback wasn't enabled in the Trunk builds for a while due to server 
problems...but Talkback should be in the latest builds since mid last week.  We 
just don't have any data right now from the newest builds (and older data is 
gone).  I did check my older reports and here is what I saw:

Jan 26 - 3 crashes out of 528 (#32 rank).  This is all the data I had in that 
report:

morkRowObject::CloseRowObject   3        56643   VERI    FIXE 
     First BBID :24860742
     Last BBID  :24927787
     Min Runtime :1975
     Max Runtime :13749
     First Appearance Date : 2001-01-18
     Last Appearance Date : 2001-01-19

Stack Trace: 

         morkRowObject::CloseRowObject  
[d:\builds\seamonkey\mozilla\db\mork\src\morkRowObject.cpp  line 110] 
         morkRowObject::CloseMorkNode   
[d:\builds\seamonkey\mozilla\db\mork\src\morkRowObject.cpp  line 63] 
         morkNode::cut_use_count        
[d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp  line 535] 
         morkNode::CutStrongRef 
[d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp  line 552] 
         morkNode::SlotStrongNode       
[d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp  line 447] 
         morkHandle::CloseHandle        
[d:\builds\seamonkey\mozilla\db\mork\src\morkHandle.cpp  line 122] 
         morkHandle::CloseMorkNode      
[d:\builds\seamonkey\mozilla\db\mork\src\morkHandle.cpp  line 59] 
         morkNode::cut_use_count        
[d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp  line 535] 
         morkNode::CutStrongRef 
[d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp  line 552] 
         morkHandle::Handle_CutStrongRef        
[d:\builds\seamonkey\mozilla\db\mork\src\morkHandle.cpp  line 395] 
         orkinRow::CutStrongRef 
[d:\builds\seamonkey\mozilla\db\mork\src\orkinRow.cpp  line 267] 
         nsMsgHdr::~nsMsgHdr    
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgHdr.cpp  line 134] 
         nsMsgHdr::`scalar deleting destructor'  
         nsDBFolderInfo::Release        
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsDBFolderInfo.cpp  line 80] 
         nsCOMPtr_base::assign_with_AddRef      
[d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp  line 59] 
         nsMsgLocalMailFolder::CreateMessageFromMsgDBHdr        
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsLocalMailFolder.cpp  line 
2134] 
         nsMessageFromMsgHdrEnumerator::GetNext 
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgUtils.cpp  line 181] 
         nsMessageViewMessageEnumerator::SetAtNextItem  
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMessageView.cpp  line 291] 
         nsMessageViewMessageEnumerator::HasMoreElements        
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMessageView.cpp  line 272] 
         CompositeEnumeratorImpl::HasMoreElements       
[d:\builds\seamonkey\mozilla\rdf\base\src\nsCompositeDataSource.cpp  line 239] 
         RDFContainerMemberTestNode::FilterInstantiations       
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp  line 
3560] 
         TestNode::Propogate    
[d:\builds\seamonkey\mozilla\rdf\content\src\nsRuleNetwork.cpp  line 871] 
         TestNode::Propogate    
[d:\builds\seamonkey\mozilla\rdf\content\src\nsRuleNetwork.cpp  line 879] 
         RootNode::Propogate    
[d:\builds\seamonkey\mozilla\rdf\content\src\nsRuleNetwork.cpp  line 597] 
         nsXULTemplateBuilder::CreateContainerContents  
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp  line 
6257] 
         nsXULTemplateBuilder::CreateTemplateAndContainerContents       
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp  line 
6179] 
         nsXULTemplateBuilder::RebuildContainerInternal 
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp  line 
4507] 
         nsXULTemplateBuilder::RebuildContainer 
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp  line 
4464] 
         nsXULDocument::RebuildWidgetItem       
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp  line 4430] 
         nsXULDocument::AttributeChanged        
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp  line 1670] 
         nsXULElement::SetAttribute     
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp  line 2907] 
         nsXULElement::SetAttribute     
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp  line 1310] 
         nsXULTreeElement::SetAttribute 
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTreeElement.h  line 54] 
         ElementSetAttribute    
[d:\builds\seamonkey\mozilla\dom\src\coreDOM\nsJSElement.cpp  line 250] 
         js_Invoke      [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
786] 
         js_Interpret   [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
2608] 
         js_Invoke      [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
802] 
         nsXPCWrappedJSClass::CallMethod        
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp  line 
820] 
         nsXPCWrappedJS::CallMethod     
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp  line 379] 
         PrepareAndDispatch     
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp  
line 102] 
         SharedStub     
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp  
line 124] 
         nsMsgMailSession::OnItemEvent  
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgMailSession.cpp  line 299] 
         nsMsgFolder::NotifyFolderEvent 
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgFolder.cpp  line 2372] 
         nsMsgLocalMailFolder::GetDatabase      
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsLocalMailFolder.cpp  line 816] 
         nsMsgLocalMailFolder::UpdateFolder     
[d:\builds\seamonkey\mozilla\mailnews\local\src\nsLocalMailFolder.cpp  line 831] 
         XPTC_InvokeByIndex     
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp  
line 139] 
         nsXPCWrappedNativeClass::CallWrappedMethod     
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativeclass.cpp  
line 923] 
         WrappedNative_CallMethod       
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp  
line 223] 
         js_Invoke      [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
786] 
         js_Interpret   [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
2608] 
         js_Invoke      [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
802] 
         js_InternalInvoke      [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  
line 874] 
         JS_CallFunctionValue   [d:\builds\seamonkey\mozilla\js\src\jsapi.c  
line 3266] 
         nsJSContext::CallEventHandler  
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp  line 934] 
         nsJSEventListener::HandleEvent 
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp  line 155] 
         nsEventListenerManager::HandleEventSubType     
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp  line 
840] 
         nsEventListenerManager::HandleEvent    
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp  line 
1351] 
         nsXULElement::HandleDOMEvent   
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp  line 3455] 
         nsXULTreeElement::FireOnSelectHandler  
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTreeElement.cpp  line 455] 
         nsXULTreeElement::SetSuppressOnSelect  
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTreeElement.cpp  line 152] 
         nsXULTreeElement::SelectItem   
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTreeElement.cpp  line 187] 
         XULTreeElementSelectItem       
[d:\builds\seamonkey\mozilla\rdf\content\src\nsJSXULTreeElement.cpp  line 273] 
         js_Invoke      [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
786] 
         js_Interpret   [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
2608] 
 
        Source File : 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/db/mork/src/morkRowObject.cp
p line : 110


Then the crash wasn't in the Jan 27 report.  It seems as if the last reported 
crash occurred on Jan 19th. This could either have been fixed or people 
continued to crash with newer builds, but since talkback was not enabled, 
we don't know about those crashes.  We'll have to wait to see if this crash is 
still in the newest Trunk builds that have Talkback enabled.

Comment 5

[scottputterman]

moving to mozilla0.9 for the moment to see if it's still a top crasher.

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 68704 has been marked as a duplicate of this bug. ***

Comment 7

[Håkan Waara]

uhh.. two duplicates and you are setting the 'mostfreq' keyword? also, is this
really a topcrash!? it's been there for quite a while but not much activity..

Comment 8

[Mack Earnhardt]

I'm attaching a news msf that will cause this crash on unsubscribe. It has a
problem that I can't duplicate reliably but the symptom is that the unread count
when viewing threaded doesn't match the read/unread flag on the messages. It
will be higher. For example, a thread with 2 messages can show 2 unread even
though both messages are flagged as read. If you then flag them both unread the
thread info shows unread 4 total 2.  If you unsubscribe from the newsgroup in
this state, you crash.  btw, I'm on a custom build of mozilla0.8 branch.

Comment 9

[Mack Earnhardt]

Attachment: News msf that causes crash

Comment 10

[Mack Earnhardt]

Attachment: rc file to go with msf

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

Haakan - I set it to mostfreq for the following: I reproduced this bug in about
5 minutes of my checking out the report against it.  I suspect others are
crashing in news here, and either just aren't reporting it or don't have a stack
trace to correctly identify this bug.  If you feel I'm in error, then go ahead
and remove the keyword.  And Jay would know whether it's a top crash or not.

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

------- Additional Comments From Seth Spitzer 2001-02-13 13:12 -------

I've seen this before. I think it was caused by a corrupt .msf file. look at
your .msf files, and look for non ascii data. it is possible to corrupt .msf
files by using two instances of mozilla (or a mozilla based application, like
Netscape 6) at the same time. I might be able to bulletproof to prevent crash
upon corruption, and perhaps get fancy and remove corrupt .msf files if I can
tell they are corrupt.

Comment 13

[Jay Patel [:jay]]

This is currently around #20 on the Trunk topcrash list. The stack looks the 
same, and here are a couple of URLs and user comments in case anyone needs to 
repro:
         URL: http://derstandard.at
         URL: http://sites.netscape.net/ekrockhome/answers.html
        Comment:  when subscribing to borland.public.jbuilder.opentools and 
downloading all new headers mozilla crashed after downloading the 1140th header 
of 1165.
        Comment:  unsubscribing from a newsgroup using right-click 

Comment 14

[Mack Earnhardt]

Please disregard the files I posted and pardon me for jumping to conclutions.
It's not necessary to have an inconsistent msf like I posted to duplicate this
crash. I'm getting a MORK crash on exit after _any_ unsubscribe.

Comment 15

[Håkan Waara]

Mozilla.org's description of the mostfreq keyword:

"This is for bugs which tend to have a lot of duplicates written up in the
Bugzilla database."

Comment 16

[Gervase Markham [:gerv]]

Removing mostfreq. This may be frequently encountered but unless there's a 
succinct summary of what actions always cause the crash (to reduce the number of 
dupes filed) then adding "crashes [@ morkRowObject::CloseRowObject]" to the 
mostfreq page won't help anyone.

Gerv

Comment 17

[scottputterman]

Stephen, can you try to reproduce this?  There are a lot of talk back reports on
this.  It's also happening in Local Mail according to some of the stack traces.

There's a possibility this could disappear in the thread pane rewrite because
our messages will no longer be held onto by the content model. 

Comment 18

[[e-mail] (gone - use [e-mail] instead)]

I reproduced this on the 13th of this month (see my comments near Hwaara's). 
But I'll try this again...

Comment 19

[David :Bienvenu]

the thread pane rewrite should fix this, as you say, Scott. The view does cache
a single header, so I'll have to remember to clear that cache.

Comment 20

[scottputterman]

OK, so as long as we know that we've been able to reproduce this in the past
then it's probably safe to wait until the rewrite happens and then test that to
make sure it's not happening.

Comment 21

[scottputterman]

sorry for the extra email, but I want to keep this on the nsbeta1 radar.

Comment 22

[Håkan Waara]

*** Bug 69733 has been marked as a duplicate of this bug. ***

Comment 23

[David :Bienvenu]

changing summary - I did add code to the view to clear the single header cache.

Comment 24

[Jay Patel [:jay]]

This is a topcrasher for Mozilla0.8 on Win32 and Linux.  Adding M08 to summary
for tracking.

Comment 25

[Jay Patel [:jay]]

sorry, this only appears on win32...not linux.

Comment 26

[[e-mail] (gone - use [e-mail] instead)]

I just queried the Talkback server, and this crash hasn't occured in 6.5 for the
last 25 crashes or so (all the crashes were in 6.01 and 6.0.)

Comment 27

[David :Bienvenu]

landing the performance branch should make this go away.

Comment 28

[[e-mail] (gone - use [e-mail] instead)]

I just searched Talkback, and found that the only current seamonkey builds 
(marked with 6/6.50 in their User-Agent string) were as follows:

Netscape6.50    mozilla.exe 0.0.0.0 
Netscape Win32 (2001021510) 

This is before the outliner branch landed, so I'm confident that if the 
Talkback data is correct, this is VERIFIED.

Comment 29

[scottputterman]

I'm reopening the bug.  If you think this is a different scenario I can open a
new one.  According to Talkback, there have been 26 crashes between the 4/23 and
5/1 builds.  Here's the current comments and stack:

 (29829645)	Comments: In mail.  Selected the trash can (right click) and then chose to emply
trash.  That is when it crashes.
     (29715608)	Comments: mailnews: moving and renaming folders
     (29704949)	Comments: compacting mailboxes takes *way* too long -- or at least it never
finishes....
     (29703896)	Comments: unsubscribing.
     (29681952)	URL: http://www.rpgnews.com
     (29681952)	Comments: I was browsing the above in the background when I tried to empty
my trash in Mail.
     (29546313)	Comments: I emptied the trash can

morkRowObject::CloseRowObject

morkRowObject::CloseMorkNode

morkNode::cut_use_count

morkNode::CutStrongRef

morkNode::SlotStrongNode

morkHandle::CloseHandle

morkHandle::CloseMorkNode

morkNode::cut_use_count

morkNode::CutStrongRef

morkHandle::Handle_CutStrongRef

orkinRow::CutStrongRef

nsMsgHdr::~nsMsgHdr

nsMsgHdr::Release

nsCOMPtr_base::~nsCOMPtr_base

nsMsgDBView::~nsMsgDBView
	 nsMsgWatchedThreadsWithUnreadDBView::`scalar deleting destructor'
nsMsgDBView::Release
nsXPCWrappedNative::~nsXPCWrappedNative

Comment 30

[David :Bienvenu]

I checked in some more fixes for this recently. I guess we'll just have to see
if Talkback shows this crash with new builds.

Comment 31

[Jay Patel [:jay]]

I was going to update this bug, but I found another bug that seemed more
appropriate for the latest crashes under this stack signature.  If this
particular crash was fixed, maybe the latest Talkback data reflects a new crash.
 The other bug that I updated recently is bug 77113.  Can someone look at that
bug and see if it's a dup of this one or a new problem?

Comment 32

[David :Bienvenu]

Attachment: fix hdr leak

Comment 33

[David :Bienvenu]

attached patch for review - we were leaking message headers again (a recent bug
introduced about a week ago, I think) which will make this crash much more likely.

Comment 34

[Navin Gupta]

r=naving. 

Comment 35

[David :Bienvenu]

I checked in the hdr leak fix. I guess we'll just have to watch the talkback
logs for builds from yesterday on.

Comment 36

[scottputterman]

The good news is that so far the last build date that mork.dll or this this
function caused a crash according to Talkback was 5/5

Comment 37

[scottputterman]

I'm going to mark this fixed.  The 5/5 build is still the last build according
to talkback.

Comment 38

[Jay Patel [:jay]]

This crash might have been fixed on the Trunk, but it is still a topcrasher for 
Mozilla 0.9.  Here is a quick summary of this crash with M09 builds:

morkRowObject::CloseRowObject   13
                         77113   NEW             [e-mail]   ---
                         65838   REOP            [e-mail]   
mozilla0.9.1
     First BBID : 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=30171468
     Last BBID  : 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=30196648
     Min Runtime :425
     Max Runtime :30434
     Min seconds since last crash :36
     Max seconds since last crash :30434
     First Appearance Date : 2001-05-08
     Last Appearance Date : 2001-05-09
     First Build ID : 2001050518
     Latest Build ID : 2001050518

Reopening it for now so we know that this crash is still alive with M09 build 
2001050518.  If this was fixed on the Trunk on 5/8, it didn't make it into the 
M09 build.

Comment 39

[Jay Patel [:jay]]

*** Bug 77113 has been marked as a duplicate of this bug. ***

Comment 40

[scottputterman]

I guess I don't really care about 0.9 crashes we think we fixed so removing
nsbeta1 markings and target milestone.

Comment 41

[David :Bienvenu]

I don't understand, jpatel - we can't mark a bug fixed if it's not fixed in .9?
Please let me know what I need to do to get this mark fixed. If I wait for a
week to make sure it's still not in the trunk top crashers, is that sufficient?
Or should I take m09 out of the summary, and then mark it fixed?

Comment 42

[Jay Patel [:jay]]

bienbenu, i don't really know what to do in this situation either.  i didn't 
want to open a new bug just for the M09 crash, since that bug would have been 
marked a dup of this one.  chofmann, should we just mark this bug fixed?   is 
mozilla 0.9.1 going to come from the 0.9 branch or from a new branch off the 
trunk?

Comment 43

[chris hofmann]

mark this fixed.
0.9.1 will come from a new branch made off the trunk just after 5/22.

Comment 44

[David :Bienvenu]

marking fixed - if we have new leaks, it will come back to life, unfortunately.

Comment 45

[Jay Patel [:jay]]

Ok, thanks for clearing that up for me.  Verified Fixed based on the latest 
TRUNK Talkback data.  This crash last appeared with build 2001050518.  

Since this particular crash is still occuring in the M09 branch, adding tracking 
bug 80378 to the dependency tree.