75633 - Ref. to non-existent "chrome://" stylesheet in XBL or XUL file, causes crash M092, Trunk & N610 [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[John Morrison]

This is a followup to (or rebirth of) bug 72081. That bug was about
mutation events, but it turns out that simply specifying an non-existent
stylesheet in an XBL binding.xml file will result in a crash somewhere
below the XML content sink. Guessing nisheeth, but may be in need of 
serious re-education.

The example, which I'll attach as a .zip, is this:

Note the reference to the non-existent stylesheet in the binding file.
Remove that, and the binding is correctly loaded.
 <?xml-stylesheet href="chrome://maths/skin/global.css" type="text/css"?>


-- test.xul -- 
<?xml version="1.0" ?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<?xml-stylesheet href="test.css" type="text/css"?>
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <mywidget/>
</window>


-- testbinding.xml --
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://maths/skin/global.css" type="text/css"?>
<?xml-stylesheet href="test.css" type="text/css"?>
<bindings 
  xmlns="http://www.mozilla.org/xbl"
  xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
	<binding id="mywidget" extends="xul:box" >
        <content>
            <xul:button label="I got label."/>
        </content>	
	</binding>
</bindings>


-- test.css --
mywidget
{
	-moz-binding: url(test-binding.xml#mywidget);
}




Stack, according to talkback:

nsProxyObjectManager::GetProxyForObject 
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyObjectManager.cpp, line 
193] 
nsStreamLoader::Init 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 59] 
NS_NewStreamLoader [..\..\..\..\dist\include\nsNetUtil.h, line 354] 
CSSLoaderImpl::LoadSheet 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1225] 
CSSLoaderImpl::LoadStyleLink 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1392] 
nsXMLContentSink::ProcessCSSStyleLink 
[d:\builds\seamonkey\mozilla\content\xml\document\src\nsXMLContentSink.cpp, 
line 1078] 
nsXMLContentSink::ProcessStyleLink 
[d:\builds\seamonkey\mozilla\content\xml\document\src\nsXMLContentSink.cpp, 
line 1009] 
nsXMLContentSink::AddProcessingInstruction 
[d:\builds\seamonkey\mozilla\content\xml\document\src\nsXMLContentSink.cpp, 
line
1252] 
CWellFormedDTD::HandleProcessingInstructionToken 
[d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 605] 
CWellFormedDTD::HandleToken 
[d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 521] 
CWellFormedDTD::BuildModel 
[d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 260] 
nsParser::BuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, 
line 2031] 
nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, 
line 1910] 
nsParser::OnDataAvailable 
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 2361] 
nsXBLStreamListener::OnDataAvailable 
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLService.cpp, line 273] 
nsFileChannel::OnDataAvailable 
[d:\builds\seamonkey\mozilla\netwerk\protocol\file\src\nsFileChannel.cpp, line 
503] 
nsOnDataAvailableEvent::HandleEvent 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp, line 
183] 
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 589] 
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, 
line 522] 
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, 
line 1070] 
nsAppShellService::Run 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 408] 
netscp6.exe + 0x16ec (0x004016ec) 
netscp6.exe + 0x11b8 (0x004011b8) 
netscp6.exe + 0x2c28 (0x00402c28) 
KERNEL32.DLL + 0x7903 (0x77e87903)

Comment 1

[John Morrison]

Attachment: stripped down version of Alex's original testcase (no mutation events)

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This does not happen with normal XML files, even if using chrome URLs. It also
does not happen if you have a XUL file that directly references a non-existing
CSS stylesheet.

Seems XBL specific, reassigning.

Comment 3

[Marc Attinasi]

*** Bug 74057 has been marked as a duplicate of this bug. ***

Comment 4

[Marc Attinasi]

bug 74057 was marked as a dup of this bug (same crash stack), however that bug 
was a topcrasher and had all kinds of urgency associated with it. I'm clearing 
the milestone so the 'future' can be reevaluated - also migrating the operative 
kwds from 74057.

Comment 5

[greer]

Rooting around in the M091 Offset reports shows 15 crashes (hiding under 
0x00000000) between 6/15 and 6/18 at the signature in the summary 
(nsProxyEventObject::GetNewOrUsedProxy). However, they are all on the 
2001060713 windows build. Not seeing it in the Trunk.

