Closed
Bug 103997
Opened 23 years ago
Closed 23 years ago
[DEP 52334 ]crash opening URL w/ JavaScript enabled [@ nsWindow::Create]
Categories
(Core :: Layout, defect, P1)
Tracking
()
mozilla0.9.9
People
(Reporter: db, Assigned: jst)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(1 file, 1 obsolete file)
|
(deleted),
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4+) Gecko/20011008
BuildID: 20011008
When browsing to the page http://www.ifrance.com/ardantz/setup_tools.htm with
JavaScript enabled Mozilla crashed with a segfault. When I disable JavaScript
Mozilla displays the page (correctly, i.e. no layout errors are visible to me).
Reproducible: Always
Steps to Reproduce:
1. Enable JavaScript for Navigator (Edit -> Preferences... -> Advanced).
2. Browse to "http://www.ifrance.com/ardantz/setup_tools.htm" (it doesn't seem
to matter if I type the URL by hand, copy it from the clipboard, or browse to it
via Bookmark).
Actual Results: Mozilla crashes (Stack trace currently not at hand,
unfortunately...). When the JavaScript Console is open, you see the following
errors before Mozilla crashes:
- Error: this.stopContext has no properties
Source File: chrome://navigator/content/nsBrowserStatusHandler.js Line: 189
- Error: relpubloc is not defined
The first error seems to be normal (i.e. I see it on every page load). The
second error is not normal and seems to indicate that there is a reference to a
JS variable which is not defined (just my 5c).
Expected Results: Display the page and do not crash.
Stack trace is same as attachment 52084 [details] in bug 101746.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
Reporter | |
Comment 2•23 years ago
|
||
*** Bug 104011 has been marked as a duplicate of this bug. ***
|
||
Comment 3•23 years ago
|
||
Here's the minimal code to have the crash (note: i have an empty
'definition.css' file, and yes all part are required to have a crash. removing
the if else condition, the var, or the link stuff remove the crash !).
<HTML>
<SCRIPT language=javascript>
<!--
var ops_s;
ops_s = 400;
if(ops_s < 400) {} else {
if(window == window.top) {
var s='<FRAMESET><FRAME src="'+window.location+'?" name="doc"></FRAMESET>';
document.write(s);
}
}
//-->
</SCRIPT>
<LINK
href="Site de Jean-Michel Ardantz - Ximian Setup Tools (captures d
crans)_fichiers/definition.css"
type=text/css rel=stylesheet>
</HEAD></HTML>
|
||
Comment 4•23 years ago
|
||
wfm with win2k build 20011009..
|
||
Comment 5•23 years ago
|
||
This was the call stack reported in duplicate bug 104011:
GKGFXWIN! 60348946()
GKGFXWIN! 60345a23()
GKGFX! 60c93b75()
GKLAYOUT! 60387566()
GKLAYOUT! 60387425()
GKLAYOUT! 603983cc()
GKLAYOUT! 6039211d()
GKLAYOUT! 6038531f()
GKLAYOUT! 6036bb0d()
GKLAYOUT! 603ebd47()
GKLAYOUT! 603eb951()
GKLAYOUT! 603e724d()
GKLAYOUT! 603e724d()
GKLAYOUT! 603fbfa1()
GKLAYOUT! 603fbfcc()
GKLAYOUT! 603e724d()
GKLAYOUT! 603fb9ef()
GKLAYOUT! 6038531f()
GKLAYOUT! 603faae0()
GKLAYOUT! 6037e665()
GKCONTENT! 6024d26d()
GKCONTENT! 6024bce9()
GKPARSER! 60458078()
GKPARSER! 60462b95()
GKCONTENT! 60243cb8()
DOCSHELL! 60158854()
DOCSHELL! 60153a2c()
GKLAYOUT! 6039f64d()
GKLAYOUT! 60366352()
GKLAYOUT! 60384a81()
GKLAYOUT! 60366352()
GKLAYOUT! 60384a81()
GKLAYOUT! 60399026()
GKLAYOUT! 60391da0()
GKLAYOUT! 6038fc29()
GKLAYOUT! 603a9768()
GKCONTENT! 60213aee()
GKCONTENT! 60251ece()
GKCONTENT! 602517f7()
GKCONTENT! 6025197d()
GKCONTENT! 60251a2a()
GKCONTENT! 602514d4()
NECKO! 608284c8()
NECKO! 6082f94e()
NECKO! 6082e8c6()
XPCOM! 60f114d9()
|
|
||
Comment 6•23 years ago
|
||
Browser, not engine. Reassigning to Layout for further triage -
Assignee: rogerl → attinasi
Component: Javascript Engine → Layout
QA Contact: pschwartau → petersen
|
||
Comment 7•23 years ago
|
||
I crash if I reload the page after it is loaded successfully. Here is the stack
I get on Windows 2000
NTDLL! 77fa018c()
nsWindow::Create(nsWindow * const 0x03b33154, nsIWidget * 0x03b00e04, const
nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x02e44d90 HandleEvent(nsGUIEvent
*), nsIDeviceContext * 0x03b07a00, nsIAppShell * 0x00000000, nsIToolkit *
0x00000000, nsWidgetInitData * 0x0012ee98) line 1211
nsView::CreateWidget(nsView * const 0x03b33470, const nsID & {...},
nsWidgetInitData * 0x0012ee98, void * 0x00000000, int 1) line 973
nsScrollPortView::CreateScrollControls(nsScrollPortView * const 0x03b334d0, void
* 0x00000000) line 177
nsScrollBoxFrame::CreateScrollingView(nsIPresContext * 0x03b05c70) line 310
nsScrollBoxFrame::Init(nsScrollBoxFrame * const 0x028ec484, nsIPresContext *
0x03b05c70, nsIContent * 0x03b07910, nsIFrame * 0x028ec21c, nsIStyleContext *
0x028b0ae0, nsIFrame * 0x00000000) line 116
nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x03b05c70,
nsFrameConstructorState & {...}, nsIContent * 0x03b07910, nsIFrame * 0x028ec21c,
nsIStyleContext * 0x028b0ae0, nsIFrame * 0x00000000, nsIFrame * 0x028ec484) line
6489 + 32 bytes
nsCSSFrameConstructor::BeginBuildingScrollFrame(nsIPresShell * 0x03b00a20,
nsIPresContext * 0x03b05c70, nsFrameConstructorState & {...}, nsIContent *
0x03b07910, nsIStyleContext * 0x028ec184, nsIFrame * 0x028ec0c8, nsIAtom *
0x016f6d70, nsIDocument * 0x03afbc90, int 1, nsIFrame * & 0x028ec21c,
nsCOMPtr<nsIStyleContext> & {...}, nsIFrame * & 0x00000000, nsIFrame *
0x00000000) line 5
nsCSSFrameConstructor::ConstructRootFrame(nsCSSFrameConstructor * const
0x03b00140, nsIPresShell * 0x03b00a20, nsIPresContext * 0x03b05c70, nsIContent *
0x03b07910, nsIFrame * & 0x00000000) line 3662
StyleSetImpl::ConstructRootFrame(StyleSetImpl * const 0x03b00210, nsIPresContext
* 0x03b05c70, nsIContent * 0x03b07910, nsIFrame * & 0x00000000) line 1179 + 39 bytes
PresShell::InitialReflow(PresShell * const 0x03b00a20, int 15750, int 7380) line
2620
HTMLContentSink::StartLayout() line 3907
HTMLContentSink::DidBuildModel(HTMLContentSink * const 0x03afdd90, int 0) line 2747
CNavDTD::DidBuildModel(CNavDTD * const 0x03b02e50, unsigned int 2152596471, int
1, nsIParser * 0x03afe7e0, nsIContentSink * 0x03afdd90) line 666 + 14 bytes
nsParser::DidBuildModel(unsigned int 2152596471) line 1418 + 60 bytes
nsParser::Terminate() line 1494
nsHTMLDocument::StopDocumentLoad(nsHTMLDocument * const 0x03afbc90) line 879
DocumentViewerImpl::Stop(DocumentViewerImpl * const 0x03afee40) line 1238
nsDocShell::Stop(nsDocShell * const 0x03ae51a0, unsigned int 3) line 2300
nsDocShell::Destroy(nsDocShell * const 0x03ae51a4) line 2445
nsWebShell::Destroy(nsWebShell * const 0x03ae51a4) line 1412
nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame() line 696
nsHTMLFrameInnerFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsFrame::Destroy(nsFrame * const 0x028a2400, nsIPresContext * 0x03aefd40) line
468 + 34 bytes
nsFrameList::DestroyFrames(nsIPresContext * 0x03aefd40) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x028a23c0, nsIPresContext *
0x03aefd40) line 136
nsFrameList::DestroyFrames(nsIPresContext * 0x03aefd40) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x028a225c, nsIPresContext *
0x03aefd40) line 136
nsLineBox::DeleteLineList(nsIPresContext * 0x03aefd40, nsLineBox * 0x028a255c)
line 267
nsBlockFrame::Destroy(nsBlockFrame * const 0x028a1ed0, nsIPresContext *
0x03aefd40) line 326 + 16 bytes
nsFrameList::DestroyFrame(nsIPresContext * 0x03aefd40, nsIFrame * 0x028a1ed0)
line 217
CanvasFrame::RemoveFrame(CanvasFrame * const 0x028a181c, nsIPresContext *
0x03aefd40, nsIPresShell & {...}, nsIAtom * 0x00000000, nsIFrame * 0x028a1ed0)
line 371
FrameManager::RemoveFrame(FrameManager * const 0x03ab35b0, nsIPresContext *
0x03aefd40, nsIPresShell & {...}, nsIFrame * 0x028a181c, nsIAtom * 0x00000000,
nsIFrame * 0x028a1ed0) line 859
nsCSSFrameConstructor::ReconstructDocElementHierarchy(nsCSSFrameConstructor *
const 0x03ab3e20, nsIPresContext * 0x03aefd40) line 7171 + 61 bytes
StyleSetImpl::ReconstructDocElementHierarchy(StyleSetImpl * const 0x03ab3ef0,
nsIPresContext * 0x03aefd40) line 1186
PresShell::ReconstructFrames() line 5112 + 41 bytes
PresShell::StyleSheetAdded(PresShell * const 0x03ab6068, nsIDocument *
0x03ae5b90, nsIStyleSheet * 0x03b0ca40) line 5124
nsDocument::InsertStyleSheetAt(nsDocument * const 0x03ae5b90, nsIStyleSheet *
0x03b0ca40, int 0, int 1) line 1386
CSSLoaderImpl::InsertSheetInDoc(nsICSSStyleSheet * 0x03b0ca40, int 0, nsIContent
* 0x03af5530, int 1, nsICSSLoaderObserver * 0x00000000) line 1120
CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x03b0ca40, SheetLoadData *
0x03af0f00) line 823
CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x03b098d0, SheetLoadData *
0x03af0f00, int & 1, nsICSSStyleSheet * & 0x03b0ca40) line 878
CSSLoaderImpl::DidLoadStyle(nsIStreamLoader * 0x03af0df0, nsString * 0x03b09880,
SheetLoadData * 0x03af0f00, unsigned int 0) line 913 + 27 bytes
SheetLoadData::OnStreamComplete(SheetLoadData * const 0x03af0f00,
nsIStreamLoader * 0x03af0df0, nsISupports * 0x00000000, unsigned int 0, unsigned
int 1894, const char * 0x02972028) line 670
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x03af0df4, nsIRequest *
0x03af0c60, nsISupports * 0x00000000, unsigned int 0) line 136 + 81 bytes
nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x03b09830,
nsIRequest * 0x03af0c60, nsISupports * 0x00000000, unsigned int 0) line 25
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x03af0c64, nsIRequest *
0x03af1334, nsISupports * 0x00000000, unsigned int 0) line 2336
nsOnStopRequestEvent::HandleEvent() line 177
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x03b0a804) line 80
PL_HandleEvent(PLEvent * 0x03b0a804) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x016e4960) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x01920242, unsigned int 49577, unsigned int 0,
long 24004960) line 1071 + 9 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
main(int 1, char * * 0x00645d10) line 172 + 11 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e97d08()
It looks like we are getting a stylesheet in the middle of the document, which
makes us throw away all of the frames and rebuild the frame model. However, in
tearing down an IFRAME frame we end up stopping the webshell's loading, which
calls DidBuildDocument which then tries to build all of the frames for the
IFRAME's document, but the IFRAME frame has already been deleted!
Soem serious plumbing problems here - I have another bug related to this too,
but it is jsut a contrived testcase and this one is much more intriguing because
it is on a real page.
Status: NEW → ASSIGNED
|
|
||
Updated•23 years ago
|
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
|
|
||
Comment 8•23 years ago
|
||
|
|
||
Comment 9•23 years ago
|
||
Comment on attachment 53025 [details]
testcase that crashes Moz
I cannot access this testcase for some reason - but I have a better one anyway...
Attachment #53025 -
Attachment is obsolete: true
|
|
||
Comment 10•23 years ago
|
||
|
||
Comment 11•23 years ago
|
||
*** Bug 102471 has been marked as a duplicate of this bug. ***
|
|
||
Comment 12•23 years ago
|
||
So the problem is that the IFrame is being destroyed due to a full reframe
because of a new stylesheet (OK, the stylesheet was never loaded, but that is
another problem). In the destructor of the frame, we destroy the webShell, which
will Stop the docViewer, which calls document stopDocumentLoad, which then
termnates the parser. Whent he parser is terminated, it throws what it has to
the contentSink and we start layout - in the destroyed frame!
I think we need to abort the document load somehow so that we do not try and
build a layout model. I'll have to find out how this is done - I have no clue.
But deleting a frame should NOT cause that frame's document to be layed out.
Here is the offending sequence from the callstack, btw:
[snip]
PresShell::InitialReflow(PresShell * const 0x03b00a20, int 15750, int 7380) line
2620
HTMLContentSink::StartLayout() line 3907
HTMLContentSink::DidBuildModel(HTMLContentSink * const 0x03afdd90, int 0) line 2747
CNavDTD::DidBuildModel(CNavDTD * const 0x03b02e50, unsigned int 2152596471, int
1, nsIParser * 0x03afe7e0, nsIContentSink * 0x03afdd90) line 666 + 14 bytes
nsParser::DidBuildModel(unsigned int 2152596471) line 1418 + 60 bytes
nsParser::Terminate() line 1494
nsHTMLDocument::StopDocumentLoad(nsHTMLDocument * const 0x03afbc90) line 879
DocumentViewerImpl::Stop(DocumentViewerImpl * const 0x03afee40) line 1238
nsDocShell::Stop(nsDocShell * const 0x03ae51a0, unsigned int 3) line 2300
nsDocShell::Destroy(nsDocShell * const 0x03ae51a4) line 2445
nsWebShell::Destroy(nsWebShell * const 0x03ae51a4) line 1412
nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame() line 696
nsHTMLFrameInnerFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsFrame::Destroy(nsFrame * const 0x028a2400, nsIPresContext * 0x03aefd40) line
[snip]
Summary: crash opening URL w/ JavaScript enabled → crash opening URL w/ JavaScript enabled [@ nsWindow::Create]
|
||
Comment 13•23 years ago
|
||
*** Bug 107213 has been marked as a duplicate of this bug. ***
|
|
||
Comment 14•23 years ago
|
||
*** Bug 107792 has been marked as a duplicate of this bug. ***
|
|
||
Comment 15•23 years ago
|
||
[Reproducing hyatt's comments from bug 101554. Similar to what Marc said above]
------- Additional Comments From David Hyatt 2001-10-22 16:05 -------
[...] we then promptly crash in layout. There's a gaping
architectural problem here, which is that iframes that are being torn down
call Stop() on the docshell, which causes the page to attempt to display what
it's got so far. WHen a docshell is being destroyed, this is ridiculous. We
waste time firing onload, the parser calls DidBuildModel, we lay out and
reflow, etc. etc.
[...] someone is going to need to look at the more serious architectural problem
here.
|
|
||
Comment 16•23 years ago
|
||
Moving up to 0.9.7. Note that this will likely be fixed when we start loading
IFRAME / FRAME documents in the content node instead of in the layout frame. jst
will be workin on this next milestone, but I will keep this in case his plan
changes and we need to fix the ridiculous way that we tear down the frameFrame.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
|
|
||
Comment 17•23 years ago
|
||
*** Bug 101470 has been marked as a duplicate of this bug. ***
|
|
||
Comment 18•23 years ago
|
||
Marking as dependent of bug 52334 - once Johnny fixes that this problem will go
away, as will the architectural hole.
Depends on: 52334
Summary: crash opening URL w/ JavaScript enabled [@ nsWindow::Create] → [DEP 52334 ]crash opening URL w/ JavaScript enabled [@ nsWindow::Create]
|
||
Comment 19•23 years ago
|
||
*** Bug 110956 has been marked as a duplicate of this bug. ***
|
|
||
Comment 20•23 years ago
|
||
reassigning to jst since he is taking care of the fix. This could either be
considered a dup of bug 52334, or we could just keep it dependent and test it
when that bug is fixed.
NOTE: without the fix for bug 52334, fixing this will be quite heinous.
Assignee: attinasi → jst
Status: ASSIGNED → NEW
|
Assignee | |
Comment 21•23 years ago
|
||
I'll dupe this against bug 52334, but please don't verify it as a dupe until bug
52334 is fixed.
*** This bug has been marked as a duplicate of 52334 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Target Milestone: mozilla0.9.7 → mozilla0.9.9
|
|
||
Comment 22•23 years ago
|
||
*** Bug 112886 has been marked as a duplicate of this bug. ***
|
||
Updated•13 years ago
|
Crash Signature: [@ nsWindow::Create]
You need to log in
before you can comment on or make changes to this bug.
Description
•