Null-dereference in IsChromeSettingsAppOrPopupWindow |
|||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5843751166803968 Fuzzer: meacer_extension_apis Job Type: windows_syzyasan_chrome Platform Id: windows Crash Type: Null-dereference Crash Address: 0x00000003 Crash State: IsChromeSettingsAppOrPopupWindow SystemMenuModelBuilder::BuildSystemMenuForAppOrPopupWindow SystemMenuModelBuilder::BuildMenu Memory Tool: SYZYASAN Regressed: https://clusterfuzz.com/revisions?job=windows_syzyasan_chrome&range=367319:367361 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5843751166803968 Additional requirements: Requires Gestures Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Oct 1 2017
Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.
,
Oct 5 2017
Here is the change log form above CF report. https://chromium.googlesource.com/chromium/src/+log/24ad7029705b271d0a12107231a1db5f4d5abb6d..8d34e46c9a294b4d9a5f74e97d9e6536d34555c2?pretty=fuller&n=10000 msramek@, can you please look into this change (https://chromium.googlesource.com/chromium/src/+/995ab976f757b4c693610cb9f2caa6983495239a) if possible? Thank you!
,
Oct 5 2017
My change is in cocoa/, i.e. Mac-only, so it couldn't have affected Windows. (It's also in a different part of code). I don't see a good suspect at the first glance, but even if I did, the regression range is two years old. At this time, I think code owners would be more helpful.
,
Nov 7 2017
,
Nov 29 2017
,
Nov 30 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ca9f237833ea0b34529ffe7e398979047f8d8bf0 commit ca9f237833ea0b34529ffe7e398979047f8d8bf0 Author: Peter Kasting <pkasting@chromium.org> Date: Thu Nov 30 09:43:29 2017 Try to avoid crash by being more defensive about potentially-empty tabstrips. I've seen other places in the codebase that check for "no active WebContents", so it seems reasonable that maybe we need a similar check here? I'm not sure of the conditions when this can be true (I heard certain types of windows maybe never have a WebContents in them?). Along the way this also simplifies the existing code, and makes it more conservative (and IMO correct) about only marking the settings page, not any chrome internal page with "settings" in the hostname, as "a settings page". BUG= 764674 TEST=none Change-Id: I7d6e6c537509d5ca358b85948333fdc2896e7a69 Reviewed-on: https://chromium-review.googlesource.com/795650 Commit-Queue: Peter Kasting <pkasting@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#520492} [modify] https://crrev.com/ca9f237833ea0b34529ffe7e398979047f8d8bf0/chrome/browser/ui/views/frame/system_menu_model_builder.cc
,
Nov 30 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by msrchandra@chromium.org
, Sep 13 2017Labels: Test-Predator-Wrong-CLs M-63 CF-NeedsTriage