85559 - WinEmbed and MfcEmbed crash at this page.

Status: VERIFIED DUPLICATE of bug 75633

(Core :: CSS Parsing and Computation, defect)

Description

[Teruko Kobayashi]

WinEmbed and MfcEmbed crashes at this page.

Tested 6-12 WinEmbed and MfcEmbed trunk build.

WINEMBED のページ違反です。
モジュール : <不明>、アドレス : 0000:007dd721
Registers:
EAX=007dd810 CS=015f EIP=007dd721 EFLGS=00010202
EBX=60e02680 SS=0167 ESP=0063fb44 EBP=007dd5c0
ECX=607b2260 DS=0167 ESI=007e8290 FS=4e57
EDX=0000004c ES=0167 EDI=00000003 GS=0000
Bytes at CS:EIP:
da 6a 89 00 f5 88 00 4a 4e f6 9d 50 2e 89 00 00 
Stack dump:
00000000 00000000 00000000 00000000 60e02710 60ed1caa 007dd5c0 00000003 
00000005 007e81f0 00000000 007e8dd0 60eca6b8 007e8dd0 00000000 007f28e0

Comment 1

[Asa Dotzler [:asa]]

not mine. someone wanna attach a stack trace so I can maybe send this to the
right engineer (or reassign it yourself if you know who should get it).

Comment 2

[Teruko Kobayashi]

I can reproduce this on 6-19-01 Mtrunk WinEmbed and MfcEmbed build on Win2kJ.

Comment 3

[Teruko Kobayashi]

Roy or Brian, would you take a look at this bug?

Comment 4

[Roy Yokoyama]

I'll take a look, teruko.

Comment 5

[Roy Yokoyama]

asa: can you assign this to me?

Comment 6

[Roy Yokoyama]

I can reproduce this in my W2K-Ja.  
It's crashing at
http://lxr.mozilla.org/seamonkey/source/xpcom/proxy/src/nsProxyEventObject.cpp#162

