Closed Bug 185207 Opened 23 years ago Closed 21 years ago

Crash - Stack Overflow -MSVCRT.DLL + 0x60d8 (0x780060d8) bc71d56d

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bc, Assigned: peterv)

References

Details

(Keywords: crash)

Attachments

(3 files)

html file included into test page via iframe
1.45 KB, text/html
Details
testcase
273 bytes, text/html
Details
remains of the stack
131.83 KB, text/plain
Details
Attempting to test some dom 2 traversal range code of which I am unfamiliar crashed both 1.0.2 20021120 and the trunk 2002120908/win2k. test case coming up. http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=15053614 Other tb incidents but haven't been able to get them to send yet.
Attached file testcase —
over to dom dudes for a look to see where this should land.
Assignee: anthonyd → peterv
I did a similar test case using innerHTML to replace the span in the parent page. On initial tries, it worked as I expected but on subsequent runs it seemed to cause the script contained in the body tag of the included page to execute in an infinite loop in 1.0.2 but not in the trunk. So perhaps the copying of the content via traversal is causing the stack overflow.
FYI crashes also on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 TB id is TB15059044W
Attached file remains of the stack —
Here's the part of the stack that I was able to grab.
Note: stack trace was from 121203 Win2k
Yet another script recursion ugliness. The troublesome code is in a <script> tag inside the <body> in the iframe. This code attempts to create a fragment from document.body.innerHTML and append it to the parent. This creates a new <script> and adds it to the parent document. When this happens the newly created inline script element will execute in the parent. But by this time the parent document's body.innerHTML property already contains the new <script>, so we will end up creating even more <script>s and trying to execute them and promptly proceed to blow up. FWIW, a "workaround" in this case would be to move the <script> outside the <body> and call replaceStaticSpan() from onload().
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
I have had crashes in MSVCRT.DLL with 1.3 release candidate 1 and 2, and in the final release. I Wonder if its this bug? The release candidates didn't catch the crashes in the "crash manager" (I always forget what its called), but final release does. This is from my latest crash in 1.3final on my Windows 98: MOZILLA caused an invalid page fault in module MSVCRT.DLL at 0187:7800b936. Registers: EAX=0384d4d8 CS=0187 EIP=7800b936 EFLGS=00010202 EBX=00000000 SS=018f ESP=0065e138 EBP=0065e154 ECX=00000120 DS=018f ESI=03caf95c FS=4d0f EDX=00000000 ES=018f EDI=00000003 GS=0000 Bytes at CS:EIP: 89 5a 04 8b 55 0c 89 4d fc 8b 5a 04 8b 52 08 89 Stack dump: 038a90bc 03caf960 00000001 0384dc28 00000000 00000031 00000120 0065e198 7800b30c 00770138 03cafa7c 038a90bc 007b31b0 00000001 03caf980 bff7b9b6 Is it this bug? I haven't found a way to reproduce it for sure. Seems to happen pretty random.
I just had a crash in MSVCRT.DLL in 1.7 post-alpha. Anyone else seeing that?
(In reply to comment #2) > Created an attachment (id=109228) > testcase > Crashes here... talkbackid: TB8695Z Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040330 Microsoft Windows 2000 Pro 5.00.2195 SP4
top of Anders' stack track from talkback: CalculateUTF8Length::write[../../../dist/include/string\nsUTF8Utils.h,[ine[29] copy_string[../../../dist/include/string\nsAlgorithm.h,[ine[7] AppendUTF8toUTF16[/mozilla/xpcom/string/src/nsReadableUtils.cpp,[ine[19] AtomImpl::ToString[/mozilla/xpcom/ds/nsAtomTable.cpp,[ine[63] nsAttrValue::ToString[/mozilla/content/base/src/nsAttrValue.cpp,[ine[90] nsGenericHTMLElement::GetAttr[/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,[ine[776] nsHTMLDocument::RemoveFromIdTable[/mozilla/content/html/document/src/nsHTMLDocument.cpp,[ine[168] nsHTMLDocument::UnregisterNamedItems[/mozilla/content/html/document/src/nsHTMLDocument.cpp,[ine[212] nsHTMLDocument::UnregisterNamedItems[/mozilla/content/html/document/src/nsHTMLDocument.cpp,[ine[222] nsHTMLDocument::UnregisterNamedItems[/mozilla/content/html/document/src/nsHTMLDocument.cpp,[ine[222] nsHTMLDocument::UnregisterNamedItems[/mozilla/content/html/document/src/nsHTMLDocument.cpp,[ine[222]
Still crashes for me as well with today's build on WinXP. Crashes so bad I can't send a talkback and my debug build just craps out without even bringing up the Debug dialog.
It crashes also my linux GTK2 build : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040401 Firefox/0.8.0+
Fixed by bug 220408.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Well, it pegged my cpu, began slow unbounded memory increase, and locked up Mozilla so I had to kill it... but it didn't crash.
/me recalls telling jst something about testing before closing ;-)
Well, no more stack overflow, no? ;) Sounds like there's still a bug here, but it aint a stack overflow any more. Should we reopen, or file a new bug? I'm game either way, but we need a new subject if we reopen.
I'll file a new bug later tonight and comment here.
hang filed as Bug 240025
Component: DOM: Traversal-Range → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: