Last Comment Bug 130442 - Crash in [@ nsNntpCacheStreamListener::OnStartRequest(nsIRequest*, nsISupports*)] closing stand-alone windows.
: Crash in [@ nsNntpCacheStreamListener::OnStartRequest(nsIRequest*, nsISupport...
Status: RESOLVED FIXED
: crash, fixed-seamonkey2.0.1, topcrash
Product: MailNews Core
Classification: Components
Component: Networking: NNTP (show other bugs)
: Trunk
: All All
: -- critical with 1 vote (vote)
: Thunderbird 3.0rc1
Assigned To: David :Bienvenu
:
Mentors:
http://talkback-public.mozilla.org/ta...
: 506257 (view as bug list)
Depends on:
Blocks: 531794
  Show dependency treegraph
 
Reported: 2002-03-12 17:30 PST by stephend@netscape.com (gone - use stephen.donner@gmail.com instead)
Modified: 2011-06-09 14:58 PDT (History)
16 users (show)
mozilla: blocking‑thunderbird3-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
possible fix (1.10 KB, patch)
2009-07-24 17:47 PDT, David :Bienvenu
no flags Details | Diff | Review
check for null channel in both start and stop request (1.47 KB, patch)
2009-10-22 10:57 PDT, David :Bienvenu
Pidgeot18: review+
neil: superreview+
Details | Diff | Review
fix for landing (1.60 KB, patch)
2009-10-26 13:57 PDT, David :Bienvenu
mozilla: approval‑thunderbird3+
Details | Diff | Review

Description stephend@netscape.com (gone - use stephen.donner@gmail.com instead) 2002-03-12 17:30:23 PST
Build ID: 2002-03-12-08, Linux RedHat 7.2

Summary: Crash in [ @ nsNntpCacheStreamListener::OnStartRequest] closing
stand-alone windows.

Steps to Reproduce:

DISCLAIMER: Not very reproducable, and the server was being extremely slow when
I was doing this, so bear with me.

1.  Double-click on multiple news postings.
2.  Before they come up entirely, close their windows.

Expected Results:

Window should close.

Actual Results:

Crash in nsNntpCacheStreamListener::OnStartRequest
Comment 1 stephend@netscape.com (gone - use stephen.donner@gmail.com instead) 2002-03-12 17:31:31 PST
Here's the full stack, but it's not particularly useful.

nsNntpCacheStreamListener::OnStartRequest() 
Process() 
nsStorageTransport::AsyncRead() 
AsyncRead() 
nsNNTPProtocol::ReadFromMemCache() 
nsNNTPProtocol::OnCacheEntryAvailable() 
XPTC_InvokeByIndex() 
EventHandler() 
PL_HandleEvent() 
PL_ProcessEventsBeforeID() 
processQueue() 
nsVoidArray::EnumerateForwards() 
nsAppShell::ProcessBeforeID() 
handle_gdk_event() 
libgdk-1.2.so.0 + 0x1710f (0x4036910f) 
libglib-1.2.so.0 + 0x10055 (0x40398055) 
libglib-1.2.so.0 + 0x10659 (0x40398659) 
libglib-1.2.so.0 + 0x107e8 (0x403987e8) 
libgtk-1.2.so.0 + 0x9127b (0x402b427b) 
nsAppShell::Run() 
nsAppShellService::Run() 
netscape-bin + 0x84a9 (0x080504a9) 
netscape-bin + 0x8cf7 (0x08050cf7) 
libc.so.6 + 0x1c306 (0x404f5306) 
Comment 2 Håkan Waara 2002-03-23 05:17:25 PST
Are there other crashes in talkback, with the same stack?  Any other data?
Comment 3 stephend@netscape.com (gone - use stephen.donner@gmail.com instead) 2002-03-23 14:07:45 PST
It was from a Windows XP user, but they didn't place their email or steps to
reproduce in the stack

 2002031805   MozillaTrunk   Windows NT 5.1 build 2600   2002-03-21 04:13:42  
nsNntpCacheStreamListener::OnStartRequest d753d45d
Comment 4 stephend@netscape.com (gone - use stephen.donner@gmail.com instead) 2002-09-15 03:01:26 PDT
Okay, people are still seeing this.  I'm seeing crashes in Talkback stacks as
recent as 8/26/2002.
Comment 5 stephend@netscape.com (gone - use stephen.donner@gmail.com instead) 2002-09-15 03:06:49 PDT
x86 Registers:
EAX: 00000000 EBX: 60012450 ECX: 00000000 EDX: 0012fd08
ESI: 03f418e0 EDI: 00000000 ESP: 0012fcec EBP: 0012fd0c
EIP: 60c4fe2a cf PF af ZF sf of IF df nt RF vm   IOPL: 0
CS: 001b DS: 0023 SS: 0023 ES: 0023 FS: 0038 GS: 0000

Code Around the PC:
60c4fe2a 8b08             mov     ecx,[eax]
60c4fe2c ff5124           call    dword ptr [ecx+0x24]
60c4fe2f 8b45fc           mov     eax,[ebp-0x4]
60c4fe32 3bc7             cmp     eax,edi
60c4fe34 740a             jz      60c4fe40
60c4fe36 8b08             mov     ecx,[eax]
60c4fe38 57               push    edi
60c4fe39 ff7508           push    dword ptr [ebp+0x8]
60c4fe3c 50               push    eax
60c4fe3d ff5144           call    dword ptr [ecx+0x44]
60c4fe40 ff7510           push    dword ptr [ebp+0x10]
60c4fe43 8b760c           mov     esi,[esi+0xc]
60c4fe46 ff7508           push    dword ptr [ebp+0x8]
60c4fe49 8b491c           mov     ecx,[ecx+0x1c]
Comment 6 David Bradley 2002-09-19 05:42:43 PDT
The crash occurs at line 721:

mChannelToUse->GetLoadGroup(getter_AddRefs(loadGroup));

Looks like mChannelToUse is null.

NOTE: The assembler is not exactly identical to what I have on my system, but
I'm pretty certain this is the crash.
Comment 7 Brant Gurganus 2003-01-18 17:59:45 PST
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Comment 8 Jan Carpenter 2003-04-14 14:27:51 PDT
not very many crashes, and mostly by one user. marking topcrash- 

Recent stack:
 Stack trace(Frame) 

	 nsNntpCacheStreamListener::OnStartRequest()
[/builds/client/linux22/seamonkey/mozilla/mailnews/news/src/nsNNTPProtocol.cpp 
line 717] 
	 nsInputStreamPump::OnStateStart()
[/builds/client/linux22/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp
 line 354] 
	 nsInputStreamPump::OnInputStreamReady()
[/builds/client/linux22/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp
 line 319] 
	 nsInputStreamReadyEvent::EventHandler()  
	 PL_HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/xpcom/threads/plevent.c  line 659] 
	 PL_ProcessPendingEvents()
[/builds/client/linux22/seamonkey/mozilla/xpcom/threads/plevent.c  line 594] 
	 nsEventQueueImpl::ProcessPendingEvents()
[/builds/client/linux22/seamonkey/mozilla/xpcom/threads/nsEventQueue.cpp  line 391] 
	 event_processor_callback()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsAppShell.cpp  line 194] 
	 our_gdk_io_invoke()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsAppShell.cpp  line 75] 
	 libglib-1.2.so.0 + 0xee00 (0x40289e00)  
	 libglib-1.2.so.0 + 0x104c8 (0x4028b4c8)  
	 libglib-1.2.so.0 + 0x10ad3 (0x4028bad3)  
	 libglib-1.2.so.0 + 0x10c6c (0x4028bc6c)  
	 libgtk-1.2.so.0 + 0x8d7f7 (0x401ac7f7)  
	 nsAppShell::Run()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsAppShell.cpp  line 336] 
	 nsAppShellService::Run()
