Closed Bug 591330 Opened 10 years ago Closed 10 years ago
Firefox crashes whenever I open the site [@ ns
Html5Tree Operation::Append Text]
22.37 KB, patch
|Details | Diff | Splinter Review|
3.20 KB, patch
|Details | Diff | Splinter Review|
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
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: --- → ?
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)
Attachment #471814 - Flags: review?(jonas) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
Crash Signature: [@ nsHtml5TreeOperation::AppendText]
You need to log in before you can comment on or make changes to this bug.