428614 - Crash every time I try to read news [@SearchTable]

Status: RESOLVED FIXED

(MailNews Core :: Database, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

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)

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 2

[Matthias Versen [:Matti]]

adding a crash id from about:crashes would be nice

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 5

[Matthias Versen [:Matti]]

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

Comment 6

[Andrew Schultz]

#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

Comment 7

[Joshua Cranmer [:jcranmer]]

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.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

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? 

Comment 9

[Mark Banner (:standard8)]

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" ?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 11

[Frank Wein [:mcsmurf]]

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

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 14

[timeless]

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

you need to have symbols configured

Comment 15

[Joshua Cranmer [:jcranmer]]

Attachment: Patch

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.

Comment 16

[David :Bienvenu]

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

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

Comment 17

[Phil Ringnalda (:philor)]

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

Comment 18

[Wayne Mery (:wsmwk)]

crash stats shows no crashes with 2008042100 build

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

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.  

Comment 20

[Mark Banner (:standard8)]

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.

Comment 21

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Moving alpha 1 nomination to alpha 2.

Comment 22

[Mark Banner (:standard8)]

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.

Comment 23

[Joshua Cranmer [:jcranmer]]

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. 

Comment 24

[Joshua Cranmer [:jcranmer]]

Thought I was already assigned...

Comment 25

[David Ascher (:davida)]

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

Comment 26

[Joshua Cranmer [:jcranmer]]

Attachment: Fix for the newer problem

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

Comment 27

[David :Bienvenu]

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?

Comment 28

[Joshua Cranmer [:jcranmer]]

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

Comment 29

[Joshua Cranmer [:jcranmer]]

Attachment: Patch [checked-in]

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