Closed Bug 591330 Opened 10 years ago Closed 10 years ago

Firefox crashes whenever I open the site [@ nsHtml5TreeOperation::AppendText]

Categories

(Core :: DOM: HTML Parser, defect, P2, critical)

All
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: ryanli, Assigned: hsivonen)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b5pre) Gecko/20100826 Minefield/4.0b5pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b5pre) Gecko/20100826 Minefield/4.0b5pre

Whenever I tried to open http://www.cdcf.ngo.cn, Firefox 4.0 nightly crashes.
However, Firefox 3.6.8 works quite fine

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.cdcf.ngo.cn
Actual Results:  
Firefox crashes.

Expected Results:  
It should not crash.
Would you check for a crash report by typing about:crashes in the address bar.

https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report
OK, I got the ID:
bp-0de7af58-7ce7-4584-8e07-ce8b62100827
Signature	nsHtml5TreeOperation::AppendText
UUID	0de7af58-7ce7-4584-8e07-ce8b62100827
Time 	2010-08-27 17:16:54.78198
Uptime	13
Last Crash	37721 seconds (10.5 hours) before submission
Install Age	76016 seconds (21.1 hours) since version was first installed.
Product	Firefox
Version	4.0b5pre
Build ID	20100826031217
Branch	2.0
OS	Linux
OS Version	0.0.0 Linux 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:12:52 UTC 2010 i686
CPU	x86
CPU Info	GenuineIntel family 6 model 37 stepping 2
Crash Reason	SIGSEGV
Crash Address	0x2a7c0800
User Comments	
Processor Notes 	
EMCheckCompatibility	False
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	libxul.so 	nsHtml5TreeOperation::AppendText 	nsINode.h:945
1 	libxul.so 	nsHtml5TreeOperation::Perform 	parser/html/nsHtml5TreeOperation.cpp:555
2 	libxul.so 	nsHtml5TreeOpExecutor::RunFlushLoop 	parser/html/nsHtml5TreeOpExecutor.cpp:485
3 	libxul.so 	nsHtml5ExecutorFlusher::Run 	parser/html/nsHtml5StreamParser.cpp:153
4 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:547
5 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
6 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
7 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
8 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:202
9 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:175
10 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:191
Severity: major → critical
Component: General → HTML: Parser
Keywords: crash
Product: Firefox → Core
QA Contact: general → parser
Summary: Firefox crashes whenever I open the site → Firefox crashes whenever I open the site [@ nsHtml5TreeOperation::AppendText]
Version: unspecified → Trunk
Confirmed on x86_64. I'll have to take a look in a debugger, but my scientific guess is that this is a duplicate of nsTArray not being infallible yet.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
That was the wrong guess. aParent is 0xC0DEDBAD in debug builds, which means the parent node never got created.
The crashing page is http://www.cdcf.ngo.cn/bot.html it crashes for me on Linux64 when loading from the network. It doesn't crash when loading from the cache or when loading from a file: URL. It doesn't crash for me on Mac.

The page has some deeply-nesting spans, which suggests that the deep nesting prevention code could be to blame. However, the timing-dependence (not crashing from cache) suggests that speculations are to blame.

On the most basic level, the problem is that the parser is supposed to have the property that if an eTreeOpAppendText operation ever get executed an eTreeOpCreateElementNetwork or eTreeOpCreateElementNotNetwork operation will have run first creating the node that eTreeOpAppendText tries to append to.

It seems that the element creation op has gotten dropped somehow (or never existed) but the subsequent text appending op didn't get dropped together with it.
Best guess so far: The tree builder state snapshotting code fails to consider mDeepTreeSurrogateParent in the snapshot.
(Making the snapshots support fields defined in C++ would have been more complicated than introducing some code that's not really needed in non-Gecko contexts.)
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Attachment #471465 - Flags: review?(jonas)
Nominating as a blocker, since this is a crash with a very low-risk fix.
blocking2.0: --- → ?
Duplicate of this bug: 587822
blocking2.0: ? → betaN+
Comment on attachment 471465 [details] [diff] [review]
Move mDeepTreeSurrogateParent to the Java side and make it participate in tree builder snapshotting

r=me if you also write a testcase.
Attachment #471465 - Flags: review?(jonas) → review+
(In reply to comment #11)
> Comment on attachment 471465 [details] [diff] [review]
> Move mDeepTreeSurrogateParent to the Java side and make it participate in tree
> builder snapshotting
> 
> r=me if you also write a testcase.

I have trouble provoking the crash locally when I try to. Here's a obvious test case that would be nice to have in the tree and that's supposed to test for this crash. However, it's not really a test for this bug, since it doesn't crash without the fix for this bug.

Is it OK to land the fix that seems to fix the problem as seen with the site even though there's no true crashtest?
Attachment #471814 - Flags: review?(jonas)
Priority: -- → P2
http://hg.mozilla.org/mozilla-central/rev/729107825a48
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
Depends on: 610786
Crash Signature: [@ nsHtml5TreeOperation::AppendText]
You need to log in before you can comment on or make changes to this bug.