N601 crash #2 [@ nsHTTPPipelinedRequest::GetCurrentRequest]

VERIFIED FIXED

Status

()

P3
critical
VERIFIED FIXED
18 years ago
10 years ago

People

(Reporter: jay, Assigned: darin.moz)

Tracking

({crash, topcrash})

Trunk
x86
All
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
This is the #3 topcrasher for the official RTM build for Windows.  Another bug
49500 covers a similar crash for Linux, I wasn't sure if it was the same
problem, so I'm loggin this bug.  Here is the stack trace:

Incident ID 21916396
nsHTTPPipelinedRequest::GetCurrentRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPRequest.cpp, line 1120]
nsHTTPServerListener::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cpp,
line 653]
nsOnStartRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 213]
nsStreamListenerEvent::HandlePLEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 581]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 517]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1051]
KERNEL32.DLL + 0x248f7 (0xbff848f7)
0x00658b52
0x00058f64
0xffffffff

I have been unable to reproduce, but here are a list of URLs mentioned by users
and a few entries with some user comments:

http://www.telepolis.com
http://www.msn.com
www.demonews.com
ww4.janus.com
www.netscape.com/webmail
www.iseekpasswords.com
http://www.vgmusic.com
http://www.yahoo.com

--------------
CrashDate: 2000-11-27 UptimeMinutes: 1438  Total: 2718 OS: Windows 98  4.10
build 67766222
	 Incident ID: http://climate/reports/stackcommentemail.cfm?dynamicBBID=21843227
Comment: I had searched for clipart in Yahoo.  I selected one of the results and
windows started opening up.  I closed them as fast as I could but they kept
opening.  Finally crashed netscape.
--------------
CrashDate: 2000-11-26 UptimeMinutes: 421  Total: 421 OS: Windows 98  4.10 build
67766446
	 Incident ID: http://climate/reports/stackcommentemail.cfm?dynamicBBID=21867793
URL: i forget
	 Comment: it asked me to do something with the java plug in
---------------
CrashDate: 2000-11-27 UptimeMinutes: 326  Total: 524 OS: Windows 98  4.10 build
67766446
	 Incident ID: http://climate/reports/stackcommentemail.cfm?dynamicBBID=21887775
URL: Netscape Plugin Finder
----------------
CrashDate: 2000-11-27 UptimeMinutes: 206  Total: 790 OS: Windows 95  4.0 build
67109975
	 Incident ID: http://climate/reports/stackcommentemail.cfm?dynamicBBID=21889913
URL: netscape 6
	 Comment: i was reading my email and as usual netscape web mail screwed it up
----------------
CrashDate: 2000-11-27 UptimeMinutes: 235  Total: 235 OS: Windows 95  4.0 build
67109975
	 Incident ID: http://climate/reports/stackcommentemail.cfm?dynamicBBID=21900097
URL: http://www.att.com/ucs/ Comment: Trying to access my AT&T credit card info
(Reporter)

Comment 1

18 years ago
adding crash, topcrash keywords and [@ nsHTTPPipelinedRequest::GetCurrentRequest]
 for tracking.
Keywords: crash, topcrash
(Reporter)

Updated

18 years ago
Summary: RTM crash [@ nsHTTPPipelinedRequest::GetCurrentRequest] → RTM crash #3 [@ nsHTTPPipelinedRequest::GetCurrentRequest]

Comment 2

18 years ago
http bugs to "Networking::HTTP"
Assignee: gagan → darin
Component: Networking → Networking: HTTP
Target Milestone: --- → M19
(Reporter)

Comment 3

18 years ago
This crash is also the #3 topcrash for the RTM release on Linux.  Here are some
URLs and Comments from user talkback reports:

URL:(23135611) register.com
Comment: (23135611) I hit a link to an insecure document from a secure document.
 The secure document may have been stale. Idunno.

URL:(23147087) www.java.sun.com
Comment: (23147087) cancelling installation of Java plug-in

URL:(23153010) www.nyt.com
Comment: (23153010) browsing the nyt tech section

URL:(23168235) www.realplayer.com
URL:(23171841) http://mail.yahoo.com/

Comment: (23129271) trying to access "enable javascript" from "preferences" so
that I could enable javascript. the "javascript" choice does not appear when I
click on"advanced" under "preferences"  there are other choices such as"cookies"
or "cache"



I am fairly consistently able to reproduce this crash on my Linux system, using
TalkBalk Build 2001011208.  Crashes are logged by TalkBalk with Incident IDs
TB24628054Z, TB24627541W, TB24627239X, TB24696077X, and TB24696620M.  I'll
attach a copy of a stack trace from the last of these crashes (TB24696077X).

I originally thought this was a part of bug #63243, so there is a bit more
information there.

My configuration is a completely stock Mozilla installation, with no plugins at
all (save for the "libnullplugin.so" plugin that apparently comes with Mozilla).
 I'm clearing my cache, then shutting down Mozilla and starting up a new copy. 
Then I'm going through a list of URLs serially, middle-clicking on each link,
waiting for the page to load (pressing STOP and RELOAD if it seems stuck or has
almost nothing on it), then closing the new window and continuing on to the next
one in the list.  If a window pops up asking me to install a plugin, I hit
cancel, sometimes waiting 5-10 seconds, depending on how much attention I'm paying.

  At different points in this list, Mozilla will crash.  It seems to make it
further through the list each time I test it, although I've never made it all
the way through.

  Here's the list (from bug #63243):

