Open Bug 1654805 Opened 4 months ago Updated 3 months ago

Crash in [@ nsHtml5TreeOpExecutor::FlushDocumentWrite]

Categories

(Core :: DOM: HTML Parser, defect)

defect

Tracking

()

Tracking Status
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- affected

People

(Reporter: sefeng, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-102ccdef-19d1-44b1-850d-668090200721.

Top 10 frames of crashing thread:

0 libxul.so nsHtml5TreeOpExecutor::FlushDocumentWrite parser/html/nsHtml5TreeOpExecutor.cpp:589
1 libxul.so nsHtml5Parser::Parse parser/html/nsHtml5Parser.cpp:344
2 libxul.so mozilla::dom::Document::WriteCommon dom/base/Document.cpp:9124
3 libxul.so mozilla::dom::Document::WriteCommon dom/base/Document.cpp:9027
4 libxul.so mozilla::dom::Document_Binding::write dom/bindings/DocumentBinding.cpp:3167
5 libxul.so bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3220
6 libxul.so js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:576
7 libxul.so js::jit::DoCallFallback js/src/jit/BaselineIC.cpp:3110
8  @0x24d33896abc7 
9  @0x7f43465ee267 

Since it's a release assert, I'd expect that this is something we don't expect to happen, but it's happening, so I am filing this bug.

Randomly finding someone who is in the commit log, not in PTO, and have less NIs. :mayhemer, do you mind taking a look?

Severity: -- → S3
Flags: needinfo?(honzab.moz)
Flags: needinfo?(honzab.moz) → needinfo?(hsivonen)

This is indeed very unexpected. RyanVM, who could look at the non-public crash stats for hints of steps to reproduce?

Flags: needinfo?(hsivonen) → needinfo?(ryanvm)

Not a lot of URLs or comments in the reports from the last 3 months. Just some random news and gaming sites from what I can see. One of the comments when run through a translator says:

big concerns, Firefox opens several browsers at the same time, for a request => 4 are covered

Flags: needinfo?(ryanvm)

Thanks. Random news and gaming sites suggests that document.write in ads triggers this.

I don't have good ideas of how to turn this into something actionable.

This is spiking up in release in the last couple of days.

Some comments mention ebay, and users seeing this crash repeatedly.

Severity: S3 → --

The severity field is not set for this bug.
:jstutte, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jstutte)

Hi John, can you please triage this? Thank you!

Flags: needinfo?(jstutte) → needinfo?(jdai)

This is very clearly bad, but the problem is that I don't know how to make this actionable. If someone catches this with steps to reproduce, please post the steps to reproduce.

I suspect a nested event loop created by synchronous XHR.

(In reply to Henri Sivonen (:hsivonen) from comment #10)

I suspect a nested event loop created by synchronous XHR.

Sure enough, seen e.g. here: https://crash-stats.mozilla.org/report/index/53c7f47b-0547-43bf-be1f-642d90200811

And that makes this somewhat more actionable. We can start trying to repro with sync XHR.

The spike subsided around August 12, suggesting the server-side cause went away.

Severity: -- → S2
Flags: needinfo?(jdai)

The general sketch for repro should be along the lines of:

<!-- HTML loaded from the network -->
<script>document.write("<scr" + "ipt>// Do synchronous XHR<\/script>");</script>
<script>document.write("foo");</script>

It's possible that something more complicated than the above sketch is needed for the second document.write.

You need to log in before you can comment on or make changes to this bug.