74057 - M09 W2k startup crash [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]

Status: VERIFIED DUPLICATE of bug 75633

(Core :: XPCOM, defect, P1)

Description

[chris hofmann]

Ed, can you get the investigation started on this
and figure out if its xpcom or where the bug should
go next?

Looking at talkback comment data for M0.8.1 it appears several 
folks are having problems with startup on win2000 (NT 5.0)

Comments in the talback data look like.

- nsProxyEventObject::GetNewOrUsedProxy 6a6f1f2d BBID: 28317242 Build:
2001032614 Crash Date: 2001-03-27 
172 sec. started it with old app data (0.8) running on Windows NT 5.0 build 2195
src_file d:/builds/0.8.1/mozilla/xpcom/proxy/src/nsProxyEventObject.cpp line 172 

- nsProxyEventObject::GetNewOrUsedProxy 6a6f1f2d BBID: 28319255 Build:
2001032614 Crash Date: 2001-03-27 
172 sec. It crashes while starting on win 2000 running on Windows NT 5.0 build 
2195
src_file d:/builds/0.8.1/mozilla/xpcom/proxy/src/nsProxyEventObject.cpp line 172 

- nsProxyEventObject::GetNewOrUsedProxy 6a6f1f2d BBID: 28365299 Build:
2001032614 Crash Date: 2001-03-28 
172 sec. no url just starting the newly installed lizard :) running on Windows 
NT 5.0
build 2195 src_file 
d:/builds/0.8.1/mozilla/xpcom/proxy/src/nsProxyEventObject.cpp
line 172 

- nsProxyEventObject::GetNewOrUsedProxy 6a6f1f2d BBID: 28369413 Build:
2001032614 Crash Date: 2001-03-28 
172 sec. starting the application (mozilla.exe) running on Windows NT 5.0 build 
2195
src_file d:/builds/0.8.1/mozilla/xpcom/proxy/src/nsProxyEventObject.cpp line 172 