nsProxyEventObject::GetNewOrUsedProxy(nsIEventQueue *destQueue,
                                      PRInt32 proxyType, 
                                      nsISupports *aObj,
                                      REFNSIID aIID)
{
    if (!aObj)
        return nsnull;

    nsISupports* rawObject = aObj;

    // make sure that the object pass in is not a proxy.
    nsCOMPtr<nsProxyEventObject> aIdentificationObject;
    nsresult rv = rawObject->QueryInterface(kProxyObject_Identity_Class_IID, getter_AddRefs(aIdentificationObject));

rawObject is corrupted.

asa: hummm, maybe you can assign to someone in XPCOM .

Comment 7

[Asa Dotzler [:asa]]

->XPCOM

Comment 8

[Edward Kandrot]

rawObject is passed in as aObj, which probably was called from GetProxyForObject
with a bad aObj was well.  This call could have come from any place.  Without a
stack trace, nothing can really be done with this.  Is there one available?

Comment 9

[Roy Yokoyama]

Here it is.  Hope this helps.

nsProxyEventObject::GetNewOrUsedProxy(nsIEventQueue * 0x00d90830, int 0x00000006, nsISupports * 0x00e0abd0, const nsID & 
{...}) line 162 + 38 bytes
nsProxyObjectManager::GetProxyForObject(nsProxyObjectManager * const 0x00e1fb30, nsIEventQueue * 0x00000000, const nsID 
& {...}, nsISupports * 0x00e0abd0, int 0x00000006, void * * 0x0012f238) line 200 + 26 bytes
nsStreamLoader::Init(nsStreamLoader * const 0x00e0ae20, nsIURI * 0x00e0ab50, nsIStreamLoaderObserver * 0x00e0abd0, 
nsISupports * 0x00000000, nsILoadGroup * 0x00e02c90, nsIInterfaceRequestor * 0x00000000, unsigned int 0x00000000) line 58 + 
61 bytes
NS_NewStreamLoader(nsIStreamLoader * * 0x0012f304, nsIURI * 0x00e0ab50, nsIStreamLoaderObserver * 0x00e0abd0, 
nsISupports * 0x00000000, nsILoadGroup * 0x00e02c90, nsIInterfaceRequestor * 0x00000000, unsigned int 0x00000000) line 378 + 
47 bytes
CSSLoaderImpl::LoadSheet(URLKey & {...}, SheetLoadData * 0x00e0abd0) line 1217 + 38 bytes
CSSLoaderImpl::LoadStyleLink(CSSLoaderImpl * const 0x02b25c50, nsIContent * 0x00e0a2e0, nsIURI * 0x00e0ae80, const 
nsString & {...}, const nsString & {...}, int 0xffffffff, int 0x00000000, nsIParser * 0x02b18610, int & 0x00000001, 
nsICSSLoaderObserver * 0x00000000) line 1396 + 22 bytes
nsStyleLinkElement::UpdateStyleSheet(nsStyleLinkElement * const 0x00e0a310, int 0x00000001, nsIDocument * 0x02b16dd0, int 
0x00000000) line 325 + 130 bytes
HTMLContentSink::ProcessLINKTag(const nsIParserNode & {...}) line 4462 + 42 bytes
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x02b27480, const nsIParserNode & {...}) line 3420 + 12 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x00b140c8) line 3789 + 22 bytes
CNavDTD::AddHeadLeaf(nsIParserNode * 0x00b140c8) line 3847 + 15 bytes
CNavDTD::HandleStartToken(CToken * 0x02878940) line 1744 + 12 bytes
CNavDTD::HandleToken(CNavDTD * const 0x00e0b570, CToken * 0x02878940, nsIParser * 0x02b18610) line 910 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x00e0b570, nsIParser * 0x02b18610, nsITokenizer * 0x00e0b410, nsITokenObserver * 
0x00000000, nsIContentSink * 0x02b27480) line 540 + 20 bytes
nsParser::BuildModel() line 2206 + 34 bytes
nsParser::ResumeParse(int 0x00000001, int 0x00000000) line 2077 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x02b18618, nsIRequest * 0x02afec10, nsISupports * 0x00000000, nsIInputStream * 
0x00dec3b0, unsigned int 0x00000000, unsigned int 0x0000280f) line 2680 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x02a9f650, nsIRequest * 0x02afec10, nsISupports * 
0x00000000, nsIInputStream * 0x00dec3b0, unsigned int 0x00000000, unsigned int 0x0000280f) line 235 + 46 bytes
nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x00d81e20, nsIRequest * 0x02afec10, nsISupports * 
0x00000000, nsIInputStream * 0x02a9ec90, unsigned int 0x00000000, unsigned int 0x0000280f) line 56 + 51 bytes
nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x02afec14, nsIRequest * 0x02ae3b80, nsISupports * 0x00000000, 
nsIInputStream * 0x02a9ec90, unsigned int 0x00000000, unsigned int 0x0000280f) line 2146 + 57 bytes
nsOnDataAvailableEvent::HandleEvent() line 175 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x02b1a5a4) line 64
PL_HandleEvent(PLEvent * 0x02b1a5a4) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00d90760) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x001904ee, unsigned int 0x0000c132, unsigned int 0x00000000, long 0x00d90760) line 1071 + 9 
bytes
USER32! 77de2a70()

Comment 10

[Edward Kandrot]

Thanks for the stack trace.  Tracing back through the trace, it appears that the
bad value is an Observer which is bad.  It looks like this happens in
CSSLoaderImpl, so I am assigning this to the default owner who should be able to
determine why this value is bad when passed down.

Comment 11

[Pierre Saslawsky]

The page at the URL above links a chrome stylesheet through:
<link rel="important stylesheet" href="chrome://messenger/skin/mailheader.css">

This path is no longer valid. We already have a bug reported against this 
problem: bug 75633 - Ref. to non-existent "chrome://" stylesheet in XBL or XUL 
file, causes crash M091 Trunk & N610 branch [@ 0x00000000 - 
nsProxyEventObject::GetNewOrUsedProxy]


*** This bug has been marked as a duplicate of 75633 ***

Comment 12

[John Morrison]

verified dup (but it does kinda suck that this can be triggered from an HTML 
page, not just XUL (although not in seamonkey, just in embedded)).