asan stack-use-after-scope in browser_tests on ClangToTMacASan tester |
||||||||
Issue descriptionhttps://build.chromium.org/p/chromium.fyi/builders/ClangToTMacASan%20tester is showing stack-use-after-scope errors. From https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.fyi%2FClangToTMacASan_tester%2F4052%2F%2B%2Frecipes%2Fsteps%2Fbrowser_tests%2F0%2Fstdout [ RUN ] AppControllerMainMenuBrowserTest.BookmarksMenuIsRestoredAfterProfileSwitch ================================================================= ==4877==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fff539ecc80 at pc 0x00011cd9eedb bp 0x7fff539ecc50 sp 0x7fff539ecc48 WRITE of size 8 at 0x7fff539ecc80 thread T0 #0 0x11cd9eeda in HistoryMenuBridge::ClearMenuSection(NSMenu*, long) ??:0:0 #1 0x11cd9d3b4 in HistoryMenuBridge::TabRestoreServiceChanged(sessions::TabRestoreService*) ??:0:0 #2 0x11cd9c4c8 in HistoryMenuBridge::HistoryMenuBridge(Profile*) ??:0:0 #3 0x113f73202 in -[AppController windowChangedToProfile:] ??:0:0 #4 0x10c24aa52 in (anonymous namespace)::AppControllerMainMenuBrowserTest_BookmarksMenuIsRestoredAfterProfileSwitch_Test::RunTestOnMainThread() ??:0:0 #5 0x113ee7aef in InProcessBrowserTest::RunTestOnMainThreadLoop() ??:0:0 #6 0x1153a3a89 in content::BrowserTestBase::ProxyRunTestOnMainThreadLoop() ??:0:0 #7 0x114049d04 in ChromeBrowserMainParts::PreMainMessageLoopRunImpl() ??:0:0 #8 0x114047195 in ChromeBrowserMainParts::PreMainMessageLoopRun() ??:0:0 #9 0x1102f1a4d in content::BrowserMainLoop::PreMainMessageLoopRun() ??:0:0 #10 0x110dce813 in content::StartupTaskRunner::RunAllTasksNow() ??:0:0 #11 0x1102ebc74 in content::BrowserMainLoop::CreateStartupTasks() ??:0:0 #12 0x1102fbeb4 in content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const&) ??:0:0 #13 0x1102e4111 in content::BrowserMain(content::MainFunctionParams const&) ??:0:0 #14 0x113c157eb in content::ContentMainRunnerImpl::Run() ??:0:0 #15 0x11968adf3 in service_manager::Main(service_manager::MainParams const&) ??:0:0 #16 0x113c1397b in content::ContentMain(content::ContentMainParams const&) ??:0:0 #17 0x1153a2b21 in content::BrowserTestBase::SetUp() ??:0:0 #18 0x113ee4b3a in InProcessBrowserTest::SetUp() ??:0:0 #19 0x116b69a7f in testing::Test::Run() ??:0:0 #20 0x116b6bb43 in testing::TestInfo::Run() ??:0:0 #21 0x116b6cec6 in testing::TestCase::Run() ??:0:0 #22 0x116b80b96 in testing::internal::UnitTestImpl::RunAllTests() ??:0:0 #23 0x116b80108 in testing::UnitTest::Run() ??:0:0 #24 0x113f2ffd5 in base::TestSuite::Run() ??:0:0 #25 0x113c3f2a0 in ChromeTestSuiteRunner::RunTestSuite(int, char**) ??:0:0 #26 0x11544df42 in content::LaunchTests(content::TestLauncherDelegate*, int, int, char**) ??:0:0 #27 0x113c3f0c2 in main ??:0:0 #28 0x7fff8c5a85fc in start ??:0:0 Address 0x7fff539ecc80 is located in stack of thread T0 at offset 32 in frame #0 0x11cd9e65f in HistoryMenuBridge::ClearMenuSection(NSMenu*, long) ??:0:0 This frame has 3 object(s): [32, 40) 'menu_item' (line 256) <== Memory access at offset 32 is inside this variable [64, 128) 'state.ptr' [160, 288) 'items.ptr' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-use-after-scope (/b/swarm_slave/w/irjMBG1h/out/Release/./browser_tests:x86_64+0x110b90eda) Shadow bytes around the buggy address: 0x1fffea73d940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffea73d950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffea73d960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffea73d970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffea73d980: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 =>0x1fffea73d990:[f8]f2 f2 f2 00 00 00 00 00 00 00 00 f2 f2 f2 f2 0x1fffea73d9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffea73d9b0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffea73d9c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffea73d9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffea73d9e0: f1 f1 f1 f1 f8 f2 f2 f2 f8 f8 f8 f3 f3 f3 f3 f3 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==4877==ABORTING Received signal 6 [0x000113c6a31c] [0x000113c6a019] [0x7fff932ae5aa] [0x7fff95b933af] [0x7fff8f1cab2e] [0x00012e86a546] [0x00012e865b38] [0x00012e84d7b7] [0x00012e84d22b] [0x00012e84e3f9] [0x00011cd9eedb] [0x00011cd9d3b5] [0x00011cd9c4c9] [0x000113f73203] [0x00010c24aa53] [0x000113ee7af0] [0x0001153a3a8a] [0x000114049d05] [0x000114047196] [0x0001102f1a4e] [0x000110dce814] [0x0001102ebc75] [0x0001102fbeb5] [0x0001102e4112] [0x000113c157ec] [0x00011968adf4] [0x000113c1397c] [0x0001153a2b22] [0x000113ee4b3b] [0x000116b69a80] [0x000116b6bb44] [0x000116b6cec7] [0x000116b80b97] [0x000116b80109] [0x000113f2ffd6] [0x000113c3f2a1] [0x00011544df43] [0x000113c3f0c3] [0x7fff8c5a85fd] [end of stack trace]
,
Apr 4 2017
glider, assigning to you because I think you may be a good person to decide on a course of action.
,
Apr 4 2017
,
Apr 4 2017
[Mac Sheriff] Tentatively bumping to P1. I have a hunch that this was 0f51324df2b3f6a90d7454fe66a17c012bd16277.
,
Apr 5 2017
+Nico, Hans assuming they're in charge of the Clang ToT tester. Folks, do you know why is the file:line info missing on this bot?
,
Apr 5 2017
We tried to give it the same config as other Mac asan bots. Are stacks symbolized elsewhere? Maybe someone broke them everywhere? If they work elsewhere, I'd check what's different with this bot's config.
,
Apr 5 2017
Oh, sorry, this must be issue 700543. Looks like the symbols on the bots are still missing.
,
Apr 5 2017
Ivan, can you please take a look? According to issue 649897 , the report in question is known and should have been blocking the UAS detection from being enabled on Mac. Has anything changed since then? I took a brief glance at HistoryMenuBridge::ClearMenuSection() and couldn't see any errors there, so either my ObjC-fu is rusty or the use-after-scope detection doesn't handle the ObjC locals correctly. In either case I don't even have an Mac machine to try this out.
,
Apr 5 2017
I think I saw a commit enabling uas by default upstream, so we probably need to explicit disable it now somehow?
,
Apr 5 2017
When I made a use-after-scope fixit, I didn't cover Mac (in particular, because I don't have one): https://crbug.com/649897 . Then (I guess) some CL enabled this check for all the platforms. That change must be identified and reverted, as it was submitted before fixing existing failures.
,
Apr 5 2017
Interesting, the guards are still there (build/config/sanitizers/BUILD.gn):
cflags += [ "-fsanitize=address" ]
if (!is_mac && !is_win) {
cflags += [ "-fsanitize-address-use-after-scope" ]
}
...
if (is_asan) {
ldflags += [ "-fsanitize=address" ]
if (!is_mac) {
ldflags += [ "-fsanitize-address-use-after-scope" ]
}
}
Which makes me wonder who did that bot even got the option enabled.
,
Apr 5 2017
It was enabled in clang r299174. Reverting that for chrome tests doesn't seem super reasonable to me – isn't there some "turn this off again" flag we can pass? (If not, there should be one)
,
Apr 5 2017
Ah, thanks. Yes, Clang can do that, and we can't make a case for a revert just because a Chrome test is broken. Let me check the flags we have in sanitizers. It's plenty of them.
,
Apr 5 2017
Maybe it's spelled -fno-sanitize-address-use-after-scope ?
,
Apr 5 2017
,
Apr 5 2017
Yes, it is spelled like that. :)
,
Apr 5 2017
,
Apr 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/69faa6a6ffc1ceebf4d499618a5d17c8a1e7af67 commit 69faa6a6ffc1ceebf4d499618a5d17c8a1e7af67 Author: krasin <krasin@chromium.org> Date: Wed Apr 05 19:48:01 2017 Turn off use-after-scope check on Mac. It was disabled in BUILD.gn, because there are known failures, but recently Clang enabled it by default, so we have to opt out. Eventually, we need to clean up these failures and reenable the check as it's useful. BUG=708216, 708707 Review-Url: https://codereview.chromium.org/2797253002 Cr-Commit-Position: refs/heads/master@{#462187} [modify] https://crrev.com/69faa6a6ffc1ceebf4d499618a5d17c8a1e7af67/build/config/sanitizers/BUILD.gn
,
Jul 20 2017
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by inglorion@chromium.org
, Apr 4 2017