Closed Bug 74057 Opened 24 years ago Closed 23 years ago

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

Categories

(Core :: XPCOM, defect, P1)

x86
Windows 2000
defect

Tracking

()

VERIFIED DUPLICATE of bug 75633
mozilla0.9.1

People

(Reporter: chofmann, Assigned: attinasi)

References

Details

(Keywords: crash, helpwanted, topcrash)

Crash Data

Attachments

(2 files)

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)
Keywords: crash, topcrash
Yuck! Any idea when this started showing up?
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?
cc'ing dougt for help with proxies
Assignee: kandrot → dougt
Severity: normal → major
Target Milestone: --- → mozilla0.9
yeah, this is mine. I will try to get to it for .9
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
bug 73316 looks a lot like this bug. Should i mark it a dupe and change the Platform/OS?
Blocks: 73716
*** Bug 73236 has been marked as a duplicate of this bug. ***
Summary: NT5.0 crash on startup [@nsProxyEventObject::GetNewOrUsedProxy] → W2k startup crash [@nsProxyEventObject::GetNewOrUsedProxy]
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]
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?
Keywords: qawanted
Keywords: nsCatFood+
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.
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?
Attached patch Shooting in the dark - v.1 (deleted) — Splinter Review
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.
looks good, sr=waterson
patch checked in
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
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
lets see what happens with 0.9 rolls out....
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]
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?
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
Accepting, happy to help.
Status: NEW → ASSIGNED
Priority: -- → P1
btw: bug 81823 covers the regression in the LINK element (mixed case for 'stylesheet' was breaking it - now fixed).
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.
Blocks: 82033
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 ago23 years ago
Resolution: --- → DUPLICATE
verified dups
Status: RESOLVED → VERIFIED
Keywords: qawanted
Crash Signature: [@ 0x00000000 - nsProxyEventObject::GetNewOrUsedProxy]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: