Closed Bug 241947 Opened 20 years ago Closed 19 years ago

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

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.8beta5

People

(Reporter: dmclean, Assigned: darin.moz)

References

Details

(Keywords: crash)

Crash Data

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).
Please try it with 1.7RC1 and post a Talkback ID from the crash.
TB33040X
IS this ID from RC1 ?
The talkback server can't find the ID :-(
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.
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?
 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)
Assignee: general → darin
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
Keywords: crash
QA Contact: general → benc
I have seen this stack trace before.  I think timeless has seen it too.
Status: NEW → ASSIGNED
Summary: Crashes while using browser interface to read my "netscape.net" email → [crash @nsInputStreamPump::OnStateStop] Crashes while using browser interface to read my "netscape.net" email
Target Milestone: --- → mozilla1.8alpha
Flags: blocking1.7?
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.
yeah, that looks familiar, but i haven't seen it w/in the past week.
Summary: [crash @nsInputStreamPump::OnStateStop] Crashes while using browser interface to read my "netscape.net" email → crash [@ nsInputStreamPump::OnStateStop] Crashes while using browser interface to read my "netscape.net" email
TB40057H

Should I continue to submit Talkback IDs?
TB41043G
TB44245Z
TB41144X
TB43812X
TB44609W
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.
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).
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
jay: yes, i suspect that is a duplicate crash report.
Flags: blocking1.7? → blocking1.7+
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?
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?
ok, renominate if anyone comes up with something that gives us more to go on for 1.7
Flags: blocking1.7+ → blocking1.7-
I haven't noticed any particular pattern - other than it was always and only on
the one site.
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.
Target Milestone: mozilla1.8alpha1 → mozilla1.8beta
Blocks: 252328
can anyone reproduce this crash using firefox 1.0 or mozilla 1.7.5?
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.
Priority: -- → P1
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2
Target Milestone: mozilla1.8beta2 → mozilla1.8beta5
Flags: blocking1.8rc1?
not showing up in the early branch talkback data at all.
Flags: blocking1.8rc1? → blocking1.8rc1-
marking WORKSFORME based on talkback data.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsInputStreamPump::OnStateStop]
You need to log in before you can comment on or make changes to this bug.