These are the M091 comments:
Comments: Reinstalling Netscape 6.1 after upgrade problems from 6.1
Comments: Just running it for the first time
Comments: attempted to launch browser... got to intro screen then crashed ("... 
generated errors")

And the latest stack for good measure:

0x00000000 
nsProxyEventObject::GetNewOrUsedProxy 
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEventObject.cpp, line 164] 
nsProxyObjectManager::GetProxyForObject 
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyObjectManager.cpp, line
202] 
nsStreamLoader::Init 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 59] 
NS_NewStreamLoader [..\..\..\dist\include\nsNetUtil.h, line 362] 
CSSLoaderImpl::LoadSheet 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1221] 
CSSLoaderImpl::LoadChildSheet 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1483] 
CSSParserImpl::ProcessImport 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSParser.cpp, line 987] 
CSSParserImpl::ParseImportRule 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSParser.cpp, line 934] 
CSSParserImpl::ParseAtRule 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSParser.cpp, line 803] 
CSSParserImpl::Parse 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSParser.cpp, line 565] 

Comment 6

[John Morrison]

*** Bug 88472 has been marked as a duplicate of this bug. ***

Comment 7

[John Morrison]

It was noted on bug Bug 88472 by [e-mail] that you could 
get this same crash with this testcase.

| Here's an entire XUL file that always crashes my browser when I load it:
|
| <?xml version="1.0"?>
| <?xml-stylesheet href="chrome://foo/bar/baz.css"?>
| <window/>

greer: what's the current frequency for this crash? Common or rare?

Comment 8

[greer]

John, in answer to your earlier question: this crash is no longer common.

Trunk reports from 7/2 show 6 occurrences all on or before 6/26. Five of the 
crashes are from a single user. A little further digging shows 3 incidents under 
0x00000000, all on 6/24

M091 shows 3 incidents from unique users on 6/29 and 6/30 under this 
signature.

We have no record of it happening since 6/30.

Comment 9

[greer]

An update from last night's comments:
This morning's Trunk reports (7/3/1) show several new incidents with this stack 
signature (20 incidents but 18 from a single user).

Comments from Trunk data:
     (32438369) Comments: this happens since i installed netscape6 pr1 ... after 
