123677 - Crash in [@morkNode::CutWeakRef] trying to access mcom.beta.feedback.browser

Status: VERIFIED DUPLICATE of bug 105497

(MailNews Core :: Networking: NNTP, defect)

Description

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

Build ID: 2002-02-04-09, Windows 2000.

Summary: Crash in [morkNode::CutWeakRef] trying to access mcom.beta.feedback.browser

Steps to Reproduce: While trying to reproduce bug 87164 (progress intermittent
downloading large numbers of headers), I crashed consistently on startup trying
to access this newsgroup.

1.  Add news://news.netscape.com/mcom.beta.feedback.browser
2.  I crashed around 100,000+ headers, total for this group currently is 102,280.
3.  Upon relaunch, I tried to access this newsgroup again and get this crash:


Stack Signature  0x002f02e1 7dfb697a
Trigger Time 2002-02-05 14:53:23
Email Address [e-mail]
URL visited news://news.netscape.com/mcom.beta.feedback.browser
User Comments Crash on startup, accessing the 'mcom.beta.feedback.browser'
newsgroup on news.netscape.com
Build ID 2002020411
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Privileged instruction
Stack Trace
0x002f02e1
morkNode::CutWeakRef [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp, line
649]
morkNode::SlotWeakNode [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp,
line 506]
morkTable::CloseTable [d:\builds\seamonkey\mozilla\db\mork\src\morkTable.cpp,
line 200]
morkTable::CloseMorkNode [d:\builds\seamonkey\mozilla\db\mork\src\morkTable.cpp,
line 107]
morkTable::~morkTable [d:\builds\seamonkey\mozilla\db\mork\src\morkTable.cpp,
line 115]
morkTable::`scalar deleting destructor'
morkObject::Release [d:\builds\seamonkey\mozilla\db\mork\src\morkObject.cpp,
line 68]
morkEnv::Release [d:\builds\seamonkey\mozilla\db\mork\src\morkEnv.cpp, line 202]
morkTable::CutStrongRef [d:\builds\seamonkey\mozilla\db\mork\src\morkTable.cpp,
line 1003]
morkBeadMap::CutAllBeads [d:\builds\seamonkey\mozilla\db\mork\src\morkBead.cpp,
line 256]
morkBeadMap::CloseBeadMap [d:\builds\seamonkey\mozilla\db\mork\src\morkBead.cpp,
line 172]
morkBeadMap::CloseMorkNode
[d:\builds\seamonkey\mozilla\db\mork\src\morkBead.cpp, line 144]
morkRowSpace::CloseRowSpace
[d:\builds\seamonkey\mozilla\db\mork\src\morkRowSpace.cpp, line 171]
morkRowSpace::CloseMorkNode
[d:\builds\seamonkey\mozilla\db\mork\src\morkRowSpace.cpp, line 111]
morkNode::cut_use_count [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp,
line 573]
morkNode::CutStrongRef [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp,
line 590]
morkNode::SlotStrongNode [d:\builds\seamonkey\mozilla\db\mork\src\morkNode.cpp,
line 485]
morkPortTableCursor::ClosePortTableCursor
[d:\builds\seamonkey\mozilla\db\mork\src\morkPortTableCursor.cpp, line 160]
morkPortTableCursor::CloseMorkNode
[d:\builds\seamonkey\mozilla\db\mork\src\morkPortTableCursor.cpp, line 83]
morkPortTableCursor::~morkPortTableCursor
[d:\builds\seamonkey\mozilla\db\mork\src\morkPortTableCursor.cpp, line 91]
morkPortTableCursor::`scalar deleting destructor'
morkObject::Release [d:\builds\seamonkey\mozilla\db\mork\src\morkObject.cpp,
line 68]
morkEnv::Release [d:\builds\seamonkey\mozilla\db\mork\src\morkEnv.cpp, line 202]
morkPortTableCursor::Release
[d:\builds\seamonkey\mozilla\db\mork\src\morkPortTableCursor.cpp, line 131]
nsMsgDBThreadEnumerator::~nsMsgDBThreadEnumerator
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp, line 2451]
nsMsgDBThreadEnumerator::`scalar deleting destructor'
nsMsgDBEnumerator::Release
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp, line 2458]
nsCOMPtr_base::assign_with_AddRef
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 74]
nsMsgThreadedDBView::InitThreadedView
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgThreadedDBView.cpp, line 169]
nsMsgThreadedDBView::InitThreadedView
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgThreadedDBView.cpp, line 169]
nsMsgThreadedDBView::Open
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgThreadedDBView.cpp, line 94]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2000]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2803]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 850]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3407]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1206]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1809]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3383]
nsOutlinerSelection::FireOnSelectHandler
[d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerSelection.cpp,
line 738]
nsOutlinerSelection::Select
[d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerSelection.cpp,
line 369]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2000]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2803]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 850]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3407]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsXBLPrototypeHandler::ExecuteHandler
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLPrototypeHandler.cpp, line 442]
DoMouse
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLMouseMotionHandler.cpp, line 103]
nsXBLMouseHandler::MouseDown
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLMouseHandler.cpp, line 124]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1295]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3383]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5993]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5911]

Comment 1

[Håkan Waara]

Looks like a database issue to me.

Stephend, is it *always* reproducible - and does it always happen when you're
around 100,000 headers downloaded?

Comment 2

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

This has happened to me the last 3 times I tried it.

Comment 3

[scottputterman]

Giving this an nsbeta1- because of the 100,000 messages.  If you can reproduce
this with 10,000 or left, please renominate.

Comment 4

[David :Bienvenu]

taking.

Comment 5

[David :Bienvenu]

OK, I believe this has to do with having more than 64K different threads in a
folder/newsgroup - this overflows mork's internal weak reference scheme. This in
and of itself isn't neccesarily a problem since mork catches this, but I suspect
it causes a problem down the road when we're releasing all the refs. I'll look
into this a little, since it would be a drag if we had a built-in limitation
like this.

I also found that loading this newsgroup is very slow because there's one giant
thread in it, with thousands of messages. Giant threads cause us to slow down
quite a bit as we verify that the threading is correct. There are two ways to
speed this up; one is to make the header cache bigger while loading a newsgroup
(right now we blow away the header cache quite frequently loading this
newsgroup). The other thing we could do is when we get the newsgroup hdr from
the server, check if the hdr has a message-id we've seen before, and if not,
then we know we don't have to redo any of the threading by message-id for that
header. But that could involve calling a private mork interface to see if that
message-id had been atomized already.

Comment 6

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

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

Comment 7

[Blake Ross]

Just reproduced this crash in a 6/24 nightly branch build.

Comment 8

[David :Bienvenu]

I'm workin on a fix for this. Basically, rows don't need to ref-cnt the store.
Tables probably don't either.

Comment 9

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

I believe this is a straight DUP of bug 105497, but I'll test this anyway.  

news://news.netscape.com/mcom.beta.feedback.browser no longer has a large number
of messages to easily test this, I'll poke around for some large ones.

Comment 10

[David :Bienvenu]

Stephen, yes, it's a straight dup.

*** This bug has been marked as a duplicate of 105497 ***

Comment 11

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

verified, I thought so, based on the stack and comments.

Thanks.