[/builds/client/linux22/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp
 line 479] 
	 main1()
[/builds/client/linux22/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line
1657] 
	 main()
[/builds/client/linux22/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line
1642] 
	 libc.so.6 + 0x15a51 (0x403a3a51)   
Comment 10 David :Bienvenu 2004-09-23 10:32:44 PDT
I see a lot of these in current talkback queries.
Comment 11 Frank Wein [:mcsmurf] 2005-02-26 02:34:28 PST
Also see Bug 281212, it contains steps how to reproduce this bug (or at least
one variant of a nsNntpCacheStreamListener::OnStartRequest crasher).
Comment 12 Wayne Mery (:wsmwk, NI for questions) 2007-08-09 06:30:58 PDT
low on the 2.0.0.6 list, currently #88 in talkcback

TB34590930 doing... "Absolutely nothing. Computer was locked and thunderbird was inactive (open on a newsgroup page). This install was only upgraded to 2.0.0.6 in the last hour. Thunderbird has never crashed before on this machine.

nsNntpCacheStreamListener::OnStartRequest  [mozilla/mailnews/news/src/nsNNTPProtocol.cpp, line 659]
nsInputStreamPump::OnStateStart  [mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 442]
nsOutputStreamReadyEvent::EventHandler  [mozilla/xpcom/io/nsStreamUtils.cpp, line 121]