the installation i
cannot start mozilla anymore ... tried to install into a different directory but 
this didn't help either.don't know what causes the crash on start-up ... :-(
     (32437117) Comments: just tried to start it!
     (32197011) Comments: Messed around with the linktoolbar.jar rezipped it

M092 reports have 8 incidents from 6 unique users with these comments:

     (32404295) Comments: Trying to launch. Deleted JRE to no avail. Will there 
ever be a version that LAUNCHES on my win32 PC??? :(
     (32400799) Comments: Just tried to run mozilla. nothing more.
     (32383911) Comments: After starting on Win2000 crash (only view "mozilla" 
image). Version 0.9.1 working OK. Thanks

So it appears this crash is more common than I gave it credit for last night.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think I am seeing this too with a testcase from bug 75844. I'll attach the
testcase that produces the following stack...

Stack (Win2k):

nsProxyEventObject::GetNewOrUsedProxy(nsIEventQueue * 0x01103c90, int 6,
nsISupports * 0x03aa4b40, const nsID & {...}) line 162 + 38 bytes
nsProxyObjectManager::GetProxyForObject(nsProxyObjectManager * const 0x011ae1f0,
nsIEventQueue * 0x00000000, const nsID & {...}, nsISupports * 0x03aa4b40, int 6,
void * * 0x0012ed4c) line 200 + 26 bytes
nsStreamLoader::Init(nsStreamLoader * const 0x03aa2de0, nsIURI * 0x03aa1be0,
nsIStreamLoaderObserver * 0x03aa4b40, nsISupports * 0x00000000, nsILoadGroup *
0x03a44e20, nsIInterfaceRequestor * 0x00000000, unsigned int 0) line 58 + 61 bytes
NS_NewStreamLoader(nsIStreamLoader * * 0x0012ee18, nsIURI * 0x03aa1be0,
nsIStreamLoaderObserver * 0x03aa4b40, nsISupports * 0x00000000, nsILoadGroup *
0x03a44e20, nsIInterfaceRequestor * 0x00000000, unsigned int 0) line 378 + 47 bytes
CSSLoaderImpl::LoadSheet(URLKey & {...}, SheetLoadData * 0x03aa4b40) line 1217 +
38 bytes
CSSLoaderImpl::LoadStyleLink(CSSLoaderImpl * const 0x046415e0, nsIContent *
0x00000000, nsIURI * 0x03aa4940, const nsString & {""}, const nsString & {""},
int -1, int 2, nsIParser * 0x046412d0, int & 1, nsICSSLoaderObserver *
0x00000000) line 1396 + 22 bytes
XULContentSinkImpl::ProcessStyleLink(nsIContent * 0x00000000, const nsString &
{"chrome://xulmaker/content/xulmaker.css"}, int 0, const nsString & {""}, const
nsString & {"text/css"}, const nsString & {""}) line 868 + 123 bytes
XULContentSinkImpl::AddProcessingInstruction(XULContentSinkImpl * const
0x04641780, const nsIParserNode & {...}) line 943
CWellFormedDTD::HandleProcessingInstructionToken(CToken * 0x0304d6d8) line 606 +
31 bytes
CWellFormedDTD::HandleToken(CWellFormedDTD * const 0x03a9a160, CToken *
0x0304d6d8, nsIParser * 0x046412d0) line 522 + 12 bytes
CWellFormedDTD::BuildModel(CWellFormedDTD * const 0x03a9a160, nsIParser *
0x046412d0, nsITokenizer * 0x03a9a040, nsITokenObserver * 0x00000000,
nsIContentSink * 0x04641780) line 261 + 20 bytes
nsParser::BuildModel() line 2182 + 34 bytes
nsParser::ResumeParse(int 1, int 0) line 2053 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x046412d8, nsIRequest * 0x0463bab0,
nsISupports * 0x00000000, nsIInputStream * 0x0463fe80, unsigned int 0, unsigned
int 498) line 2517 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x0463a180,
nsIRequest * 0x0463bab0, nsISupports * 0x00000000, nsIInputStream * 0x0463fe80,
unsigned int 0, unsigned int 498) line 235 + 46 bytes
nsFileChannel::OnDataAvailable(nsFileChannel * const 0x0463bab8, nsIRequest *
0x0463b9a4, nsISupports * 0x00000000, nsIInputStream * 0x0463fe80, unsigned int
0, unsigned int 498) line 496 + 49 bytes
nsOnDataAvailableEvent::HandleEvent() line 175 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x0463f554) line 64
PL_HandleEvent(PLEvent * 0x0463f554) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x010cb900) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x001a07ba, unsigned int 49452, unsigned int 0,
long 17611008) line 1071 + 9 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
nsAppShellService::Run(nsAppShellService * const 0x0113a930) line 419
main1(int 2, char * * 0x00485f90, nsISupports * 0x00000000) line 1174 + 32 bytes
main(int 2, char * * 0x00485f90) line 1478 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e97d08()

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: testcase, XUL, xulmaker, save to disc and open (CRASH)

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Based on greer's comments about number of occurrencies, removing Future
milestone for re-evaluation.

Comment 13

[Jan Carpenter]

This is a topcrash on the N610 branch

Here's the only comment so far:
 (32415390)	Comments: I just tried to start mozilla!It crashes every time on start-up.

(Servers are shut down till Saturday, I'll have to get the stack trace Monday)

Comment 14

[Heikki Toivonen (remove -bugzilla when emailing directly)]

The startup crashes are probably due to some weird packages the users have
installed a long time ago, or they are installing on top of old installation
without cleaning the dir first (like if you copy files instead of running the
installer), or corrupted bits, or something else unusual going on. But since it
seems to be common, and causes crash at startup (effectively making it
impossible for these people to run the product) I really feel we should take a
whack at fixing this for RTM.

Comment 15

[basic]

Attachment: testcase served as xul

Comment 16

[Roger D]

I would suggest that we should:

a) detect that this has happened and not crash

b) warn the user that the installation of their browser and/or one or more of 
their themes may be corrupted and that they may need to do a clean reinstall. If 
we can tell them the chrome: URL of the CSS file was not found, and ideally also 
the URL of the XUL file which contained the bad reference, that would probably 
help them figure out what needs to be reinstalled.

c) (possibly) go ahead and attempt to display the XUL without the required CSS, 
in the hope that it may still be of some use to the user without the specified 
style information

Comment 17

[Pierre Saslawsky]

