Closed
Bug 74057
Opened 24 years ago
Closed 23 years ago
M09 W2k startup crash [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]
Categories
(Core :: XPCOM, defect, P1)
Tracking
()
mozilla0.9.1
People
(Reporter: chofmann, Assigned: attinasi)
References
Details
(Keywords: crash, helpwanted, topcrash)
Crash Data
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•24 years ago
|
Comment 1•24 years ago
|
||
Yuck! Any idea when this started showing up?
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 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•24 years ago
|
||
cc'ing dougt for help with proxies
Updated•24 years ago
|
Assignee: kandrot → dougt
Severity: normal → major
Target Milestone: --- → mozilla0.9
Comment 5•24 years ago
|
||
yeah, this is mine. I will try to get to it for .9
Comment 6•24 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•24 years ago
|
||
bug 73316 looks a lot like this bug. Should i mark it a dupe and change the
Platform/OS?
Reporter | ||
Updated•24 years ago
|
Summary: NT5.0 crash on startup [@nsProxyEventObject::GetNewOrUsedProxy] → W2k startup crash [@nsProxyEventObject::GetNewOrUsedProxy]
Comment 9•24 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•24 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.
Comment 11•24 years ago
|
||
*** Bug 73716 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
I am having a tough time reproducing this. Does anyone have a reliable way to
reproduce this?
Updated•24 years ago
|
Keywords: nsCatFood+
Comment 13•24 years ago
|
||
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•24 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.
Comment 15•24 years ago
|
||
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?
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
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•24 years ago
|
||
looks good, sr=waterson
Comment 19•24 years ago
|
||
patch checked in
Updated•24 years ago
|
Whiteboard: Possible fix checked in.
Comment 20•24 years ago
|
||
*** Bug 75636 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
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•24 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
Closed: 24 years ago
Resolution: --- → FIXED
Comment 24•24 years ago
|
||
lets see what happens with 0.9 rolls out....
Comment 25•24 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•23 years ago
|
Whiteboard: Possible fix checked in.
Comment 26•23 years ago
|
||
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•23 years ago
|
Keywords: helpwanted
Comment 27•23 years ago
|
||
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 29•23 years ago
|
||
btw: bug 81823 covers the regression in the LINK element (mixed case for
'stylesheet' was breaking it - now fixed).
Comment 30•23 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.
Comment 31•23 years ago
|
||
John - thanks for pointing this out. 75633 is a dup of this one.
Assignee | ||
Comment 32•23 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
Closed: 24 years ago → 23 years ago
Resolution: --- → DUPLICATE
Updated•13 years ago
|
Crash Signature: [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]
You need to log in
before you can comment on or make changes to this bug.
Description
•