interesting... TB34298317 "going offline and reading news posts" 

one more: TB34397104 
Comment 14 David :Bienvenu 2008-12-22 11:34:20 PST
seems possible this has to do with the changes to the way nntp does connection caching... bug 66150 - I'll look for this crash. I haven't seen it myself
Comment 15 Wayne Mery (:wsmwk, NI for questions) 2008-12-29 16:10:43 PST
bp-1bd8d97c-8241-4d71-b14e-7479a2081224 has a comment "when connecting a news group, I click the "go offline" button, then it crashes
Comment 16 Magnus Melin 2009-01-02 10:06:03 PST
I crashed with bp-410922bb-93a2-46e7-b702-ba5972090102.

That's on mChannelToUse->GetLoadGroup(getter_AddRefs(loadGroup));

Should we just null check mChannelToUse?
Comment 17 Ludovic Hirlimann [:Usul] 2009-03-10 03:07:52 PDT
http://crash-stats.mozilla.com/report/index/d792ecfb-2348-4333-922f-6733a2090306 "Checking the failing^Hmailing list for news.php.net which frequently times out."

Would be nice to fix this for TB3. This is topcrash #20 for TB3.0b2
Comment 18 Wayne Mery (:wsmwk, NI for questions) 2009-05-12 09:50:00 PDT
#13 crash in 3.0b3pre
Comment 19 Thomas Stache 2009-07-20 01:36:17 PDT
I crashed twice in that method in the last 30 minutes reading news on news.mozilla.org (using "N" goto next unread message)

incidents:
http://crash-stats.mozilla.com/report/index/9335f28c-e789-4a30-847c-2991e2090720
http://crash-stats.mozilla.com/report/index/7b2637db-ed68-470d-ba3a-2ebf52090720?p=1

and a while ago the same:
http://crash-stats.mozilla.com/report/index/3cfca427-1b8b-4398-a137-799072090715
Comment 20 Robert Kaiser (not working on stability any more) 2009-07-24 16:26:53 PDT
*** Bug 506257 has been marked as a duplicate of this bug. ***
Comment 21 Robert Kaiser (not working on stability any more) 2009-07-24 16:33:24 PDT
bp-b7963bd8-3726-42cc-95f2-29c922090722 has a user comment:
"i guess i was traversing thru a newsgroup with large number of headers > 500 very quickly with 'T' for marking thread as reading and moving to next thread. mail was open in 2nd tab."

Bug 506257 states it's reproduceable by "switching through the news pressing Space for about 10-20 seconds" and provides those crash IDs on SeaMonkey 2.0 Beta 1:
bp-026c4afa-e569-4aba-962f-f59032090724
bp-5d3f40a5-023e-49c5-b9cf-cb8282090724
bp-285275dc-dc20-4319-816c-77d9d2090724

Currently that signature is #13 topcrasher for Thunderbird 3.0 Beta 3:
http://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/3.0b3

Here's a Mac stack, so it's happening on all platforms: bp-dd29e64d-f474-4f4c-a7c3-b10592090723

SeaMonkey 2.0 Beta 1 shows it as #10 topcrasher right now: http://crash-stats.mozilla.com/topcrasher/byversion/SeaMonkey/2.0b1
Comment 22 stefan.blumenrath 2009-07-24 16:53:12 PDT
Hi,
I was the one with the space key on a xp system using an external news server.
I tried to reproduce it with my local hamster, a local news server.
SM did not crash but was busy for about one minute (netbook),
Hamster is set to allow 100 NNTP connections (instead of 4) per user due to errors i recieved due to this Bug ... recursion sucks...
Is there some testing that can be done?
Comment 23 David :Bienvenu 2009-07-24 17:47:31 PDT
Created attachment 390596 [details] [diff] [review]
possible fix

I hit this crash once, and these two checks should fix the crash I saw...
Comment 24 neil@parkwaycc.co.uk 2009-07-25 14:36:05 PDT
Comment on attachment 390596 [details] [diff] [review]
possible fix

nsNntpCacheStreamListener::OnStartRequest(nsIRequest *request, nsISupports * aCtxt)
Why does it only go wrong in OnStartRequest?

