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

VERIFIED DUPLICATE of bug 75633

Status

()

P1
major
VERIFIED DUPLICATE of bug 75633
18 years ago
18 years ago

People

(Reporter: chofmann, Assigned: attinasi)

Tracking

({crash, helpwanted, topcrash})

Trunk
mozilla0.9.1
x86
Windows 2000
crash, helpwanted, topcrash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

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

Updated

18 years ago
Keywords: crash, topcrash

Comment 1

18 years ago
Yuck!  Any idea when this started showing up?
(Reporter)

Comment 2

18 years ago
Created attachment 29267 [details]
shows list of all crashes in the database with this signature
(Reporter)

Comment 3

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

18 years ago
cc'ing dougt for help with proxies

Updated

18 years ago
Assignee: kandrot → dougt
Severity: normal → major
Target Milestone: --- → mozilla0.9
yeah, this is mine.  I will try to get to it for .9

Comment 6

18 years ago
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.
Keywords: nsCatFood

Comment 7

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

Updated

18 years ago
Blocks: 73716

Comment 8

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

Updated

18 years ago
Summary: NT5.0 crash on startup [@nsProxyEventObject::GetNewOrUsedProxy] → W2k startup crash [@nsProxyEventObject::GetNewOrUsedProxy]

Comment 9

18 years ago
added M081 to summary for tracking, since this is the #1 crasher for the Mozilla 
0.8.1 milestone.
Summary: W2k startup crash [@nsProxyEventObject::GetNewOrUsedProxy] → M081 W2k startup crash [@ nsProxyEventObject::GetNewOrUsedProxy]

Comment 10

18 years ago
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.
*** Bug 73716 has been marked as a duplicate of this bug. ***
I am having a tough time reproducing this.  Does anyone have a reliable way to 
reproduce this?

Updated

18 years ago
Keywords: qawanted

Updated

18 years ago
Keywords: nsCatFood+

Updated

18 years ago
Keywords: nsCatFood
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

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


I have not been abled to reproduce.  I have spoken to Ben Bucksch 
<ben.bucksch@beonex.com> and Simon P. Lucy <slucy@objectivesw.co.uk> 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?
Created attachment 30858 [details] [diff] [review]
Shooting in the dark - v.1
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

18 years ago
looks good, sr=waterson
patch checked in

Updated

18 years ago
Whiteboard: Possible fix checked in.
*** Bug 75636 has been marked as a duplicate of this bug. ***
setting milestone...
Target Milestone: mozilla0.9 → mozilla0.9.1
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

18 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
lets see what happens with 0.9 rolls out....

Comment 25

18 years ago
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]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: M081 W2k startup crash [@ nsProxyEventObject::GetNewOrUsedProxy] → M09 W2k startup crash [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]

Updated

18 years ago
Whiteboard: Possible fix checked in.
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?

Updated

18 years ago
Keywords: helpwanted
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 asa@mozilla.org, and paw@netscape.com to see if we can get as 
many QA folks to try to get a reliable test case.
Assignee: dougt → attinasi
Status: REOPENED → NEW
(Assignee)

Comment 28

18 years ago
Accepting, happy to help.
Status: NEW → ASSIGNED
Priority: -- → P1
(Assignee)

Comment 29

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

Comment 30

18 years ago
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.
John - thanks for pointing this out.  75633 is a dup of this one.

(Reporter)

Updated

18 years ago
Blocks: 82033
(Assignee)

Comment 32

18 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 33

18 years ago
verified dups
Status: RESOLVED → VERIFIED

Updated

18 years ago
Keywords: qawanted
Crash Signature: [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]
You need to log in before you can comment on or make changes to this bug.