many assertions when loading rec.arts.sf.written

VERIFIED WORKSFORME

Status

MailNews Core
Database
P3
normal
VERIFIED WORKSFORME
18 years ago
9 years ago

People

(Reporter: scottputterman, Assigned: Bienvenu)

Tracking

Trunk
Future
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
I tried downloading rec.arts.sf.written and after about 2700 messages I asserted
enough times that I had to quit at:

nsDebug::Assertion(const char * 0x0196cc1c, const char * 0x0196cb18, const char
* 0x0196cae8, int 78) line 186 + 13 bytes
mork_assertion_signal(const char * 0x0196cc1c) line 78 + 31 bytes
morkEnv::NewWarning(const char * 0x0196ca40) line 381 + 19 bytes
morkNode::RefsOverflowWarning(morkEnv * 0x0383a650) line 328
morkNode::AddWeakRef(morkEnv * 0x0383a650) line 576
morkNode::SlotWeakNode(morkNode * 0x038454e0, morkEnv * 0x0383a650, morkNode * *
0x053621a8) line 468 + 18 bytes
morkTable::SlotWeakTable(morkTable * 0x038454e0, morkEnv * 0x0383a650, morkTable
* * 0x053621a8) line 282 + 20 bytes
morkTableRowCursor::morkTableRowCursor(morkEnv * 0x0383a650, const morkUsage &
{...}, nsIMdbHeap * 0x0383da80, morkTable * 0x038454e0, long 205) line 98 + 20
bytes
morkTable::NewTableRowCursor(morkEnv * 0x0383a650, long 205) line 739 + 58 bytes
orkinTable::GetTableRowCursor(nsIMdbEnv * 0x0383c3d8, long 205,
nsIMdbTableRowCursor * * 0x0012f9ac) line 560 + 19 bytes
nsMsgThread::GetChildHdrAt(nsMsgThread * const 0x0535d0e0, int 206, nsIMsgDBHdr
* * 0x0012fa20) line 369 + 37 bytes
nsMsgThread::AddChild(nsMsgThread * const 0x0535d0e0, nsIMsgDBHdr * 0x05359d60,
nsIMsgDBHdr * 0x0535b190, int 1, nsIDBChangeAnnouncer * 0x0383c5d0) line 217 +
40 bytes
nsMsgDatabase::AddToThread(nsMsgHdr * 0x05359d60, nsIMsgThread * 0x0535d0e0,
nsIMsgDBHdr * 0x0535b190, int 1) line 2548 + 33 bytes
nsMsgDatabase::ThreadNewHdr(nsMsgHdr * 0x05359d60, int & 1244292) line 2505 + 44
bytes
nsMsgDatabase::AddNewHdrToDB(nsMsgDatabase * const 0x0383c5d0, nsIMsgDBHdr *
0x05359d60, int 1) line 2008 + 22 bytes
nsNNTPNewsgroupList::ParseLine(char * 0x00000000, unsigned int * 0x0012fcbc)
line 774 + 29 bytes
nsNNTPNewsgroupList::ProcessXOVERLINE(nsNNTPNewsgroupList * const 0x038420a0,
const char * 0x0535d140, unsigned int * 0x0012fce4) line 796 + 16 bytes
nsNNTPProtocol::ReadXover(nsIInputStream * 0x03841d48, unsigned int 8192) line
3186 + 34 bytes
nsNNTPProtocol::ProcessProtocolState(nsIURI * 0x03845334, nsIInputStream *
0x03841d48, unsigned int 901120, unsigned int 8192) line 4699 + 16 bytes
nsMsgProtocol::OnDataAvailable(nsMsgProtocol * const 0x038458b0, nsIChannel *
0x03843eb4, nsISupports * 0x03845334, nsIInputStream * 0x03841d48, unsigned int
901120, unsigned int 8192) line 172 + 32 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x053102c0)
line 370
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x05311fd0) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x05311fd0) line 522 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0108d6c0) line 483 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0013108c, unsigned int 49480, unsigned int 0,
long 17356480) line 951 + 9 bytes
USER32! 77e71820()
0108d6c0()

Comment 1

18 years ago
Since it's only a warning, the assert is only advisory; this predates any more
rational approach to assertions since first writing.  The assert could be
commented out, if the problem is really just sheer number of references.  I
should look a the code to see what number causes overflow.  Since I suspect the
number is at least 0x7FFF, then 2700 messages should not be nearly enough to
cause the problem, in which case it could also be caused by memory stomping.
(Assignee)

Comment 2

18 years ago
these are mine now, I guess.
Assignee: davidmc → bienvenu

Comment 3

18 years ago
Marking M16 (not M15 stopper)
Target Milestone: --- → M16
(Assignee)

Comment 4

18 years ago
accepting
Status: NEW → ASSIGNED

Comment 5

18 years ago
Not M16 stopper.  Marking M17.
Target Milestone: M16 → M17
(Reporter)

Comment 6

18 years ago
moving to future.
Target Milestone: M17 → Future
(Assignee)

Comment 7

17 years ago
have not seen this in a very long time.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 8

17 years ago
ok, verified wfm then.  Scott, assume you don't see this any longer?
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.