How are we getting to OnStartRequest before we're initialised?
Comment 25 David :Bienvenu 2009-07-25 16:49:57 PDT
I'm not sure what's happening, actually. It's hard to reproduce this crash, so it's hard to debug it.
Comment 26 stefan.blumenrath 2009-07-27 03:25:16 PDT
Yesterday i tried and found SM crashing by pressing space once again (no, this time it was curiosity that killed the ...seamonkey).
This time i took a lokal nntp-server, i had around 92 open connections from SM to to my NNTP-server, SM was busy for a minute and crshed.

bp-0eb43fa6-e3c6-4eba-b774-6ea122090408
Im sorry i can't convice my neighbours to do some testing by now...
Comment 27 stefan.blumenrath 2009-07-27 03:53:17 PDT
It might be useful if SM could forget about the headers i've clicked when i decided for the last header to read the message...
btw. i read news in online mode, having the header loaded. 
So every time a header is clicked, the 'load message' command gets to a cache, right? Might it be useful to reduce this cache to a number of 1 so only one maessage is loaded?


## about:me
The only programs i ever wrote,were Sinclair BASIC and PASCAL in school, and C looks very mystic to me, sorry. But i'll try to do a little more testing from time to time, lot of headache, lot of time...
Comment 28 Joshua Cranmer [:jcranmer] 2009-07-27 16:13:22 PDT
(In reply to comment #27)
> It might be useful if SM could forget about the headers i've clicked when i
> decided for the last header to read the message...
> btw. i read news in online mode, having the header loaded. 
> So every time a header is clicked, the 'load message' command gets to a cache,
> right? Might it be useful to reduce this cache to a number of 1 so only one
> maessage is loaded?

That would be a result as bug 424148 (which may be a duplicate of an older bug), which is simply a result of us failing to cancel the message loads in the URI. We do have a memory cache (in addition to the offline cache, of course), but the existence or lack thereof isn't causing the problem you specifically are seeing (we'd still load the message anyways).
Comment 29 David :Bienvenu 2009-08-04 07:42:01 PDT
pinging for review
Comment 30 Wayne Mery (:wsmwk, NI for questions) 2009-08-12 12:11:31 PDT
update crash sig for crash-stats to nsNntpCacheStreamListener::OnStartRequest(nsIRequest*, nsISupports*)
Comment 31 Ludovic Hirlimann [:Usul] 2009-09-16 04:54:32 PDT
First crash for b4 had this signature :-)
Comment 32 David :Bienvenu 2009-09-16 14:51:12 PDT
yes, for some reason, I'm not getting traction on the null check fix review requests...
Comment 33 Joshua Cranmer [:jcranmer] 2009-09-16 17:21:53 PDT
(In reply to comment #32)
> yes, for some reason, I'm not getting traction on the null check fix review
> requests...

I asked on IRC about why the checks were only in OnStartRequest and not in OnStopRequest as well and never really got an answer on that... Unfortunately, it seems that the one hour of missing logs corresponds to the hour I asked the question :-( .
Comment 34 Wayne Mery (:wsmwk, NI for questions) 2009-10-21 09:12:42 PDT
#14 crash for 3.0b4

bsmedberg is affected occasionally, eg http://crash-stats.mozilla.com/report/index/b3708bfc-6d0e-4b80-9165-09b992090924
Comment 35 David :Bienvenu 2009-10-22 06:18:24 PDT
I can add a check to OnStopRequest, though I never hit a case where mChannelToUse was null there...I got your question and Neil's confused. I don't know the answer to Neil's question.
Comment 36 David :Bienvenu 2009-10-22 10:57:34 PDT
Created attachment 407795 [details] [diff] [review]
check for null channel in both start and stop request
Comment 37 neil@parkwaycc.co.uk 2009-10-25 15:04:53 PDT
Comment on attachment 407795 [details] [diff] [review]
check for null channel in both start and stop request

sr=me if you add in plenty of assertions to remind us that the underlying cause of this bug has not been fixed.
Comment 38 David :Bienvenu 2009-10-26 13:57:24 PDT
Created attachment 408464 [details] [diff] [review]
fix for landing

this is what I'll check in - adds some assertions.
Comment 39 David :Bienvenu 2009-10-26 15:08:12 PDT
fixed on trunk and branch
Comment 40 stefan.blumenrath 2009-12-16 00:59:01 PST
OK, SM2.0.1 doesn't crash anymore when i switch fast through the news BUT after going fast through the news, SM won't display any message instead of crashing.  When this happens 'download chosen message' (in german 'gewählte Nachrichten abrufen') doesn't do so.

Note You need to log in before you can comment on or make changes to this bug.