**** observed with 2001-05-24 build **** Steps to reproduce: - select a newsgroup with more than 500 messages; - observe crash while download //note: the dlgbox that prompts you to select to download all headers or just 500 messages doesn't pop up stack to follow

here is a stack: (Signature = ntdll.dll + 0x143ad (0x77f943ad) 6e79c808) ntdll.dll + 0x143ad (0x77f943ad) ntdll.dll + 0x49816 (0x77fc9816) MSVCRT.DLL + 0x1089 (0x78001089) MSVCRT.DLL + 0x1026 (0x78001026) morkTable::NewTableRowCursor [d:\builds\seamonkey\mozilla\db\mork\src\morkTable.cpp, line 740] orkinTable::GetTableRowCursor [d:\builds\seamonkey\mozilla\db\mork\src\orkinTable.cpp, line 561] nsMsgThread::GetChildHdrAt [d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgThread.cpp, line 414] nsMsgThread::GetChildHdrForKey [d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgThread.cpp, line 1032] nsMsgThread::GetRootHdr [d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgThread.cpp, line 931] nsMsgThreadEnumerator::nsMsgThreadEnumerator [d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgThread.cpp, line 653] nsMsgThread::EnumerateMessages [d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgThread.cpp, line 884] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3159] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185] nsMsgDBView::ListIdsInThreadOrder [d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 3185]

My Mac build from today hangs on this scenario, too, so expecting this to be XP (my linux build is crashing at startup right now). Really easy to test with a new profile, using news://news.mozilla.org/netscape.public.mozilla.mail-news

Actually, that link should be: news://news.mcom.com/netscape.public.mozilla.org (after the first initial crash in the "Download" dialog, I crash *every* time on simply accessing the newsgroup in the folder pane.)

I've tried this on Mac and Windows and have only had success. Is there a specific newsgroup that crashes or hangs?

For me, I crash 100% on n.p.m.mail-news using news.mcom.com as my server on win2k with today's 5-24-04 build.

I also unchecked the "Ask me before downloading X messages" pref, and I still crash.

I can't make this happen but I saw this on Stephen's machine and we should look into it.

looks like some evil recursion going on with nsMsgDBView::ListIdsInThreadOrder. accepting, I'll investigate.

adding url.

whoa nelly, definitely stack overflow in nsMsgDBView::ListIdsInThreadOrder() working on it now.

adding a printf to ListIdsInThreadOrder, we're stuck in this loop: parentKey = 8043, level = 3592 parentKey = 8026, level = 3593 parentKey = 8042, level = 3594 parentKey = 8043, level = 3595 parentKey = 8026, level = 3596 parentKey = 8042, level = 3597 parentKey = 8043, level = 3598 parentKey = 8026, level = 3599

