241947 - crash [@ nsInputStreamPump::OnStateStop] Crashes while using browser interface to read my "netscape.net" email

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P1)

Description

[Donald F. McLean]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421

I have one of Netscape's free email accounts and I use Mozilla to read the email
using their browser interface. In both 1.6 and 1.7rc1, I see crashes on a
semi-regular basis (two just this morning) while reading my email on this site.
This is the only site that I access that seems to have this problem.

Reproducible: Sometimes
Steps to Reproduce:
1. Get a "netscape.net" account.
2. Log in using their browser interface.
3. Read email messages.

Actual Results:  
Sometimes it works perfectly, sometimes it crashes.


This happens both at work (Windows 2000) and at home (Windows XP).

Comment 1

[Matthias Versen [:Matti]]

Please try it with 1.7RC1 and post a Talkback ID from the crash.

Comment 2

[Donald F. McLean]

TB33040X

Comment 3

[Matthias Versen [:Matti]]

IS this ID from RC1 ?
The talkback server can't find the ID :-(

Comment 4

[Donald F. McLean]

The talkback tool says that it was sent. Too bad it won't let me resend it.

When it happens again, I'll post that ID.

Comment 5

[Donald F. McLean]

TB38165X

I'm running 1.7RC1 on Win 2000.

I tried to look this ID up and couldn't find it. Either I don't know where to
look it up or talkback is misbehaving. Any thoughts?

Comment 6

[Asa Dotzler [:asa]]

 0x03168217
nsInputStreamPump::OnStateStop
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 499]
nsInputStreamPump::OnInputStreamReady
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 340]
nsInputStreamReadyEvent::EventHandler
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpcom/io/nsStreamUtils.cpp,
line 215]
PL_HandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 674]
PL_ProcessPendingEvents
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 612]
_md_EventReceiverProc
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 1415]
nsAppShellService::Run
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 524]
main1
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1313]
main
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1783]
WinMain
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1809]
WinMainCRTStartup()
KERNEL32.DLL + 0x11af6 (0x7c581af6)

Comment 7

[Darin Fisher]

I have seen this stack trace before.  I think timeless has seen it too.

Comment 8

[Darin Fisher]

Since the last address on the call stack is bogus (0x03168217), and the source
line corresponds to:

  mAsyncStream->Close();

I suspect that mAsyncStream is pointing to a bad address.  It seems the object
has already been destroyed.  A simple NULL check probably wouldn't help here.

Comment 9

[timeless]

yeah, that looks familiar, but i haven't seen it w/in the past week.

Comment 10

[Donald F. McLean]

TB40057H

Should I continue to submit Talkback IDs?

Comment 11

[Donald F. McLean]

TB41043G

Comment 12

[Donald F. McLean]

TB44245Z

Comment 13

[Donald F. McLean]

TB41144X
TB43812X
TB44609W

Comment 14

[Matthias Versen [:Matti]]

One TB ID is enough if we get a stack trace and we got a stack trace with
comment #6. Please stop posting TB ID's unless the developer needs more.

Comment 15

[Donald F. McLean]

Ok - I did ask, though (in #10).

One thing that I thought that I'd mention. I don't know if it makes any
difference, but I have the same problem on my WinXP machine at home (the
talkback ids in #13 are from that machine).

Comment 16

[Jay Patel [:jay]]

Darin:  There are a few crashes in Talkback data with
nsHttpChannel::OnStopRequest as the stack signature and pretty much the same
stack as this bug.   Let me know if it's the same crash so we can add that stack
signature to the summary for tracking (or if it's not the same, I can log a new
bug).  Thanks.

Here is one of the incidents I'm referring to:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=46933

Comment 17

[Darin Fisher]

jay: yes, i suspect that is a duplicate crash report.

Comment 18

[chris hofmann]

jay, can you see if you can figure out if any of the recent mozilla releases are
in worst shape that 1.4 based releases on netscape.net web mail?

Comment 19

[Jay Patel [:jay]]

I don't see any webmail related crashes in old 1.4 Talkback data, although there
were a few crashes in nsHttpChannel::OnStopRequest for users doing other things.
 There aren't many of these crashes in recent Mozilla 1.7 rc2 data.

It looks like most of the recent webmail crashes are from the same user (the
reporter here).  So I wonder if it's a particular email message that is causing
this crash?

Donald:  Are you crashing randomly or when reading certain emails?  Are they in
plaintext or html?

Comment 20

[chris hofmann]

ok, renominate if anyone comes up with something that gives us more to go on for 1.7

Comment 21

[Donald F. McLean]

I haven't noticed any particular pattern - other than it was always and only on
the one site.

Comment 22

[Patrick Zesar]

this happened to me with firefox 0.9 and 0.9.1 two times in the last few days at
the same site: http://derstandard.at - an important news site in austria (and
only on this one site). there have been issues with this site before, but never
crashes. i never experienced this crash with FF 0.8 or older.

the first talkback ID is 198730
the second one is not processed yet

i tried everything i could think of to reproduce it but did not succeed.

Comment 23

[Darin Fisher]

can anyone reproduce this crash using firefox 1.0 or mozilla 1.7.5?

Comment 24

[Darin Fisher]

talkback indicates that this crash is present in firefox 1.0.  it may have been
fixed on the trunk, but keeping open just in case.

Comment 25

[Asa Dotzler [:asa]]

not showing up in the early branch talkback data at all. 

Comment 26

[Darin Fisher]

marking WORKSFORME based on talkback data.