Null-dereference READ in chrome |
|||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6723712041353216 Fuzzer: mbarbella_js_mutation_layout Job Type: linux_cfi_chrome Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x000000000204 Crash State: chrome blink::Document::UpdateStyleAndLayoutTreeIgnorePendingStylesheets blink::Document::UpdateStyleAndLayoutIgnorePendingStylesheets Sanitizer: cfi (CFI) Regressed: https://clusterfuzz.com/revisions?job=linux_cfi_chrome&range=570924:570982 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6723712041353216 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Sep 5
Predator has provided 3 possible suspects 1. Remove use of WebLayerTreeViewImplForTesting in FrameTestHelpers by danakj@chromium.org 2. [css-logical] Implement flow-relative border longhand properties by obrufau@igalia.com 3. [RootLayerScrolls] Make scroll origin PLSA-specific. by szager@chromium.org Unable to find the suspect CL from above list, hence adding CF-NeedsTriage label for further triage
,
Sep 10
,
Sep 10
I don't think any of the suspect CL's is the culprit. Root cause appears to be that a "print" command was issued while a frame was still loading; then a navigation is issued before the frame finishes loading; and in the swapping-out code, the deferred print command still runs. The fix is probably to disabled the deferred print command when a frame is being swapped out.
,
Sep 13
Looking at the regression range, it could be: https://chromium.googlesource.com/chromium/src/+/91f94dcfb2e328e0e5c1f8c61f46e959bb98a556
,
Sep 15
I think this is actually due to https://chromium.googlesource.com/chromium/src/+/55d21e1555e7de5dd34e8ca115f27b3267870fee. Manually disabling error page isolation fixes the issue. Nasko, is this a known bug already? See also issue 862088, where we had to land a check to fight the similar problem (print while unloading).
,
Sep 30
Issue 890554 has been merged into this issue.
,
Sep 30
There was another recent issue similar to this (can't find it right now). It happens, I think, when a 'print' command is issued while a document is still loading; so the print command is deferred until the document finishes loading, but then the document gets swapped out before the load completes. I think a correct fix would be to reset the value of LocalDOMWindow::should_print_when_finished_loading_ from somewhere near the top of LocalFrame::DetachImpl.
,
Sep 30
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Oct 18
This is still happening on Latest M70 Beta/Stable# 70.0.3538.67. Could someone please look into it? Thank you!
,
Dec 3
I have a patch which fixes this one [1], but it's not 100% web-compatible. We should figure out whether disallowing print during unload is acceptable. Firefox does support this behavior. [1] https://chromium-review.googlesource.com/c/chromium/src/+/1297068
,
Dec 5
I thought we already disallow printing in unload handlers, is this different codepath?Adding dcheng@ as I think he did that a while ago.
,
Jan 5
ClusterFuzz testcase 5733834451320832 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by dtapu...@chromium.org
, Sep 4