*** Bug 85559 has been marked as a duplicate of this bug. ***

Comment 18

[Jay Patel [:jay]]

Updating summary with M092, since this is a topcrasher for Mozilla 0.9.2.  I'm
sure this problem also continues to exist on the Trunk and N610 branch, but I
have not seen any crashes of this kind in the latest Talkback reports for those
builds.

Comment 19

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

Debugging by blake and jag led to the conclusion that this is a problem with 
the ownership model of nsStreamLoader.  The problem is that we end up with a 
failure that leads to the following stack:

SheetLoadData::OnStreamComplete(SheetLoadData * const 0x04a33820, 
nsIStreamLoader * 0x057f4cb0, nsISupports * 0x00000000, unsigned int 
2147500037, unsigned int 0, const char * 0x100c0bd0 gCommonEmptyBuffer) line 604
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x057f4cb4, nsIRequest * 
0x057cb758, nsISupports * 0x00000000, unsigned int 2147500037) line 120 + 81 
bytes
nsResChannel::EndRequest(unsigned int 2147500037) line 561 + 46 bytes
nsResChannel::AsyncOpen(nsResChannel * const 0x057cb758, nsIStreamListener * 
0x057f4cb4, nsISupports * 0x00000000) line 413
NS_OpenURI(nsIStreamListener * 0x057f4cb4, nsISupports * 0x00000000, nsIURI * 
0x0496e628, nsIIOService * 0x00000000, nsILoadGroup * 0x049c0c40, 
nsIInterfaceRequestor * 0x00000000, unsigned int 0) line 198 + 31 bytes
nsStreamLoader::Init(nsStreamLoader * const 0x057f4cb0, nsIURI * 0x0496e628, 
nsIStreamLoaderObserver * 0x04a33820, nsISupports * 0x00000000, nsILoadGroup * 
0x049c0c40, nsIInterfaceRequestor * 0x00000000, unsigned int 0) line 45 + 53 
bytes
NS_NewStreamLoader(nsIStreamLoader * * 0x0012edb4, nsIURI * 0x0496e628, 
nsIStreamLoaderObserver * 0x04a33820, nsISupports * 0x00000000, nsILoadGroup * 
0x049c0c40, nsIInterfaceRequestor * 0x00000000, unsigned int 0) line 378 + 47 
bytes
CSSLoaderImpl::LoadSheet(URLKey & {...}, SheetLoadData * 0x04a33820) line 1217 
+ 38 bytes
CSSLoaderImpl::LoadStyleLink(CSSLoaderImpl * const 0x0597b388, nsIContent * 
0x00000000, nsIURI * 0x0585cca8, const nsString & {...}, const nsString & 
{...}, int -1, int 2, nsIParser * 0x058908d8, int & 1, nsICSSLoaderObserver * 
0x00000000) line 1396 + 22 bytes
XULContentSinkImpl::ProcessStyleLink(nsIContent * 0x00000000, const nsString & 
{...}, int 0, const nsString & {...}, const nsString & {...}, const nsString & 
{...}) line 869 + 123 bytes
XULContentSinkImpl::AddProcessingInstruction(XULContentSinkImpl * const 
0x0589be68, const nsIParserNode & {...}) line 944
CWellFormedDTD::HandleProcessingInstructionToken(CToken * 0x057cc0a0) line 606 
+ 31 bytes
CWellFormedDTD::HandleToken(CWellFormedDTD * const 0x058141e0, CToken * 
0x057cc0a0, nsIParser * 0x058908d8) line 522 + 12 bytes
CWellFormedDTD::BuildModel(CWellFormedDTD * const 0x058141e0, nsIParser * 
0x058908d8, nsITokenizer * 0x04d525a0, nsITokenObserver * 0x00000000, 
nsIContentSink * 0x0589be68) line 261 + 20 bytes
nsParser::BuildModel() line 2210 + 34 bytes
nsParser::ResumeParse(int 1, int 0) line 2081 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x058908e0, nsIRequest * 0x057fe348, 
nsISupports * 0x00000000, nsIInputStream * 0x04ead880, unsigned int 0, unsigned 
int 498) line 2684 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x05869148, 
nsIRequest * 0x057fe348, nsISupports * 0x00000000, nsIInputStream * 0x04ead880, 
unsigned int 0, unsigned int 498) line 235 + 46 bytes
nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x04a2aea8, 
nsIRequest * 0x057fe348, nsISupports * 0x00000000, nsIInputStream * 0x049f8ce8, 
unsigned int 0, unsigned int 498) line 57 + 51 bytes
nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x057fe34c, nsIRequest * 
0x04a00cf8, nsISupports * 0x00000000, nsIInputStream * 0x049f8ce8, unsigned int 
0, unsigned int 498) line 2146 + 57 bytes
nsOnDataAvailableEvent::HandleEvent() line 175 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x04cf582c) line 64
PL_HandleEvent(PLEvent * 0x04cf582c) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01177950) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0028029a, unsigned int 49371, unsigned int 0, 
long 18315600) line 1071 + 9 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x0125c908) line 424
main1(int 1, char * * 0x00357df0, nsISupports * 0x00000000) line 1174 + 32 bytes
main(int 1, char * * 0x00357df0) line 1478 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()