http://osdn.com/
http://www.msnbc.com
http://search.perl.com/
http://www.zdnet.com/eweek
http://home.excite.com
http://www.kinigadner.com/intro.html
http://www.siemens.com
http://www.kiss.fi/
http://www.bestmat.be/en/occasbe.html
http://www.xdrive.com/target.html?path=/company/main_download.html
http://www.scee.com
http://www.real.com
http://www.vizzavi.co.uk
http://www.lge.com.au/
http://www.maximonline.com
http://www.m-w.com
http://www.tellium.com
http://cnnfn.cnn.com/2001/01/08/technology/wires/ibm_translate_wg
http://www.thecounter.com/stats/2000/
http://ntv.ru

Looking at the stack, I'd have to guess that the cause for the crash is that the
nsHTTPPipelinedRequest has been deleted.  (Since GetCurrentRequest isn't
virtual, we could enter it without crashing, but nsISupportsArray::Count is
virtual so we'd crash there.)

The nsHTTPServerListener holds a weak reference in mPipelinedRequest.  What
ensures that this object doesn't get deleted?
Created attachment 23006 [details]
stack traces for all but one of the talkback IDs Scott Gifford mentioned
(Assignee)

Comment 7

18 years ago
Created attachment 23015 [details] [diff] [review]
adds null check to avoid the crash
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 8

18 years ago
neeti, can you review this patch.  it'd be nice to at least get this in there
to avoid the crash.  thanks!
With this patch applied, it seems more stable.  I can make it much further
through my list, but I still haven't made it all the way through.  It crashes in
a different place, though.

I can see where the patch seems to come into effect, because pressing back won't
quite display the right thing (maybe one frame will change and another will
not).  So the problem that is causing the null pointer to exist is still there.
 It may be worth printing something if we find the null pointer, so there is a
better chance of somebody finding the code path that causes this pointer to be null.

I'll attach backtraces from my most recent crash; if you think they are
unrelated, let me know and I'll put them in a new bug.
Created attachment 23072 [details]
Latest crash backtraces
That latest crash and most of the talkback reports you mentioned are bug 65800.
Please try the patch there to see if it helps, and comment there as well.
Blocks: 66164
I applied the null check patch, and am now just seeing bug 65800.  The patch
there pushes the problem to 51384.

I created bug 66164 to keep track of the various problems this list of URLs
seems to be triggering.
With a recent CVS update from 1/22/2001, the patch from this bug, and the patch
from bug 61756, I'm no longer able to get Mozilla to crash using the procedure
in bug 66164.

Comment 14

18 years ago
r=neeti

Comment 15

18 years ago
sr=mscott
(Assignee)

Comment 16

18 years ago
Looks like gagan beat me to it with his fix for bug 58728.  So, the null
check patch is in place.  Marking FIXED, adding keyword verifyme.

tever: can you verify that this is fixed.  thx!
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Keywords: verifyme
Resolution: --- → FIXED
(Assignee)

Comment 18

18 years ago
Take a look at the CVS blame logs for nsHTTPResponseListener.cpp... you will see
that gagan already took care of this bug in his patch for bug 58728.
(Reporter)

Comment 19

18 years ago
changing summary to N601.  this crash is still happening with N601, it's the #2
topcrasher.  here is the latest stack trace.  reopening.

nsHTTPPipelinedRequest::GetCurrentRequest   430 	 61386 	 RESO 	 FIXE
     First BBID :
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=26104133 Last BBID  :
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=26578337 Min Runtime :32
     Max Runtime :16252845
     Min seconds since last crash :32
     Max seconds since last crash :241467
     First Appearance Date : 2001-02-10
     Last Appearance Date : 2001-02-19

Stack Trace:

	 nsHTTPPipelinedRequest::GetCurrentRequest
[d:\builds\6.01\mozilla\netwerk\protocol\http\src\nsHTTPRequest.cpp  line 1120]
	 nsHTTPServerListener::OnStartRequest
[d:\builds\6.01\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cpp
line 653]
	 nsOnStartRequestEvent::HandleEvent
[d:\builds\6.01\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp  line 213]
	 nsStreamListenerEvent::HandlePLEvent
[d:\builds\6.01\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp  line 106]
	 PL_HandleEvent
[d:\builds\6.01\mozilla\xpcom\threads\plevent.c  line 581]
	 PL_ProcessPendingEvents
[d:\builds\6.01\mozilla\xpcom\threads\plevent.c  line 517]
	 _md_EventReceiverProc
[d:\builds\6.01\mozilla\xpcom\threads\plevent.c  line 1051]

 	Source File : d:/builds/6.01/mozilla/netwerk/protocol/http/src/nsHTTPRequest.cpp
line : 1120
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: RTM crash #3 [@ nsHTTPPipelinedRequest::GetCurrentRequest] → N601 crash #2 [@ nsHTTPPipelinedRequest::GetCurrentRequest]
(Reporter)

Comment 20

18 years ago
Woops...I should have just left this resolved fixed...making it so again.
Someone still needs to verify this with the latest trunk builds though...and it
should be noted that this is a huge problem with N601 release.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 21

18 years ago
I don't believe this patch made its way into the 6.01 release :(
(Assignee)

Comment 22

18 years ago
Reopening to track landing this patch on the N6 branch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 23

18 years ago
Marking FIXED (again)... seems the 6.0 branch is dead.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 24

16 years ago
The latest stack trace of nsHTTPPipelinedRequest::GetCurrentRequest in climate
is build 2001013114. Verified fixed.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh

Updated

10 years ago
Keywords: verifyme
Crash Signature: [@ nsHTTPPipelinedRequest::GetCurrentRequest]
You need to log in before you can comment on or make changes to this bug.