Nelson Bolyard (seldom reads bugmail) Reporter
	Description • 17 years ago

SM trunk 20080410 nightly build
Start browser, ctrl-2 to bring up mail/news window.
Click on news group in folder pane.
Boom.  
Every time. 
Should be lots of those talkback-like things, 'cuz I report them all.
Was OK in 20080403 (nightly from one week ago)

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 1 • 17 years ago

SM trunk nightly build Gecko/2008040702 doesn't crash when I try to read news.

	Matthias Versen [:Matti]
	Comment 2 • 17 years ago

adding a crash id from about:crashes would be nice

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 3 • 17 years ago

Having about:crashes be discoverable would be nice, too.

9bab4814-082a-11dd-94bf-001cc45a2ce4	2008-04-11	17:49
fab1db7a-0828-11dd-a7f1-001cc45a2ce4	2008-04-11	17:37
28e450b5-0828-11dd-9fb4-001cc45a2ce4	2008-04-11	17:32

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 4 • 17 years ago

Correction:  
SM Gecko/2008040702 DOES crash if I read news after visiting a web page.   

d3bf59fa-0839-11dd-995c-001cc4e2bf68	2008-04-11	19:38

	Matthias Versen [:Matti]
	Comment 5 • 17 years ago

all the stacks are the same Stack overflow :

0  	xpcom_core.dll  	SearchTable  	 pldhash.c:402
1 	xpcom_core.dll 	PL_DHashTableOperate 	pldhash.c:598
2 	mail.dll 	nsMsgDatabase::GetHdrFromUseCache 	mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp:421
3 	mail.dll 	nsMsgDatabase::GetMsgHdrForKey 	mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp:1717
4 	mail.dll 	nsMsgHdr::GetIsKilled 	mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp:873
5 	mail.dll 	nsMsgHdr::GetIsKilled 	mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp:876
6 	mail.dll 	nsMsgHdr::GetIsKilled 	mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp:876
7 	mail.dll 	nsMsgHdr::GetIsKilled 	mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp:876
8 	mail.dll 	nsMsgHdr::GetIsKilled 	mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp:876
9 	mail.dll 	nsMsgHdr::GetIsKilled 	mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp:876
10 	mail.dll 	nsMsgHdr::GetIsKilled 	mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp:876

I had no crash reading news today with : Gecko/2008041102 SeaMonkey/2.0a1pre

	Andrew Schultz
	Comment 6 • 17 years ago

#1 TB crasher
bustage from bug 11054

http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=signature&query_type=contains&product=Thunderbird&signature=SearchTable&query=SearchTable&range_value=1

	Joshua Cranmer [:jcranmer] Assignee
	Comment 7 • 17 years ago

Taking a look at the crash information, it appears that this would be triggered by exceptionally recursive threads. Nelson, could you tell me the newsgroup you are using that has such a thread?

In the meantime, viewing ignored threads should allow you to read news w/o crashing.

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 8 • 17 years ago

Joshua, How does one view ignored threads?

What do you consider "exceptionally recursive threads"?
Threads with depths of 50 or more are not uncommon on usenet.
Does the implementation of bug 11054 have some thread depth limit 
beyond which it crashes or doesn't work? 

	Mark Banner (:standard8)
	Comment 9 • 16 years ago

Nelson, which news servers / group(s) are you trying to read?

Joshua, is there a possibility with

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp&rev=1.123&mark=872-876#858

that we are getting "parentHdr == this" ?

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 10 • 16 years ago

I have 4 different news server accounts.  I think I experienced the crash 
with more than one of them.  

If you want a group with deep threads, try sci.crypt on any usenet server 
with a relatively complete feed.  I read that group on a giganews server.

I have the impression that maybe no-one in the mailnews groups uses giganews.  
Since they're one of the top 5 news server companies, I'd think it would make 
sense of MailCo (or whatever the new name is) to spring a few bucks to get 
you test accounts there.  Seems like it might be money well spent.

Another group with occasional deep threads is grc.techtalk on news.grc.com

	Frank Wein [:mcsmurf]
	Comment 11 • 16 years ago

