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

VERIFIED FIXED

Status

()

--
critical
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: jrgmorrison, Assigned: dougt)

Tracking

({crash, topcrash})

Trunk
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: pdt+, crash signature)

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
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)
(Reporter)

Comment 1

18 years ago
Created attachment 30500 [details]
stripped down version of Alex's original testcase (no mutation events)
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.
Assignee: nisheeth → hyatt
Severity: normal → critical
Component: XML → XBL
Keywords: crash
QA Contact: petersen → jrgm

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 3

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

Comment 4

18 years ago
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.
Keywords: nsCatFood+, topcrash
Target Milestone: Future → ---

Updated

18 years ago
Target Milestone: --- → Future

Updated

18 years ago
Summary: Ref. to non-existent stylesheet in XBL binding.xml file, causes crash → Ref. to non-existent stylesheet in XBL binding.xml file, causes crash M091 Trunk [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]

Comment 5

18 years ago
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] 
(Reporter)

Comment 6

18 years ago
*** Bug 88472 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 7

18 years ago
It was noted on bug Bug 88472 by druidsquirrel@yahoo.com 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?
(Reporter)

Updated

18 years ago
Summary: Ref. to non-existent stylesheet in XBL binding.xml file, causes crash M091 Trunk [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy] → Ref. to non-existent stylesheet in XBL or XUL file, causes crash M091 Trunk [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]

Comment 8

18 years ago
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

18 years ago
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.
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()
Created attachment 41330 [details]
testcase, XUL, xulmaker, save to disc and open (CRASH)
Based on greer's comments about number of occurrencies, removing Future
milestone for re-evaluation.
Target Milestone: Future → ---

Comment 13

18 years ago
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)
Summary: Ref. to non-existent stylesheet in XBL or XUL file, causes crash M091 Trunk [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy] → Ref. to non-existent stylesheet in XBL or XUL file, causes crash M091 Trunk & N610 branch [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]
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

18 years ago
Created attachment 41615 [details]
testcase served as xul

Updated

18 years ago
Summary: Ref. to non-existent stylesheet in XBL or XUL file, causes crash M091 Trunk & N610 branch [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy] → Ref. to non-existent "chrome://" stylesheet in XBL or XUL file, causes crash M091 Trunk & N610 branch [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]

Comment 16

18 years ago
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

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

Comment 18

18 years ago
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.
Summary: Ref. to non-existent "chrome://" stylesheet in XBL or XUL file, causes crash M091 Trunk & N610 branch [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy] → Ref. to non-existent "chrome://" stylesheet in XBL or XUL file, causes crash M092, Trunk & N610 [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]
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

18 years ago
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.
Assignee: hyatt → neeti
Status: ASSIGNED → NEW
Component: XBL → Networking
QA Contact: jrgm → benc
(Assignee)

Comment 21

18 years ago
This sounds like the similar problem we fixed a few months ago.  I will attach a
fix.
Assignee: neeti → dougt
(Assignee)

Comment 22

18 years ago
Created attachment 42579 [details] [diff] [review]
proposed patch

Comment 23

18 years ago
r=valeski

Comment 24

18 years ago
doug you rock! r=gagan
Whiteboard: need sr

Comment 25

18 years ago
sr=vidur
(Assignee)

Comment 26

18 years ago
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

(Assignee)

Updated

18 years ago
Whiteboard: need sr
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
(Assignee)

Comment 28

18 years ago
good point.  The .h could be reverted.

Comment 29

18 years ago
pdt+
Whiteboard: pdt+
(Assignee)

Comment 30

18 years ago
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
(Assignee)

Comment 31

18 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 32

18 years ago
verified fixed 7/20 branch and trunk builds, mac/linux/win32 for the 
first attachment testcase and for the simplest version noted 07/02.
Status: RESOLVED → VERIFIED

Comment 33

17 years ago
*** Bug 73316 has been marked as a duplicate of this bug. ***
Crash Signature: [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]
You need to log in before you can comment on or make changes to this bug.