here's the whole paper trail (and then the fun starts.) still working on this... parentKey = 8098, level = 1 parentKey = 8099, level = 2 parentKey = 8101, level = 3 parentKey = 8103, level = 4 parentKey = 8107, level = 1 parentKey = 8117, level = 2 parentKey = 8112, level = 1 parentKey = 8113, level = 2 parentKey = 8115, level = 1 parentKey = 8127, level = 2 parentKey = 8134, level = 3 parentKey = 8118, level = 1 parentKey = 8119, level = 2 parentKey = 8122, level = 2 parentKey = 8123, level = 3 parentKey = 8133, level = 2 parentKey = 8120, level = 1 parentKey = 8131, level = 2 parentKey = 8124, level = 1 parentKey = 8128, level = 2 parentKey = 8139, level = 3 parentKey = 8135, level = 1 parentKey = 8136, level = 2 parentKey = 8137, level = 3 parentKey = 8167, level = 3 parentKey = 8173, level = 4 parentKey = 8174, level = 5 parentKey = 8177, level = 6 parentKey = 8181, level = 6 parentKey = 8141, level = 1 parentKey = 8142, level = 2 parentKey = 8143, level = 2 parentKey = 8161, level = 2 parentKey = 8162, level = 3 parentKey = 8163, level = 3 parentKey = 8164, level = 4 parentKey = 8145, level = 1 parentKey = 8146, level = 2 parentKey = 8147, level = 2 parentKey = 5860, level = 1 parentKey = 5861, level = 2 parentKey = 8148, level = 1 parentKey = 8149, level = 2 parentKey = 8150, level = 1 parentKey = 8169, level = 2 parentKey = 8216, level = 3 parentKey = 8151, level = 1 parentKey = 8152, level = 2 parentKey = 8154, level = 3 parentKey = 8156, level = 4 parentKey = 8157, level = 5 parentKey = 8158, level = 5 parentKey = 8165, level = 6 parentKey = 8159, level = 4 parentKey = 8171, level = 2 parentKey = 8153, level = 1 parentKey = 8155, level = 2 parentKey = 938, level = 1 parentKey = 939, level = 2 parentKey = 940, level = 3 parentKey = 941, level = 3 parentKey = 7988, level = 1 parentKey = 7989, level = 2 parentKey = 7990, level = 2 parentKey = 7991, level = 2 parentKey = 4821, level = 1 parentKey = 4822, level = 2 parentKey = 4823, level = 3 parentKey = 4824, level = 4 parentKey = 4826, level = 5 parentKey = 4829, level = 6 parentKey = 8166, level = 1 parentKey = 8170, level = 2 parentKey = 8194, level = 3 parentKey = 8168, level = 1 parentKey = 8172, level = 2 parentKey = 8189, level = 3 parentKey = 8183, level = 2 parentKey = 8184, level = 3 parentKey = 8193, level = 4 parentKey = 8200, level = 5 parentKey = 7993, level = 1 parentKey = 8001, level = 2 parentKey = 8010, level = 3 parentKey = 8013, level = 4 parentKey = 8040, level = 3 parentKey = 7994, level = 1 parentKey = 7995, level = 2 parentKey = 7997, level = 2 parentKey = 7998, level = 2 parentKey = 8000, level = 2 parentKey = 7996, level = 1 parentKey = 8003, level = 2 parentKey = 8064, level = 3 parentKey = 8068, level = 4 parentKey = 8072, level = 4 parentKey = 8082, level = 5 parentKey = 8083, level = 6 parentKey = 4830, level = 1 parentKey = 4831, level = 2 parentKey = 5887, level = 1 parentKey = 5903, level = 2 parentKey = 7999, level = 1 parentKey = 8009, level = 2 parentKey = 8051, level = 3 parentKey = 5888, level = 1 parentKey = 5898, level = 2 parentKey = 5908, level = 3 parentKey = 8176, level = 1 parentKey = 8178, level = 2 parentKey = 8179, level = 3 parentKey = 8182, level = 2 parentKey = 8190, level = 3 parentKey = 5890, level = 1 parentKey = 5897, level = 2 parentKey = 8006, level = 1 parentKey = 8002, level = 2 parentKey = 8032, level = 3 parentKey = 8034, level = 4 parentKey = 5891, level = 1 parentKey = 5899, level = 2 parentKey = 5909, level = 3 parentKey = 5906, level = 2 parentKey = 5892, level = 1 parentKey = 5893, level = 2 parentKey = 5901, level = 3 parentKey = 8004, level = 1 parentKey = 8011, level = 2 parentKey = 8180, level = 1 parentKey = 8191, level = 2 parentKey = 8005, level = 1 parentKey = 8008, level = 2 parentKey = 5895, level = 1 parentKey = 5905, level = 2 parentKey = 5910, level = 3 parentKey = 8007, level = 1 parentKey = 8012, level = 2 parentKey = 8185, level = 1 parentKey = 8187, level = 2 parentKey = 5900, level = 1 parentKey = 5902, level = 2 parentKey = 8014, level = 1 parentKey = 8017, level = 2 parentKey = 8039, level = 3 parentKey = 8015, level = 1 parentKey = 8106, level = 2 parentKey = 8108, level = 3 parentKey = 8130, level = 4 parentKey = 8132, level = 5 parentKey = 8144, level = 6 parentKey = 8175, level = 6 parentKey = 8016, level = 1 parentKey = 8018, level = 2 parentKey = 8192, level = 1 parentKey = 8197, level = 2 parentKey = 8198, level = 3 parentKey = 8035, level = 1 parentKey = 8036, level = 2 parentKey = 8019, level = 3 parentKey = 8037, level = 3 parentKey = 8038, level = 4 parentKey = 8195, level = 1 parentKey = 8196, level = 2 parentKey = 8020, level = 1 parentKey = 8021, level = 2 parentKey = 8022, level = 3 parentKey = 8048, level = 4 parentKey = 8053, level = 5 parentKey = 8030, level = 3 parentKey = 8023, level = 1 parentKey = 8024, level = 2 parentKey = 8027, level = 3 parentKey = 8029, level = 4 parentKey = 8199, level = 1 parentKey = 8201, level = 2 parentKey = 8202, level = 3 parentKey = 8025, level = 1 parentKey = 8028, level = 2 parentKey = 8043, level = 1 parentKey = 8026, level = 2 parentKey = 8042, level = 3 parentKey = 8043, level = 4 parentKey = 8026, level = 5 parentKey = 8042, level = 6 parentKey = 8043, level = 7 parentKey = 8026, level = 8 parentKey = 8042, level = 9 parentKey = 8043, level = 10