The ownership model (or pattern, anyway) of nsIStreamLoader says that 
NS_NewStreamLoader returns an |AddRef|ed pointer and the caller drops that 
reference on the floor, and then releases it when it gets the OnStreamComplete 
(to which the nsIStreamLoader is passed as a parameter).  The problem here is 
that the OnStreamComplete happens before NS_NewStreamLoader returns the 
reference to the caller, so the one existing reference owned by 
NS_NewStreamLoader to keep the object alive has been released during the 
object's initialization.

Comment 20

[jag (Peter Annema)]

So when we fail in nsResChannel::AsyncOpen near line 410,
nsResChannel::EndRequest is called, which in turn calls
mUserObserver->OnStopRequest.

I think the OnStopRequest call should not be made in the failure case (since as
far as I can tell no OnStartRequest was sent), so I think the
mUserObserver->OnStopRequest call should be moved from EndRequest to
nsResChannel::OnStopRequest just above it.

But this is just a guess, and the history of nsResChannel.cpp seems to suggest
I'm wrong, so handing this to the netwerk people.

Comment 21

[Doug Turner (:dougt)]

This sounds like the similar problem we fixed a few months ago.  I will attach a
fix.

Comment 22

[Doug Turner (:dougt)]

Attachment: proposed patch

Comment 23

[Judson Valeski]

r=valeski

Comment 24

[Gagan]

doug you rock! r=gagan

Comment 25

[vidur (gone)]

sr=vidur

Comment 26

[Doug Turner (:dougt)]

Fixed on trunk:
Checking in nsStreamLoader.cpp;
/cvsroot/mozilla/netwerk/base/src/nsStreamLoader.cpp,v  <--  nsStreamLoader.cpp
new revision: 1.16; previous revision: 1.15
done
Checking in nsStreamLoader.h;
/cvsroot/mozilla/netwerk/base/src/nsStreamLoader.h,v  <--  nsStreamLoader.h
new revision: 1.9; previous revision: 1.8
done

Comment 27

[Brendan Eich [:brendan]]

Dumb question from little me: why do you need to assign nsnull to mObserver, if
it's an nsCOMPtr?

-  nsStreamLoader() { NS_INIT_REFCNT();} ;
+  nsStreamLoader() { NS_INIT_REFCNT(); mObserver = nsnull; } ;
   virtual ~nsStreamLoader() {};

/be

Comment 28

[Doug Turner (:dougt)]

good point.  The .h could be reverted.

Comment 29

[selmer (gone)]

pdt+

Comment 30

[Doug Turner (:dougt)]

brendan, and now it has been:

Checking in nsStreamLoader.h;
/cvsroot/mozilla/netwerk/base/src/nsStreamLoader.h,v  <--  nsStreamLoader.h
new revision: 1.10; previous revision: 1.9
done

Comment 31

[Doug Turner (:dougt)]

checked into branch:

Checking in nsStreamLoader.cpp;
/cvsroot/mozilla/netwerk/base/src/nsStreamLoader.cpp,v  <--  nsStreamLoader.cpp
new revision: 1.15.42.1; previous revision: 1.15
done

marking fixed.

Comment 32

[John Morrison]

verified fixed 7/20 branch and trunk builds, mac/linux/win32 for the 
first attachment testcase and for the simplest version noted 07/02.

Comment 33

[Mike Schuette]

*** Bug 73316 has been marked as a duplicate of this bug. ***