New issue
Advanced search Search tips

Issue 752168 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug

Blocking:
issue 82385



Sign in to add a comment

ContentBrowserTest stack symbolication tests failing on CrWinAsan, likely after https://codereview.chromium.org/2857643002

Project Member Reported by thakis@chromium.org, Aug 3 2017

Issue description

Started here: https://luci-milo.appspot.com/buildbot/chromium.fyi/CrWinAsan%20tester/1739

https://codereview.chromium.org/2857643002 assumes we externally symbolize.

ContentBrowserTest.BrowserCrashCallStack
ContentBrowserTest.RendererCrashCallStack
 

Comment 1 by r...@chromium.org, Aug 8 2017

Cc: r...@chromium.org

Comment 2 by r...@chromium.org, Nov 6 2017

Owner: r...@chromium.org
Project Member

Comment 3 by bugdroid1@chromium.org, Nov 8 2017

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

commit 5d357ed23c6f0c4b34971935752877519e451191
Author: Reid Kleckner <rnk@google.com>
Date: Wed Nov 08 23:40:51 2017

Fix crash content_browsertests callstack tests under WinASan

First, there is a use-after-return in the browser process of
MANUAL_RendererCrash. It registers a crash observer which gets called
back after the renderer process exits.

Second, RendererProcessExited checks the termination status. When ASan
catches the crash access violation, it ultimately exits with the default
exit code of 1. Code in base/process/kill_win.cc classifies an exit code
of 1 as TERMINATION_STATUS_PROCESS_WAS_KILLED. Exit code 1 is pretty
common, so that classification is suspicious to me, but it is what
happens today.

Third, BrowserCrashCallstack crashes with DCHECK(false), which crashes
with __debugbreak. ASan isn't currently set up to handle
EXCEPTION_BREAKPOINT, although it can be configured to do this. As a
result, Chromium does the stack dumping, and it does not contain the
string "#0 ". This is *not* the case in the renderer test case, which
crashes with an access violation, and gets an ASan report. However,
Windows ASan knows how to symbolize stack traces even inside a sandbox,
so it's still correct to look for the symbolized frame.

Last but not least, there seems to be some conflict between TSan, the
Linux sandbox, and dumping the stack from a renderer process. Disabling
the sandbox makes the test dump its stack as expected, so I went ahead
and did that.

R=wfh@chromium.org

Bug:  752168 
Change-Id: I639e7947db3c1d47fbefb48f3c94b11832b0765b
Reviewed-on: https://chromium-review.googlesource.com/755760
Commit-Queue: Reid Kleckner <rnk@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515007}
[modify] https://crrev.com/5d357ed23c6f0c4b34971935752877519e451191/content/test/content_browser_test_test.cc

Comment 4 by thakis@chromium.org, Feb 28 2018

Status: Fixed (was: Assigned)

Sign in to add a comment