I've got a mbox that reproduce this problem when you thread it. I'll attach it.

updating summary. I'll continue working on this tomorrow.

I might know what's happening here - I'll check it out. My guess is that a thread parent is arriving after a thread child, and causing the thread object to get confused. There is code to handle this, but I'm guessing it's not working right. (this is probably an old old bug).

OK, here's the problem - when messages arrive out of threading order, we have to move messages around in the thread table in order to get the first message in the thread to be the first message in the thread table. The way we do this is, if we see that a new message is the parent of an existing message, we move it before the existing message. If the existing message was the former "first message in the thread", the new message becomes the first message in the thread. However, in this case, what's happening is that the newly arrived message is a parent of the soon to be former first message in the thread, but the newly arrived message already has a parent in the thread. What needs to happen is that the oldest existing ancestor of the newly arrived message should become the root message in the thread. In most cases, that will end up being the new message, but it might be an existing message. I'll try to come up with a patch for this.

over to david, who is working on the fix. cc'ing waterson. david tells me this is the bug that kept biting waterson in 6.0, but we could never get a reproducable case.

getting this too, current CVS. Never dared use moz much for newsgroups, tried now, and crash. 0x401e1d19 in __pthread_alt_lock (lock=0x405c7320, self=0x0) at spinlock.c:370 370 spinlock.c: No such file or directory. in spinlock.c (gdb) bt #0 0x401e1d19 in __pthread_alt_lock (lock=0x405c7320, self=0x0) at spinlock.c:370 #1 0x401dec86 in __pthread_mutex_lock (mutex=0x405c7310) at mutex.c:120 #2 0x4051dd4d in __libc_free (mem=0x8c4a6b0) at malloc.c:3052 #3 0x405f5136 in __builtin_delete (ptr=0x8c4a6b0) from /usr/lib/libstdc++-libc6.2-2.so.3 #4 0x42cf7597 in orkinHeap::Free () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #5 0x42d05c01 in morkNode::ZapOld () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #6 0x42d06485 in morkNode::CutWeakRef () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #7 0x42d06370 in morkNode::CutStrongRef () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #8 0x42d0616b in morkNode::SlotStrongNode () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #9 0x42d03bf7 in morkHandle::CloseHandle () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #10 0x42d03a06 in morkHandle::CloseMorkNode () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #11 0x42d06301 in morkNode::cut_use_count () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #12 0x42d0635f in morkNode::CutStrongRef () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #13 0x42d042b7 in morkHandle::Handle_CutStrongRef () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #14 0x42cfd23f in orkinTableRowCursor::Release () from /home/dark/DISK/mozilla/dist/bin/components/libmork.so #15 0x42d39bfd in nsMsgThread::GetChildHdrAt () from /home/dark/DISK/mozilla/dist/bin/components/libmsgdb.so #16 0x42d3a934 in nsMsgThread::GetChildHdrForKey () from /home/dark/DISK/mozilla/dist/bin/components/libmsgdb.so #17 0x42d3a684 in nsMsgThread::GetRootHdr () from /home/dark/DISK/mozilla/dist/bin/components/libmsgdb.so #18 0x42d39f05 in nsMsgThreadEnumerator::nsMsgThreadEnumerator () from /home/dark/DISK/mozilla/dist/bin/components/libmsgdb.so #19 0x42d3a527 in nsMsgThread::EnumerateMessages () from /home/dark/DISK/mozilla/dist/bin/components/libmsgdb.so #20 0x4280fd01 in nsMsgDBView::ListIdsInThreadOrder () from /home/dark/DISK/mozilla/dist/bin/components/libmailnews.so #21 0x4280fe5f in nsMsgDBView::ListIdsInThreadOrder () . . . #2493 0x4280fe5f in nsMsgDBView::ListIdsInThreadOrder () from /home/dark/DISK/mozilla/dist/bin/components/libmailnews.so It went on with 3000 identical lines before i broke it. At the time i had just subscribed to two newsgroups on a new server. One of them had read and marked read. The crash occured while downloading 500 new headers from the second newsgroup (actually the first that listed of the two) Afterwards i get the same crash each time i click on that newsgroup.