(In reply to comment #9)
> Joshua, is there a possibility with
> 
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp&rev=1.123&mark=872-876#858
> 
> that we are getting "parentHdr == this" ?

As I also experience this crash when I try to read a newsgroup on news.mozilla.org, I see this: Here in the debugger "this" is not parentHdr, but the "isKilled" pointer points to the same address as parentHdr.

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 12 • 16 years ago

Hit this 3 times in rapid succession tonight.  
Looked at stack in MSVC8 debugger.
Debugger will only trace the stack 1000 levels.  
The top of the stack looks like this:
 	xpcom_core.dll!60ed1380() 	
 	xpcom_core.dll!60ed1773() 	
 	mail.dll!60d76d99() 	
 	mail.dll!60d775c7() 	
 	mail.dll!60d82726() 	
 	mail.dll!60d82734() 	
 	mail.dll!60d82734() 	
There are 993 more lines just like the last one.

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 13 • 16 years ago

That stack was over 42000 levels deep.  :) gotta love infinite recursion.

	timeless
	Comment 14 • 16 years ago

http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg

you need to have symbols configured

	Joshua Cranmer [:jcranmer] Assignee
	Comment 15 • 16 years ago

Judging from above comments and others on IRC, it looks like the crash is happening when m_messageKey == parentKey; this patch will cut off this infinite recursion and should fix the problem.

	David :Bienvenu
	Comment 16 • 16 years ago

Comment on attachment 316750 [details] [diff] [review]
Patch

ok, thx, let's give it a try.

	Phil Ringnalda (:philor)
	Comment 17 • 16 years ago

mailnews/db/msgdb/src/nsMsgHdr.cpp 1.124

	Wayne Mery (:wsmwk)
	Comment 18 • 16 years ago

crash stats shows no crashes with 2008042100 build

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 19 • 16 years ago

Yeah, the good news is that the crashes have stopped.  
The bad news is that, when I started up with today's nightly, the message 
list pane for the newsgroup was really screwed up.  Threads with a single
message that was read continued to appear in the message list pane, even 
after repeated selecting to show only threads with unread messages.
So I rebuilt the MSF files, but now the newsgroup appears to be all 
read.  So I lost the partially read threads.  Only time will tell 
if partially-read threads have a new problem.  

	Mark Banner (:standard8)
	Comment 20 • 16 years ago

Although the patch appeared to have cleared up some problems, there have been (so far) 3 occurrences in Shredder Alpha 1 topcrasher's list (there are also 8 occurrences on the 3.0a1pre top crasher's list).

Therefore reopening, as the original fix obviously hasn't quite got all cases.

	Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)
	Comment 21 • 16 years ago

Moving alpha 1 nomination to alpha 2.

	Mark Banner (:standard8)
	Comment 22 • 16 years ago

This has also been seen on an imap account: http://crash-stats.mozilla.com/report/index/0a6b8e07-3c7b-11dd-9b9e-001cc45a2c28 (MarcoZ).

This prevented accessing the inbox of the relevant account, manually removing the msf file, and redownloading all the headers worked.

	Joshua Cranmer [:jcranmer] Assignee
	Comment 23 • 16 years ago

Thanks to a copy of a crashing msf file, I've found what is probably the source of the crasher.

One message key (the one that's recursing indefinitely) has its threadParent set to the suspicious value 0xffffffec, which happens to exist, with its threadParent set to the first one. I'm leery of just checking the parent for loops, since another case might crop up with larger loops.

As far as I can tell, there are two identifying characteristics that we could use to distinguish these cases:
1. "negative" values (0xffff*), so the test would be some form of
|if (!(threadParent & 0xff000000))|
2. A case where the threadParent isn't in the thread. Though probably more correct, this is probably slower.

The question still remains what is causing these problematic message keys to crop up. It looks like it's some form of deletion, but something ends up holding on that shouldn't. 

	Joshua Cranmer [:jcranmer] Assignee
	Comment 24 • 16 years ago

Thought I was already assigned...

	David Ascher (:davida)
	Comment 25 • 16 years ago

given the crashingness, and the imap crash report, this looks to me like something that could affect a lot of users.  approving blocking-tb3a2

	Joshua Cranmer [:jcranmer] Assignee
	Comment 26 • 16 years ago

I chose option #2. Seems uglier, but less hackish...

	David :Bienvenu
	Comment 27 • 16 years ago

Comment on attachment 325862 [details] [diff] [review]
Fix for the newer problem

should we handle the case where thread is null, i.e., parentHdr doesn't belong to a thread? Or does that not happen?

	Joshua Cranmer [:jcranmer] Assignee
	Comment 28 • 16 years ago

/cvsroot/mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp,v  <--  nsMsgHdr.cpp
new revision: 1.126; previous revision: 1.125
done

	Joshua Cranmer [:jcranmer] Assignee
	Comment 29 • 16 years ago

This is the slight modification of the last patch that was actually checked in.