- nsProxyEventObject::GetNewOrUsedProxy 6a6f1f2d BBID: 28385662 Build:
2001032614 Crash Date: 2001-03-28 
172 sec. Installed Mozilla via the zip file. Attempted to start Mozilla and it 
crashed.
Has done this repeatedly (I've reinstalled multiple times). running on Windows 
NT 5.0
build 2195 src_file 
d:/builds/0.8.1/mozilla/xpcom/proxy/src/nsProxyEventObject.cpp
line 172 

Stack looks like the following.  nsProxyEventObject.cpp
hasn't changed in a while so maybe the world has moved
out from under it....

Incident ID 28369413 
nsProxyEventObject::GetNewOrUsedProxy
[d:\builds\0.8.1\mozilla\xpcom\proxy\src\nsProxyEventObject.cpp, line 172] 
nsProxyObjectManager::GetProxyForObject
[d:\builds\0.8.1\mozilla\xpcom\proxy\src\nsProxyObjectManager.cpp, line 193] 
nsStreamLoader::Init 
[d:\builds\0.8.1\mozilla\netwerk\base\src\nsStreamLoader.cpp, line
59] 
NS_NewStreamLoader [..\..\..\..\dist\include\nsNetUtil.h, line 353] 
CSSLoaderImpl::LoadSheet
[d:\builds\0.8.1\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1236] 
CSSLoaderImpl::LoadStyleLink
[d:\builds\0.8.1\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1403] 
XULContentSinkImpl::ProcessStyleLink
[d:\builds\0.8.1\mozilla\content\xul\document\src\nsXULContentSink.cpp, line 
867] 
XULContentSinkImpl::AddProcessingInstruction
[d:\builds\0.8.1\mozilla\content\xul\document\src\nsXULContentSink.cpp, line 
941] 
CWellFormedDTD::HandleProcessingInstructionToken
[d:\builds\0.8.1\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 605] 
CWellFormedDTD::HandleToken
[d:\builds\0.8.1\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 521] 
CWellFormedDTD::BuildModel
[d:\builds\0.8.1\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 260] 
nsParser::BuildModel [d:\builds\0.8.1\mozilla\htmlparser\src\nsParser.cpp, line 
2032] 
nsParser::ResumeParse [d:\builds\0.8.1\mozilla\htmlparser\src\nsParser.cpp, line 
1911] 
nsParser::ContinueParsing [d:\builds\0.8.1\mozilla\htmlparser\src\nsParser.cpp, 
line 1523]

CSSLoaderImpl::Cleanup 
[d:\builds\0.8.1\mozilla\content\html\style\src\nsCSSLoader.cpp,
line 709] 
CSSLoaderImpl::DidLoadStyle
[d:\builds\0.8.1\mozilla\content\html\style\src\nsCSSLoader.cpp, line 928] 
SheetLoadData::OnStreamComplete
[d:\builds\0.8.1\mozilla\content\html\style\src\nsCSSLoader.cpp, line 647] 
nsStreamLoader::OnStopRequest
[d:\builds\0.8.1\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 122] 
nsResChannel::EndRequest
[d:\builds\0.8.1\mozilla\netwerk\protocol\res\src\nsResChannel.cpp, line 579] 
nsResChannel::AsyncOpen
[d:\builds\0.8.1\mozilla\netwerk\protocol\res\src\nsResChannel.cpp, line 422] 
NS_OpenURI [..\..\..\dist\include\nsNetUtil.h, line 177] 
nsStreamLoader::Init 
[d:\builds\0.8.1\mozilla\netwerk\base\src\nsStreamLoader.cpp, line
46] 
NS_NewStreamLoader [..\..\..\..\dist\include\nsNetUtil.h, line 353] 
CSSLoaderImpl::LoadSheet
[d:\builds\0.8.1\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1236] 
CSSLoaderImpl::LoadStyleLink
[d:\builds\0.8.1\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1403] 
XULContentSinkImpl::ProcessStyleLink
[d:\builds\0.8.1\mozilla\content\xul\document\src\nsXULContentSink.cpp, line 
867] 
XULContentSinkImpl::AddProcessingInstruction
[d:\builds\0.8.1\mozilla\content\xul\document\src\nsXULContentSink.cpp, line 
941] 
CWellFormedDTD::HandleProcessingInstructionToken
[d:\builds\0.8.1\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 605] 
CWellFormedDTD::HandleToken
[d:\builds\0.8.1\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 521] 
CWellFormedDTD::BuildModel
[d:\builds\0.8.1\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 260] 
nsParser::BuildModel [d:\builds\0.8.1\mozilla\htmlparser\src\nsParser.cpp, line 
2032] 
nsParser::ResumeParse [d:\builds\0.8.1\mozilla\htmlparser\src\nsParser.cpp, line 
1911] 
nsParser::OnDataAvailable [d:\builds\0.8.1\mozilla\htmlparser\src\nsParser.cpp, 
line 2362]

nsDocumentOpenInfo::OnDataAvailable
[d:\builds\0.8.1\mozilla\uriloader\base\nsURILoader.cpp, line 261] 
nsJARChannel::OnDataAvailable
[d:\builds\0.8.1\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 630] 
nsOnDataAvailableEvent::HandleEvent
[d:\builds\0.8.1\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp, line 173] 
nsStreamObserverEvent::HandlePLEvent
[d:\builds\0.8.1\mozilla\netwerk\base\src\nsStreamObserverProxy.cpp, line 79] 
PL_HandleEvent [d:\builds\0.8.1\mozilla\xpcom\threads\plevent.c, line 589] 
PL_ProcessPendingEvents [d:\builds\0.8.1\mozilla\xpcom\threads\plevent.c, line 
522] 
_md_EventReceiverProc [d:\builds\0.8.1\mozilla\xpcom\threads\plevent.c, line 
1070] 
nsAppShellService::Run 
[d:\builds\0.8.1\mozilla\xpfe\appshell\src\nsAppShellService.cpp,
line 408] 
main1 [d:\builds\0.8.1\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1011] 
main [d:\builds\0.8.1\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1301] 
WinMain [d:\builds\0.8.1\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1319] 
WinMainCRTStartup() 
KERNEL32.DLL + 0x192a6 (0x77e992a6)

Comment 1

[Darin Fisher]

Yuck!  Any idea when this started showing up?

Comment 2

[chris hofmann]

Attachment: shows list of all crashes in the database with this signature

Comment 3

[chris hofmann]

looks like 3/27 for the current codebase

there are some reports on 6.01 with nsProxyEventObject::GetNewOrUsedProxy on the 
top of the stack, but the stack is a bit different although we
end up crashing at the same line...  the 6.01 stacks look like

nsProxyEventObject::GetNewOrUsedProxy 
[d:\builds\6.01\mozilla\xpcom\proxy\src\nsProxyEventObject.cpp, line 172] 
nsProxyObjectManager::GetProxyForObject 
[d:\builds\6.01\mozilla\xpcom\proxy\src\nsProxyObjectManager.cpp, line 190] 
ImportMailThread [d:\builds\6.01\mozilla\mailnews\import\src\nsImportMail.cpp, 
line 828] 

maybe we just exposed a problem we already had?

Comment 4

[Darin Fisher]

cc'ing dougt for help with proxies

Comment 5

[Doug Turner (:dougt)]

yeah, this is mine.  I will try to get to it for .9

Comment 6

[selmer (gone)]

Doug, this is the top windows crash in the first few minutes of the session and
near the top overall.  I'm assigning it a crash car.

Comment 7

[Keyser Sose]

bug 73316 looks a lot like this bug. Should i mark it a dupe and change the 
Platform/OS?

Comment 8

[Edward Kandrot]

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

Comment 9

[Jay Patel [:jay]]

added M081 to summary for tracking, since this is the #1 crasher for the Mozilla 
0.8.1 milestone.

Comment 10

[Simon Lucy]

I'd like this cleared up for 0.8.1 as Beonex is due to release and this is
likely to be a blocker on that as previous 'profiles' will likely break so
upgrades will fail.

I'll work on it here so if anyone has any insight as to whereabouts they think
the problem is I'd be grateful.

Comment 11

[Doug Turner (:dougt)]

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

Comment 12

[Doug Turner (:dougt)]

I am having a tough time reproducing this.  Does anyone have a reliable way to 
reproduce this?

Comment 13

[Doug Turner (:dougt)]

Running Purify does not show anything problems with a stack as described.  I 
wrote a test case which exercises the area of the crash and purify does not have 
any problems with it.

Comment 14

[Jay Patel [:jay]]

Two new Talkback entries were made by the same person yesterday and today using 
build 2001041109, here is one of those entries:

Incident ID 28999386 
 Trigger Time 
                2001-04-12 06:16:37 
 
 Client IP Address 
                141.99.2.9 
 User Comments 
                i think it's a conflict with the new internetexplorer6.0beta i 
installed on my system 
 Build ID
                2001041109 
 Product ID
                Netscape6.50 
 Platform ID
                Win32 
 Stack Trace

nsProxyEventObject::GetNewOrUsedProxy 
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEventObject.cpp, line 172] 
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::LoadChildSheet 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1478] 
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]