Can I get reviews, Navin and Seth? The fix is, as I described above, to reroot the thread correctly when a parent of the root is added after the existing root. I also changed the view code not to treat 0 as a special parent (that code was a left-over from the early days where we weren't setting the thread parent of the root to nsMsgKey_None, but rather 0) and also change the top level message in the thread view to be the root hdr, not the 0th hdr. I'll also attach another test case that exercises the non-reference threading code at the end of nsMsgThread::AddChild.

sr=sspitzer

r=naving

a= asa@mozilla.org for checkin to 0.9.1 (on behalf of drivers)

fix checked in.

current CVS: this fixed the problem on Linux.

david, is the fix checked into 2001-05-30 build? if yes, here is what i get when verifying: - first time i download a big folder i get a prompt about 500 headers or all and everything goes smoothly without a crash... though if i want to switch to another huge folder i crash while downloading. do we reopen?

if you're saying you're downloading one folder and then click in another folder while the first folder is still downloading and crash, that's a different bug.

no, what i am saying is after viewing the first (fully) downloaded folder i am switching to another folder i crash ( basically same crash but not after the first attempt to download a huge folder but after the second one)

Yes, but the crash used to be/was filed as the fact that we couldn't even get past the Download Headers dialog, correct? Then David is right in saying that this would be a different crash. Can you get a new stack trace, and place the trace as an attachment?

stephen, the original report was for the crash on downloading a huge newsgroup and it still looks the same to me: if the first newsgroup would be a huge one i can get past the download headers dlg , read articles without a crash( that's new) but if i start with a rather small newsgroup and then switch to a huge one i'll crash , so where is the diffeerence? ... in any event i'll attach the stack

try deleteing the msf file for the newsgroup you opened that caused the crash. the fix for this bug is to store things correctly in the db - it doesn't do anything about old db's that were created incorrectly.

after deleting the msf file for those newsgroup i don't crash!... then it's fixed.

Verified FIXED using (news.mcom.com/netscape.public.mozilla.mail-news) & the testcase provided by Seth/David: Mac OS 9.1 build 2001-05-30-09 RedHat 7.0 build 2001-05-30-08 Windows 2000 build 2001-05-30-04 Was easy to verify; just like Marina, old msf files that were lurking kept hanging(mac) and crashing(win2K). Creating a new profile with this build solved the problem. Nice work.

Addint topcrash keyword and [@ ntdll.dll - morkTable::NewTableRowCursor] to summary for tracking. I noticed a few crashes in today's Topcrash report with build 2001053009 on Win2K...I'm guessing those are the crashes stephend had during his testing, before creating a new profile. Stephen, can you confirm?

Yes, I crashed a couple of times, making sure that the old .msf files would still crash, but when I switched to a new profile (both times on Windows 2000) I no longer crashed. I think Marina runs NT 4.0, so those are both probably mine. I'll take a look at the talkback report and see if it's my machine.

Jay, having a hard time finding my stacks, of the few stacks, do they all show Service Pack 2 with 384 megs of RAM, with a Pentium III processor at 750 or so mHz? If so, those are mine.

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

Fenella is absolutely right about this, this will still affect users who have a current profile that crashes, so they need to know to either delete the .msf for the crashing newsgroup, or create a new profile.

Steven, per our conversation, you also mentioned that another easy way to avoid the crash was to unsubscribe the newsgroup and then subscribe again. I tried it and it works. Esther suggested that you put this bug in the release note so that people who runs daily builds during beta development would know how to avoid this crash.

I have now commented in the release note bug 81652.

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

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

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

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

adding [@ MSVCRT.dll - morkNode::CutWeakRef] to summary for future reference, since the original bug for that crash (bug 83758) was marked a dup of this one.