61386 - N601 crash #2 [@ nsHTTPPipelinedRequest::GetCurrentRequest]

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P3)

Description

[Jay Patel [:jay]]

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

Comment 1

[Jay Patel [:jay]]

adding crash, topcrash keywords and [@ nsHTTPPipelinedRequest::GetCurrentRequest]
 for tracking.

Comment 2

[Gagan]

http bugs to "Networking::HTTP"

Comment 3

[Jay Patel [:jay]]

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"

Comment 4

[Scott Gifford (old account)]

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

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack traces for all but one of the talkback IDs Scott Gifford mentioned

Comment 7

[Darin Fisher]

Attachment: adds null check to avoid the crash

Comment 8

[Darin Fisher]

neeti, can you review this patch.  it'd be nice to at least get this in there
to avoid the crash.  thanks!

Comment 9

[Scott Gifford (old account)]

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.

Comment 10

[Scott Gifford (old account)]

Attachment: Latest crash backtraces

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 12

[Scott Gifford (old account)]

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.

Comment 13

[Scott Gifford (old account)]

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

[neeti]

r=neeti

Comment 15

[Scott MacGregor]

sr=mscott

Comment 16

[Darin Fisher]

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!

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is bug 58728 really the same?

Comment 18

[Darin Fisher]

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.

Comment 19

[Jay Patel [:jay]]

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

Comment 20

[Jay Patel [:jay]]

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.

Comment 21

[Darin Fisher]

I don't believe this patch made its way into the 6.01 release :(

Comment 22

[Darin Fisher]

Reopening to track landing this patch on the N6 branch.

Comment 23

[Darin Fisher]

Marking FIXED (again)... seems the 6.0 branch is dead.

Comment 24

[John Unruh]

The latest stack trace of nsHTTPPipelinedRequest::GetCurrentRequest in climate
is build 2001013114. Verified fixed.