Can IE 6 beta have something to do with this? 

It also should be noted that other than those 2 recent entries, all the 
other crashes reported by Talkback are happening with the 2001032614 build.

Comment 15

[Doug Turner (:dougt)]

OnClickThreadAndMessagePaneSplitter


I have not been abled to reproduce.  I have spoken to Ben Bucksch 
<[e-mail]> and Simon P. Lucy <[e-mail]> who have 
requested that this be fixed for their 0.8.1 release.  Simon may have been able 
to reproduce the crash, but I have not gotten a confirmation about this.  I have 
sent him mail again today.

As I stated in the bug report (above), I ran purify against bookmarks, and mail 
import.  Neither reveiled any problems.  I also ran purify against a test case 
which exercises this area.  It also ran clean.

I believe that the talkback reports are reporting the wrong line number.  I have 
a patch that will reorder some of the complex lines.  It also clears up some 
casting problem (which may or may not be related).  I will be checkin this in 
before 0.9.

did any of the people in the talkback reports leave an email address?

Comment 16

[Doug Turner (:dougt)]

Attachment: Shooting in the dark - v.1

Comment 17

[Doug Turner (:dougt)]

The above patch:
1. changes the order how things get created.  
2. adds assertions.
3. protects in case things go wrong and we deference a null.
4. fixes a very bad cast.

Overhaul, I can not say that this fixes the problem reported.  I think that we 
are just going to have to hold our breath until this problem become 
reproducible.

Comment 18

[Chris Waterson]

looks good, sr=waterson

Comment 19

[Doug Turner (:dougt)]

patch checked in

Comment 20

[Doug Turner (:dougt)]

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

Comment 21

[Doug Turner (:dougt)]

setting milestone...

Comment 22

[Doug Turner (:dougt)]

someone tell me I am wrong, but I don't see 
nsProxyEventObject::GetNewOrUsedProxy in the crash analysis here:

http://ftp.mozilla.org/pub/data/crash-data/seamonkey-crash-analysis.txt

Comment 23

[Jay Patel [:jay]]

According to the latest Talkback data, I can confirm that this is no longer a 
topcrasher.  The last time this crash showed up was with build 2001041109.  
Since then, Talkback has not collected any crash data for 
nsProxyEventObject::GetNewOrUsedProxy.  Marking fixed since this crash is no 
longer around and a fix was checked in on 4/13.

Comment 24

[Doug Turner (:dougt)]

lets see what happens with 0.9 rolls out....

Comment 25

[Jay Patel [:jay]]

Reopening.  This crash has reappeared with Mozilla 0.9 under the 0x00000000 
stack signature.  Adding M09 and [@ 0x00000000 - 
nsProxyEventObject::GetNewOrUsedProxy] for tracking.  This crash is also still 
on Win2K only:

Here are some entries...from the uptime data, it's clear that they're all 
startup crashes:

0x00000000 2c2df1e9
         line 
        Build: 2001050518 CrashDate: 2001-05-08 UptimeMinutes: 0  Total: 0 
        OS: Windows NT  5.0 build 2195
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=30176571
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=30176571

    0x00000000 2c2df1e9
         line 
        Build: 2001050518 CrashDate: 2001-05-08 UptimeMinutes: 0  Total: 0 
        OS: Windows NT  5.0 build 2195
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=30176393
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=30176393

    0x00000000 2c2df1e9
         line 
        Build: 2001050518 CrashDate: 2001-05-08 UptimeMinutes: 0  Total: 0 
        OS: Windows NT  5.0 build 2195
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=30176385
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=30176385

The latest stacktrace:

Incident ID 30176571 
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 354] 
CSSLoaderImpl::LoadSheet 
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp,
line 1225] 
CSSLoaderImpl::LoadChildSheet
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1478] 
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 26

[Doug Turner (:dougt)]

The only way for this crash to occur is (a) the URI to be opened fails, and (b) 
the observer of the load to be non-null but deleted.

marc, any ideas?

Comment 27

[Doug Turner (:dougt)]

At some point, for whatever reason, SheetLoadData object is being released from 
under us before the call into the nsProxyObjectManager from the nsStreamLoader.  
When the proxy manager goes to call QI on the SheetLoadData (a 
nsIStreamLoaderObserver), it dies.

It seams to me that this problem is some kind of refcounting problem with the 
SheetLoadData inside nsCSSLoader.  However, I have not been able to reproduce 
it.  I think that the best approach would be to find some kind of testcase since 
my early attempts to solve this bug by poking around have failed.  

The way to get this proxy code to execute is to use a style sheet which has a 
bad url such as "file://http://die.die.die".  Here is an internal testcase: 
(http://grok.mcom.com/u/dougt/test/test.html) It doesn't seam to work in 
todays build, but did on friday's (seperate bug?)

If you need any help from me, please let me know, but I think that this is a 
cssloading problem and I am trying to load balance right now.  Marc, thanks for 
looking at this...

I have contacted [e-mail], and [e-mail] to see if we can get as 
many QA folks to try to get a reliable test case.

Comment 28

[Marc Attinasi]

Accepting, happy to help.

Comment 29

[Marc Attinasi]

btw: bug 81823 covers the regression in the LINK element (mixed case for
'stylesheet' was breaking it - now fixed).

Comment 30

[John Morrison]

dougt: I think you already have the reproducible test case. Or more to the 
point, see bug 75633: if a XUL developer makes a typo in the spelling of a
stylesheet, they will get this crash.

jpatel: I have a question about the talkback data: those three crashes listed
are all at the same IP within 4 minutes of each other. (Hmm, maybe someone was 
tinkering with XUL, and kept tinkering until they discovered their error (but 
dutifully dispatching talkback reports for every crash)). 

So, how many crashes are we talking about, and how many are just "self 
duplicates" as above.

Comment 31

[Doug Turner (:dougt)]

John - thanks for pointing this out.  75633 is a dup of this one.

Comment 32

[Marc Attinasi]

Duping this one to the (newer) bug 75633 because 75633 has the correct owner, a 
testcase, and more information. Curiously, bug 75633 is marked Future, however, 
so that may need to be reevaluated.

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

Comment 33

[Chad Austin]

verified dups