Closed Bug 361773 Opened 13 years ago Closed 13 years ago

Crash [@ nsXMLHttpRequest::StreamReaderFunc]


(Core :: DOM: Core & HTML, defect, critical)

Not set





(Reporter: stevee, Assigned: mats)




(Keywords: crash, regression, testcase)

Crash Data


(5 files, 1 obsolete file)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061124 Minefield/3.0a1 ID:2006112404 [cairo]

1. New profile, start firefox
2. Load
3. Click on a link on the left hand side, under 'XML News Aggrigator'
4. Crash!


Incident ID: 26448788
Stack Signature	nsXMLHttpRequest::StreamReaderFunc 3da4e921
Product ID	FirefoxTrunk
Build ID	2006112404
Trigger Time	2006-11-24 12:43:46.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	firefox.exe + (00164897)
URL visited
User Comments profile 2. load url 3. click link on left hand side 4. crash!
Since Last Crash	15185 sec
Total Uptime	15185 sec
Trigger Reason	Access violation
Source File, Line No.	e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\content\base\src\nsxmlhttprequest.cpp, line 1170
Stack Trace 	
nsXMLHttpRequest::StreamReaderFunc  [mozilla\content\base\src\nsxmlhttprequest.cpp, line 1170]
nsInputStreamTee::WriteSegmentFun  [mozilla\xpcom\io\nsinputstreamtee.cpp, line 103]
nsPipeInputStream::ReadSegments  [mozilla\xpcom\io\nspipe3.cpp, line 764]
nsInputStreamTee::ReadSegments  [mozilla\xpcom\io\nsinputstreamtee.cpp, line 157]
nsXMLHttpRequest::OnDataAvailable  [mozilla\content\base\src\nsxmlhttprequest.cpp, line 1201]
nsStreamListenerTee::OnDataAvailable  [mozilla\netwerk\base\src\nsstreamlistenertee.cpp, line 97]
nsHttpChannel::OnDataAvailable  [mozilla\netwerk\protocol\http\src\nshttpchannel.cpp, line 4118]
nsInputStreamPump::OnStateTransfer  [mozilla\netwerk\base\src\nsinputstreampump.cpp, line 503]
nsInputStreamPump::OnInputStreamReady  [mozilla\netwerk\base\src\nsinputstreampump.cpp, line 394]
nsOutputStreamReadyEvent::Run  [mozilla\xpcom\io\nsstreamutils.cpp, line 112]
NS_ProcessNextEvent_P  [mozilla\xpcom\build\nsthreadutils.cpp, line 225]
nsXULWindow::ShowModal  [mozilla\xpfe\appshell\src\nsxulwindow.cpp, line 402]
nsContentTreeOwner::ShowAsModal  [mozilla\xpfe\appshell\src\nscontenttreeowner.cpp, line 503]
Exception is thrown in a dialog as firefox goes down:

[Exception... "Component returned failure code: 0x804b000f [nsIXMLHttpRequest.setRequestHeader]" nsresult: "0x804b000f (<unknown>)" location: "JS frame :: :: sendReq :: line 232" data: no]
Website works fine on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/2006112405 BonEcho/, so this is a regression.
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060504 Minefield/3.0a1 ID:2006050405 [cairo]

Busted (No actual crash, but continual exception throwing in dialog):
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060505 Minefield/3.0a1 ID:2006050511 [cairo]
Attached file testcase (obsolete) —
This crashes for me when loading.
Ok, to get the crash, you need to download the testcase locally and then change this:'get', '', true);
into this:'get', window.location, true);

And with testcase, it makes clear that the regression range from comment 5 is incorrect also (sorry, will look for it further in a little while).
Attached file updated testcase
Ok, the crash regression range is between 2006-05-09 and 2006-05-10, so that makes it very likely to be a regression from bug 326273 (the threadmanager patch).
Attachment #246524 - Attachment is obsolete: true
Attached file (part of Tetstcase #2)
Attached file Testcase #2
(Martjin's testcase have the basically the same trace data too)
Attached patch wipSplinter Review
This fixes the crash for all the testcases + URL.
The URL and Martjin's testcase still generates infinite recursive loads, but
they are limited by the JS engine after while:
"JavaScript error: , line 0: too much recursion"
Keywords: testcase
OS: Windows 2000 → All
The reason the URL works in IE7 is that the onreadystatechange handler
(load_item() in this case) is called without arguments, so for one
link click in IE7 we have:
1st call to load_item: from the onclick handler of the link ('id' is non-null
                       and indicates which link it is)
2nd call to load_item: 'id' is null. (readyState==2)
3nd call to load_item: 'id' is null. (readyState==3)
4th call to load_item: 'id' is null. (readyState==4)

In Firefox we call the onreadystatechange handler with the event as
argument, which is why load_item() opens new URLs ad infinitum.
Build 2006-05-04-04 and earlier does not call an onreadystatechange handler
or load handler at all. I guess bug 198595 and/or bug 312213 fixed that 
(they were checked in at the same time).

The remaining problem with the recursive loading of new URLs could be
Evangelism, depending on how compatible we want to be...
(I got the site working locally so it shouldn't be hard to fix.)
Attachment #246534 - Flags: review?(bzbarsky)
(In reply to comment #13)
> The remaining problem with the recursive loading of new URLs could be
> Evangelism, depending on how compatible we want to be...
> (I got the site working locally so it shouldn't be hard to fix.)

Yeah, the remaining problem was filed as bug 361811.

Comment on attachment 246534 [details] [diff] [review]

Seems reasonable, yeah.  Nice catch!  r+sr=bzbarsky
Attachment #246534 - Flags: superreview+
Attachment #246534 - Flags: review?(bzbarsky)
Attachment #246534 - Flags: review+
Assignee: nobody → general
Component: General → DOM: Mozilla Extensions
QA Contact: general → ian
Assignee: general → mats.palmgren
Flags: blocking1.9?
Checked in to trunk at 2006-11-28 05:56 PST

Closed: 13 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Crash Signature: [@ nsXMLHttpRequest::StreamReaderFunc]
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.