Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Since this issue is tagged with GPU>SwiftShader label, cc'ing to swiftshader dev for more updates on this issue

capn@ - Could you please take a look in to this issue?

Thanks!

ClusterFuzz has detected this issue as fixed in range 536320:536321.

Detailed report: https://clusterfuzz.com/testcase?key=5300765724508160

Fuzzer: tokenfuzz_pdf_march16
Job Type: linux_ubsan_chrome
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  sw::FrameBufferX11::FrameBufferX11
  createFrameBuffer
  egl::WindowSurface::reset
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=535623:535643
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=536320:536321

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5300765724508160

Additional requirements: Requires Gestures

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5300765724508160 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Reopening this because I want to understand what happened and prevent it from reoccurring.

Steve, do you have any ideas for why your "Enable root layer scrolling" change appears to have caused these X11 initialization issues in SwiftShader?

 Issue 807079  and  Issue 807079  are also very similar, and the latter was a top crasher for ClusterFuzz so we want to make sure it doesn't happen again.

Sorry, I'm not sure why RLS would affect SwiftShader.

We are planning to reland it soon so it would be great to understand this better.

The stack trace is odd, I wonder if the frames above LocalFrameView::InvalidatePaintForTickmarks are invalid?

Could this be a stable blocker for M65 based on comment #6?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/31fede9e0fffad7abd89a90ae6aedb35990561c5

commit 31fede9e0fffad7abd89a90ae6aedb35990561c5
Author: Steve Kobes <skobes@chromium.org>
Date: Wed Feb 14 18:36:55 2018

Speculative fix for crash in LocalFrameView::InvalidatePaintForTickmarks.

Bug:  811073 
Change-Id: Id357417202933651460086559f34238b363142c7
Reviewed-on: https://chromium-review.googlesource.com/919258
Reviewed-by: Stefan Zager <szager@chromium.org>
Commit-Queue: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536760}
[modify] https://crrev.com/31fede9e0fffad7abd89a90ae6aedb35990561c5/third_party/WebKit/Source/core/frame/LocalFrameView.cpp

Potentially related to Issue 819481, which was addressed by: https://swiftshader-review.googlesource.com/17708

Closing this again since there are no new leads about the true cause of it, but things appear stable now.