82595 - message thread causes infinite loop, crash Trunk [@ ntdll.dll - morkTable::NewTableRowCursor][@ MSVCRT.dll - morkNode::CutWeakRef]

Reporter

Description

•

23 years ago

**** 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

marina

Reporter

Comment 1

•

23 years ago

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]

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 2

•

23 years ago

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

Keywords: crash, nsbeta1

OS: Windows 2000 → All

Hardware: PC → All

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 3

•

23 years ago

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.)

Oliver Klee

Updated

•

23 years ago

Severity: normal → critical

scottputterman

Comment 4

•

23 years ago

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

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 5

•

23 years ago

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.

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 6

•

23 years ago

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

scottputterman

Comment 7

•

23 years ago

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

Priority: -- → P1

Whiteboard: [nsbeta1+]

Target Milestone: --- → mozilla0.9.1

(not reading, please use seth@sspitzer.org instead)

Comment 8

•

23 years ago

looks like some evil recursion going on with nsMsgDBView::ListIdsInThreadOrder.

accepting, I'll investigate.

Status: NEW → ASSIGNED

(not reading, please use seth@sspitzer.org instead)

Comment 9

•

23 years ago

adding url.

URL: news://news.mcom.com/netscape.public....

(not reading, please use seth@sspitzer.org instead)

Comment 10

•

23 years ago

whoa nelly, definitely stack overflow in nsMsgDBView::ListIdsInThreadOrder()

working on it now.

(not reading, please use seth@sspitzer.org instead)

Comment 11

•

23 years ago

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

(not reading, please use seth@sspitzer.org instead)

Comment 12

•

23 years ago

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

(not reading, please use seth@sspitzer.org instead)

Comment 13

•

23 years ago

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

I'll attach it.

(not reading, please use seth@sspitzer.org instead)

Comment 14

•

23 years ago

Attached patch this mbox folder will crash when you view in thread mode and then expand the thread — Details — Splinter Review

(not reading, please use seth@sspitzer.org instead)

Comment 15

•

23 years ago

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

Summary: News: crash on downloading huge newsgroup → message thread causes infinite loop, crash

David :Bienvenu

Assignee

Comment 16

•

23 years ago

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).

David :Bienvenu

Assignee

Comment 17

•

23 years ago

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.

(not reading, please use seth@sspitzer.org instead)

Comment 18

•

23 years ago

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.

Assignee: sspitzer → bienvenu

Status: ASSIGNED → NEW

R.K.Aa.

Comment 19

•

23 years ago

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.

David :Bienvenu

Assignee

Comment 20

•

23 years ago

Attached patch db part of proposed fix — Details — Splinter Review

David :Bienvenu

Assignee

Comment 21

•

23 years ago

Attached patch view part of diffs — Details — Splinter Review

David :Bienvenu

Assignee

Comment 22

•

23 years ago

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.

Whiteboard: [nsbeta1+] → [nsbeta1+] fix in hand

David :Bienvenu

Assignee

Comment 23

•

23 years ago

Attached file test case for subject threading when root message arrives after children. — Details

(not reading, please use seth@sspitzer.org instead)

Comment 24

•

23 years ago

sr=sspitzer

Navin Gupta

Comment 25

•

23 years ago

r=naving

David :Bienvenu

Assignee

Updated

•

23 years ago

Whiteboard: [nsbeta1+] fix in hand → [nsbeta1+] fix in hand , got reviews, will check in tonight if tree opens

Asa Dotzler [:asa]

Comment 26

•

23 years ago

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

David :Bienvenu

Assignee

Comment 27

•

23 years ago

fix checked in.

Status: NEW → RESOLVED

Closed: 23 years ago

Resolution: --- → FIXED

R.K.Aa.

Comment 28

•

23 years ago

current CVS: this fixed the problem on Linux.

marina

Reporter

Comment 29

•

23 years ago

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?

David :Bienvenu

Assignee

Comment 30

•

23 years ago

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.

marina

Reporter

Comment 31

•

23 years ago

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)

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 32

•

23 years ago

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?

marina

Reporter

Comment 33

•

23 years ago

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

marina

Reporter

Comment 34

•

23 years ago

Attached file here is the stack — Details

David :Bienvenu

Assignee

Comment 35

•

23 years ago

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.

Component: Networking - News → Mail Database

marina

Reporter

Comment 36

•

23 years ago

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

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 37

•

23 years ago

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.

Status: RESOLVED → VERIFIED

Jay Patel [:jay]

Comment 38

•

23 years ago

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?

Keywords: topcrash

Summary: message thread causes infinite loop, crash → message thread causes infinite loop, crash Trunk [@ ntdll.dll - morkTable::NewTableRowCursor]

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 39

•

23 years ago

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.

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 40

•

23 years ago

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.

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 41

•

23 years ago

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

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 42

•

23 years ago

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.

Keywords: relnote

fenella

Comment 43

•

23 years ago

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.

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 44

•

23 years ago

I have now commented in the release note bug 81652.

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 45

•

23 years ago

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

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 46

•

23 years ago

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

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 47

•

23 years ago

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

scottputterman

Comment 48

•

23 years ago

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

Jay Patel [:jay]

Comment 49

•

23 years ago

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.

Summary: message thread causes infinite loop, crash Trunk [@ ntdll.dll - morkTable::NewTableRowCursor] → message thread causes infinite loop, crash Trunk [@ ntdll.dll - morkTable::NewTableRowCursor][@ MSVCRT.dll - morkNode::CutWeakRef]

Myk Melez [:myk] [@mykmelez]

Updated

•

20 years ago

Product: MailNews → Core

Nobody; OK to take it and work on it

Updated

•

16 years ago

Product: Core → MailNews Core

Nobody; OK to take it and work on it

Updated

•

13 years ago

Crash Signature: [@ ntdll.dll - morkTable::NewTableRowCursor] [@ MSVCRT.dll - morkNode::CutWeakRef]

Mark Banner (:standard8)

Updated

•

12 years ago

Keywords: relnote

this mbox folder will crash when you view in thread mode and then expand the thread 23 years ago (not reading, please use seth@sspitzer.org instead) 41.38 KB, patch		Details \| Diff \| Splinter Review
db part of proposed fix 23 years ago David :Bienvenu 8.97 KB, patch		Details \| Diff \| Splinter Review
view part of diffs 23 years ago David :Bienvenu 1.59 KB, patch		Details \| Diff \| Splinter Review
test case for subject threading when root message arrives after children. 23 years ago David :Bienvenu 10.93 KB, text/plain		Details
here is the stack 23 years ago marina 82.58 KB, text/html		Details