content_browsertests failing on CrWinAsanCov |
||||
Issue descriptionRegular CrWinAsan is fine. Has been happening for a while, e.g. https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/CrWinAsanCov/1862 It's a bunch of tests; they all have an access violation at SUMMARY: AddressSanitizer: access-violation c:\b\s\w\ir\cache\builder\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_coverage_libcdep_new.cc:177 in __sanitizer_cov_trace_pc_guard__def Since this is in the asan runtime with a _cov symbol and this only happens in Cov builds, maybe this is an asan runtime issue? Current list of failing tests: DomSerializerTests.SubResourceForElementsInNonHTMLNamespace ResourceFetcherTests.ResourceFetcherDownload ResourceFetcherTests.ResourceFetcherDidFail ResourceFetcherTests.ResourceFetcherTimeout ResourceFetcherTests.ResourceFetcherPost DomSerializerTests.SerializeHTMLDOMWithAddingMOTW ResourceFetcherTests.ResourceFetcherRedirect ResourceFetcherTests.ResourceFetcherSetHeader RenderThreadImplDiscardableMemoryBrowserTest.DiscardableMemoryAddressSpace RenderThreadImplDiscardableMemoryBrowserTest.ReleaseFreeDiscardableMemory ResourceFetcherTests.ResourceFetcherDeletedInCallback DomSerializerTests.SerializeHTMLDOMWithNonStandardEntities SavableResourcesTest.GetSavableResourceLinksWithPageHasValidStyleLink ContentBrowserTestSanityTest.SingleProcess IndexedDBBrowserTestSingleProcess.RenderThreadShutdownTest ResourceFetcherTests.ResourceFetcher404 DomSerializerTests.SerializeHTMLDOMWithoutDocType InProcessGpuTest.NoHangAtQuickLaunchAndShutDown RenderThreadImplDiscardableMemoryBrowserTest.ReleaseFreeMemory DomSerializerTests.SerializeHTMLDOMWithEmptyHead DomSerializerTests.SerializeHTMLDOMWithBaseTag SavableResourcesTest.GetSavableResourceLinksWithPageHasValidLinks InProcessGpuTest.NoCrashAtShutdown SavableResourcesTest.GetSavableResourceLinksWithPageHasInvalidLinks RenderThreadImplDiscardableMemoryBrowserTest.LockDiscardableMemory DomSerializerTests.SerializeHTMLDOMWithEntitiesInAttributeValue DomSerializerTests.SerializeHTMLDOMWithEntitiesInText DomSerializerTests.SerializeXMLDocWithBuiltInEntities RenderViewBrowserTest.ConfirmCacheInformationPlumbed One stack: [ RUN ] DomSerializerTests.SerializeHTMLDOMWithEntitiesInAttributeValue DevTools listening on ws://127.0.0.1:59565/devtools/browser/40240de0-6c68-415c-bf75-31db4acefef5 ================================================================= ==5528==ERROR: AddressSanitizer: access-violation on unknown address 0x12627c173cd8 (pc 0x7ff6e6111074 bp 0x003f444fd230 sp 0x003f444fd120 T7) ==5528==The signal is caused by a READ memory access. ==5528==*** WARNING: Failed to initialize DbgHelp! *** ==5528==*** Most likely this means that the app is already *** ==5528==*** using DbgHelp, possibly with incompatible flags. *** ==5528==*** Due to technical reasons, symbolization might crash *** ==5528==*** or produce wrong results. *** #0 0x7ff6e6111073 in __sanitizer_cov_trace_pc_guard__def c:\b\s\w\ir\cache\builder\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_coverage_libcdep_new.cc:177 #1 0x7ff6d294636c in base::internal::flat_tree<mojo::core::WatcherDispatcher *,std::pair<mojo::core::WatcherDispatcher *,mojo::core::WatcherSet::Entry>,base::internal::GetKeyFromValuePairFirst<mojo::core::WatcherDispatcher *,mojo::core::WatcherSet::Entry>,std::less<void> >::emplace_key_args<mojo::core::WatcherDispatcher *,std::pair<mojo::core::WatcherDispatcher *,mojo::core::WatcherSet::Entry> > C:\b\s\w\ir\cache\builder\src\base\containers\flat_tree.h:960 #2 0x7ff6d294413e in mojo::core::WatcherSet::Add C:\b\s\w\ir\cache\builder\src\mojo\core\watcher_set.cc:36 #3 0x7ff6d28eeecf in mojo::core::MessagePipeDispatcher::AddWatcherRef C:\b\s\w\ir\cache\builder\src\mojo\core\message_pipe_dispatcher.cc:257 #4 0x7ff6d2939806 in mojo::core::WatcherDispatcher::WatchDispatcher C:\b\s\w\ir\cache\builder\src\mojo\core\watcher_dispatcher.cc:143 #5 0x7ff6d28be35e in mojo::core::Core::AddTrigger C:\b\s\w\ir\cache\builder\src\mojo\core\core.cc:348 #6 0x7ff6d28de043 in `anonymous namespace'::MojoAddTriggerImpl C:\b\s\w\ir\cache\builder\src\mojo\core\entrypoints.cc:229 #7 0x7ff6d8a044a9 in mojo::SimpleWatcher::Context::Create C:\b\s\w\ir\cache\builder\src\mojo\public\cpp\system\simple_watcher.cc:42 #8 0x7ff6d8a03f5c in mojo::SimpleWatcher::Watch C:\b\s\w\ir\cache\builder\src\mojo\public\cpp\system\simple_watcher.cc:175 #9 0x7ff6db01506b in mojo::HandleSignalTracker::HandleSignalTracker C:\b\s\w\ir\cache\builder\src\mojo\public\cpp\system\handle_signal_tracker.cc:22 #10 0x7ff6d80f39b1 in base::Optional<mojo::HandleSignalTracker>::emplace<const mojo::MessagePipeHandle &,const unsigned int &,scoped_refptr<base::SequencedTaskRunner> &> C:\b\s\w\ir\cache\builder\src\base\optional.h:683 #11 0x7ff6d80ef615 in mojo::Connector::WaitToReadMore C:\b\s\w\ir\cache\builder\src\mojo\public\cpp\bindings\lib\connector.cc:404 #12 0x7ff6d80ee88c in mojo::Connector::Connector C:\b\s\w\ir\cache\builder\src\mojo\public\cpp\bindings\lib\connector.cc:163 #13 0x7ff6d8107ddd in mojo::internal::MultiplexRouter::MultiplexRouter C:\b\s\w\ir\cache\builder\src\mojo\public\cpp\bindings\lib\multiplex_router.cc:321 #14 0x7ff6d8107555 in mojo::internal::InterfacePtrStateBase::InitializeEndpointClient C:\b\s\w\ir\cache\builder\src\mojo\public\cpp\bindings\lib\interface_ptr_state.cc:84 #15 0x7ff6cef7b883 in mojo::internal::InterfacePtrState<network::mojom::CookieManager>::ConfigureProxyIfNecessary C:\b\s\w\ir\cache\builder\src\mojo\public\cpp\bindings\lib\interface_ptr_state.h:215 #16 0x7ff6d2f63a49 in content::CookieStoreManager::ListenToCookieChanges C:\b\s\w\ir\cache\builder\src\content\browser\cookie_store\cookie_store_manager.cc:91 #17 0x7ff6d2f5dfe9 in content::CookieStoreContext::ListenToCookieChangesOnIOThread C:\b\s\w\ir\cache\builder\src\content\browser\cookie_store\cookie_store_context.cc:105 #18 0x7ff6d2f5fec4 in base::internal::Invoker<base::internal::BindState<void (content::CookieStoreContext::*)(mojo::InterfacePtrInfo<network::mojom::CookieManager>, base::OnceCallback<void (bool)>),scoped_refptr<content::CookieStoreContext>,mojo::InterfacePtrInfo<network::mojom::CookieManager>,base::OnceCallback<void (bool)> >,void ()>::RunOnce C:\b\s\w\ir\cache\builder\src\base\bind_internal.h:658 #19 0x7ff6dea267fb in base::debug::TaskAnnotator::RunTask C:\b\s\w\ir\cache\builder\src\base\debug\task_annotator.cc:99 #20 0x7ff6db622197 in base::MessageLoopImpl::RunTask C:\b\s\w\ir\cache\builder\src\base\message_loop\message_loop_impl.cc:374 #21 0x7ff6db623a9a in base::MessageLoopImpl::DoWork C:\b\s\w\ir\cache\builder\src\base\message_loop\message_loop_impl.cc:473 #22 0x7ff6d879871c in base::MessagePumpForIO::DoRunLoop C:\b\s\w\ir\cache\builder\src\base\message_loop\message_pump_win.cc:512 #23 0x7ff6d87923e6 in base::MessagePumpWin::Run C:\b\s\w\ir\cache\builder\src\base\message_loop\message_pump_win.cc:52 #24 0x7ff6d88234e1 in base::RunLoop::Run C:\b\s\w\ir\cache\builder\src\base\run_loop.cc:102 #25 0x7ff6d2e1cf46 in content::BrowserProcessSubThread::IOThreadRun C:\b\s\w\ir\cache\builder\src\content\browser\browser_process_sub_thread.cc:174 #26 0x7ff6d88f4659 in base::Thread::ThreadMain C:\b\s\w\ir\cache\builder\src\base\threading\thread.cc:332 #27 0x7ff6d88ee7ec in base::`anonymous namespace'::ThreadFunc C:\b\s\w\ir\cache\builder\src\base\threading\platform_thread_win.cc:97 #28 0x7ff6e611ca5f in __asan::AsanThread::ThreadStart c:\b\s\w\ir\cache\builder\src\third_party\llvm\projects\compiler-rt\lib\asan\asan_thread.cc:262 #29 0x7ffedb3c2773 in BaseThreadInitThunk+0x13 (C:\Windows\System32\KERNEL32.DLL+0x180012773) #30 0x7ffedd610d50 in RtlUserThreadStart+0x20 (C:\Windows\SYSTEM32\ntdll.dll+0x180070d50) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: access-violation c:\b\s\w\ir\cache\builder\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_coverage_libcdep_new.cc:177 in __sanitizer_cov_trace_pc_guard__def Thread T7 created by T0 here: #0 0x7ff6e611bdc7 in __asan_wrap_CreateThread c:\b\s\w\ir\cache\builder\src\third_party\llvm\projects\compiler-rt\lib\asan\asan_win.cc:146 #1 0x7ff6d88eda7e in base::`anonymous namespace'::CreateThreadInternal C:\b\s\w\ir\cache\builder\src\base\threading\platform_thread_win.cc:136 #2 0x7ff6d88f34f3 in base::Thread::StartWithOptions C:\b\s\w\ir\cache\builder\src\base\threading\thread.cc:112 #3 0x7ff6d2e1c654 in content::BrowserProcessSubThread::CreateIOThread C:\b\s\w\ir\cache\builder\src\content\browser\browser_process_sub_thread.cc:90 #4 0x7ff6d295212b in content::ContentMainRunnerImpl::RunServiceManager C:\b\s\w\ir\cache\builder\src\content\app\content_main_runner_impl.cc:934 #5 0x7ff6d2951842 in content::ContentMainRunnerImpl::Run C:\b\s\w\ir\cache\builder\src\content\app\content_main_runner_impl.cc:868 #6 0x7ff6d9ba5a4a in service_manager::Main C:\b\s\w\ir\cache\builder\src\services\service_manager\embedder\main.cc:460 #7 0x7ff6d294f79b in content::ContentMain C:\b\s\w\ir\cache\builder\src\content\app\content_main.cc:19 #8 0x7ff6d7f8afe8 in content::BrowserTestBase::SetUp C:\b\s\w\ir\cache\builder\src\content\public\test\browser_test_base.cc:349 #9 0x7ff6d1df8e01 in testing::Test::Run C:\b\s\w\ir\cache\builder\src\third_party\googletest\src\googletest\src\gtest.cc:2517 #10 0x7ff6d1dfb105 in testing::TestInfo::Run C:\b\s\w\ir\cache\builder\src\third_party\googletest\src\googletest\src\gtest.cc:2703 #11 0x7ff6d1dfc526 in testing::TestCase::Run C:\b\s\w\ir\cache\builder\src\third_party\googletest\src\googletest\src\gtest.cc:2825 #12 0x7ff6d1e1a840 in testing::internal::UnitTestImpl::RunAllTests C:\b\s\w\ir\cache\builder\src\third_party\googletest\src\googletest\src\gtest.cc:5227 #13 0x7ff6d1e19a14 in testing::UnitTest::Run C:\b\s\w\ir\cache\builder\src\third_party\googletest\src\googletest\src\gtest.cc:4835 #14 0x7ff6d8052064 in base::TestSuite::Run C:\b\s\w\ir\cache\builder\src\base\test\test_suite.cc:294 #15 0x7ff6e60b8692 in content::ContentTestLauncherDelegate::RunTestSuite C:\b\s\w\ir\cache\builder\src\content\test\content_test_launcher.cc:111 #16 0x7ff6d7ffbf96 in content::LaunchTests C:\b\s\w\ir\cache\builder\src\content\public\test\test_launcher.cc:647 #17 0x7ff6e60b84d5 in main C:\b\s\w\ir\cache\builder\src\content\test\content_test_launcher.cc:141 #18 0x7ff6e616139f in __scrt_common_main_seh f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283 #19 0x7ffedb3c2773 in BaseThreadInitThunk+0x13 (C:\Windows\System32\KERNEL32.DLL+0x180012773) #20 0x7ffedd610d50 in RtlUserThreadStart+0x20 (C:\Windows\SYSTEM32\ntdll.dll+0x180070d50) ==5528==ABORTING
,
Dec 14
Issue 848278 is an example of a similar problem, I think.
,
Dec 14
I think we set this up because inferno asked for it. Isn't this needed for coverage-based fuzzing, which I think is what Clusterfuzz uses? (I'm not sure.)
,
Dec 14
We used to use sancov in past, but now it is deprecated and we have moved to using clang-source-code-based coverage. regular fuzzing builds don't rely on sancov, we can get rid of this.
,
Dec 14
rnk: Do you know any other reasons why we have this bot? Or should we just remove the CrWinAsanCov bot then?
,
Dec 14
Let's get rid of it then. I thought it was still used as part of the libfuzzer config, but now that we have a bot for that, we don't need this coverage one. Can we remove the gn flags that enable sanitizer coverage as well so that people don't try to use it?
,
Dec 14
Removing that flag from bots configs SGTM. > Can we remove the gn flags that enable sanitizer coverage as well so that people don't try to use it? Those flags are still used to distinguish when fuzzing engine is used with sanitizer coverage (which is used for feedback during fuzzing): https://cs.chromium.org/chromium/src/build/config/sanitizers/sanitizers.gni?q=use_sanitizer_coverage&sq=package:chromium&l=142&dr=C
,
Jan 3
Are "sancov" and "sanitizer coverage" different things? If not, don't comments 7 and 4 contradict each other? Do we still need the sancov executable in the clang bundle?
,
Jan 3
> Are "sancov" and "sanitizer coverage" different things? If not, don't comments 7 and 4 contradict each other? There is "sancov" binary which we have been using for generating coverage reports in the past. Now we use clang source-based code coverage, that's why c#4 states that we don't need "sancov" binary anymore. There is also "sanitizer coverage" (which is often called "sancov") that can be enabled by e.g. -fsanitize=fuzzer or -fsanitize=trace-pc-guard, this is still being used for fuzzers as that's how we get instant and relatively cheap feedback from a targeted code to the fuzzing engine. That's what I meant in c#7. > Do we still need the sancov executable in the clang bundle? We don't need for fuzzing efforts. Not sure if there are any other users.
,
Jan 14
|
||||
►
Sign in to add a comment |
||||
Comment 1 by mmoroz@chromium.org
, Dec 14