services_unittests fails under msan |
|||||
Issue descriptionI'm enabling more tests on chromium.memory in https://chromium-review.googlesource.com/c/chromium/src/+/987916/ Three tests in services_unittests fail on msan, e.g. https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_chromeos_msan_rel_ng/674 https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_msan_rel_ng/967 Failing tests: MusDemoTest.CheckMusDemoDraws GpuHostTest.GpuClientDestroyedWhileChannelRequestInFlight GpuHostTest.GpuClientDestructionOrder Seems to be due to a single stack from what I can tell: ATTENTION: default value of option force_s3tc_enable overridden by environment. Uninitialized bytes in __interceptor_strlen at offset 20 inside [0x71f000000e00, 3280) ==6223==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f2e39f1a4c8 in _init ??:0:0 #1 0x7f2e39f1f599 in glXMakeCurrent ??:? #2 0x7f2e39f1f599 in ?? ??:0 #3 0x7f2e39f1b7f0 in glXQueryVersion ??:0:0 #4 0xa4cd447 in gl::GLSurfaceGLX::InitializeOneOff() ./../../ui/gl/gl_surface_glx.cc:423:8 #5 0x58154bd in ui::GLOzoneGLX::InitializeGLOneOffPlatform() ./../../ui/ozone/platform/x11/gl_ozone_glx.cc:27:8 #6 0xabe0c0f in gl::init::InitializeGLOneOffPlatform() ./../../ui/gl/init/gl_initializer_ozone.cc:18:26 #7 0xabdc574 in gl::init::InitializeGLOneOffImplementation(gl::GLImplementation, bool, bool, bool, bool) ./../../ui/gl/init/gl_factory.cc:88:43 #8 0xabdbbee in gl::init::(anonymous namespace)::InitializeGLOneOffHelper(bool) ./../../ui/gl/init/gl_factory.cc:65:10 #9 0xabdc09b in gl::init::InitializeGLNoExtensionsOneOff() ./../../ui/gl/init/gl_factory.cc:79:10 #10 0xb51c4a6 in gpu::GpuInit::InitializeInProcess(base::CommandLine*, gpu::GpuPreferences const&) ./../../gpu/ipc/service/gpu_init.cc:344:8 #11 0x6cd9296 in viz::VizMainImpl::VizMainImpl(viz::VizMainImpl::Delegate*, viz::VizMainImpl::ExternalDependencies, std::__1::unique_ptr<gpu::GpuInit, std::__1::default_delete<gpu::GpuInit> >) ./../../components/viz/service/main/viz_main_impl.cc:129:16 #12 0x11dea629 in make_unique<viz::VizMainImpl, nullptr_t, viz::VizMainImpl::ExternalDependencies> ./../../buildtools/third_party/libc++/trunk/include/memory:3079:32 #13 0x11dea629 in ui::ws::DefaultGpuHost::InitializeVizMain(mojo::InterfaceRequest<viz::mojom::VizMain>) ./../../services/ui/ws/gpu_host.cc:151:0 #14 0x11df0b05 in Invoke<ui::ws::DefaultGpuHost *, mojo::InterfaceRequest<viz::mojom::VizMain> > ./../../base/bind_internal.h:447:12 #15 0x11df0b05 in MakeItSo<void (ui::ws::DefaultGpuHost::*)(mojo::InterfaceRequest<viz::mojom::VizMain>), ui::ws::DefaultGpuHost *, mojo::InterfaceRequest<viz::mojom::VizMain> > ./../../base/bind_internal.h:530:0 #16 0x11df0b05 in void base::internal::Invoker<base::internal::BindState<void (ui::ws::DefaultGpuHost::*)(mojo::InterfaceRequest<viz::mojom::VizMain>), base::internal::UnretainedWrapper<ui::ws::DefaultGpuHost>, base::internal::PassedWrapper<mojo::InterfaceRequest<viz::mojom::VizMain> > >, void ()>::RunImpl<void (ui::ws::DefaultGpuHost::*)(mojo::InterfaceRequest<viz::mojom::VizMain>), std::__1::tuple<base::internal::UnretainedWrapper<ui::ws::DefaultGpuHost>, base::internal::PassedWrapper<mojo::InterfaceRequest<viz::mojom::VizMain> > >, 0ul, 1ul>(void (ui::ws::DefaultGpuHost::*&&)(mojo::InterfaceRequest<viz::mojom::VizMain>), std::__1::tuple<base::internal::UnretainedWrapper<ui::ws::DefaultGpuHost>, base::internal::PassedWrapper<mojo::InterfaceRequest<viz::mojom::VizMain> > >&&, std::__1::integer_sequence<unsigned long, 0ul, 1ul>) ./../../base/bind_internal.h:604:0 #17 0x6d66c04 in Run ./../../base/callback.h:95:12 #18 0x6d66c04 in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./../../base/debug/task_annotator.cc:61:0 #19 0x6db8305 in base::MessageLoop::RunTask(base::PendingTask*) ./../../base/message_loop/message_loop.cc:391:25 #20 0x6db9d9e in DeferOrRunPendingTask ./../../base/message_loop/message_loop.cc:403:5 #21 0x6db9d9e in base::MessageLoop::DoWork() ./../../base/message_loop/message_loop.cc:447:0 #22 0x6dbeb12 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ./../../base/message_loop/message_pump_default.cc:37:31 #23 0x6e32e4f in base::RunLoop::Run() ./../../base/run_loop.cc:130:14 #24 0x6ed2f45 in base::Thread::ThreadMain() ./../../base/threading/thread.cc:338:3 #25 0x6ec9357 in base::(anonymous namespace)::ThreadFunc(void*) ./../../base/threading/platform_thread_posix.cc:76:13 #26 0x7f2e43f26183 in start_thread /build/eglibc-SvCtMH/eglibc-2.19/nptl/pthread_create.c:312:0 #27 0x7f2e3efdfffc in clone /build/eglibc-SvCtMH/eglibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111:0 Uninitialized value was created by a heap allocation #0 0x564e3d in __interceptor_malloc /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/msan/msan_interceptors.cc:915:3 #1 0x7f2e39f1fae3 in glXMakeCurrent ??:? #2 0x7f2e39f1fae3 in ?? ??:0 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1+0x194c8) Might either be easy to fix, or a false positive due to the gl driver not being instrumented, but I think we instrument all the libs. cc'ing the gpu owners from components/viz/OWNERS.
,
Apr 11 2018
Looks like it's hitting something inside the driver (mesa). I'm really not sure this is looking at a value provided by Chrome, the only argument to glXQueryVersion is the X Display, which comes from XOpenDisplay in libX11. A bug in mesa is possible, or some library (the mesa GL library - libGL.so.1 - or the underlying driver that mesa loads, e.g. swrast_dri.so) is indeed not instrumented. I'm not sure I make full sense of the stack (glXQueryVersion doesn't call glXMakeCurrent if I look at the mesa source), so I'm not sure I can direct further. glXQueryVersion is, I believe, the first call into libGL.so.1, so maybe that is what triggers its _init, and that's what we're seeing here. Generally though, we don't use the system mesa on bots. We either use osmesa that we compile from the source tree (which has a bunch of bugs, that we won't fix though because we don't use it in prod), or SwiftShader, or disable GPU altogether. Not sure about this bot's config.
,
Apr 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d3695968a8414ad39402dd8c275e53155d170023 commit d3695968a8414ad39402dd8c275e53155d170023 Author: Nico Weber <thakis@chromium.org> Date: Thu Apr 12 03:33:46 2018 Remove many chromium.memory exceptions. If we run tests on the main waterfall, we generally should run them on the memory waterfall as well. I filed bugs and added comments to those for the few tests that actually don't pass on the memory waterfall. Most do pass. Bug: 814403,831667,831674,831676,830653 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: I0ea3cf12745f089d7fb87da8fc20e2665d86d53f Reviewed-on: https://chromium-review.googlesource.com/987916 Commit-Queue: Nico Weber <thakis@chromium.org> Reviewed-by: Kenneth Russell <kbr@chromium.org> Cr-Commit-Position: refs/heads/master@{#550005} [modify] https://crrev.com/d3695968a8414ad39402dd8c275e53155d170023/testing/buildbot/chromium.memory.json [modify] https://crrev.com/d3695968a8414ad39402dd8c275e53155d170023/testing/buildbot/test_suite_exceptions.pyl [modify] https://crrev.com/d3695968a8414ad39402dd8c275e53155d170023/ui/gl/gl_context_glx_unittest.cc [modify] https://crrev.com/d3695968a8414ad39402dd8c275e53155d170023/ui/gl/gl_image_shared_memory_unittest.cc
,
May 21 2018
Re piman comment 2: Should these 3 tests move to gl_tests then? Or should we disable these 3 tests under msan and enable the rest of services_unittests? Or are things good the way they are?
,
May 21 2018
@#4: I don't think they belong to gl_tests, they're not there to test the GL command buffer stack at all, they test the GPU process creation (under mus) - that they exercise the GL initialization is just a side effect of starting the GPU process. I think at least the GpuHostTest tests would make sense even with the GPU disabled, so maybe we can disable there. MusDemoTest.CheckMusDemoDraws, I don't know. Maybe we can use swiftshader for it? ->sadrul who probably knows more about these tests.
,
Jun 21 2018
sadrul: ping?
,
Jun 21 2018
-> sky@ The associated code for these tests will be removed soon. So I think this would be a WontFix?
,
Jun 21 2018
GpuHostTest.GpuClientDestroyedWhileChannelRequestInFlight GpuHostTest.GpuClientDestructionOrder will live on. I don't have any idea about the failure though. I can't tell if it's ozone related, or mesa related. Sadrul, I'm kicking back to you as you likely know more than I do about this.
,
Aug 3
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
,
Jan 4
I'm hitting this same stack with my cl: https://chromium-review.googlesource.com/c/chromium/src/+/1393454 affected tests are: WidgetInputMethodInteractiveTest.TwoWindows NativeWidgetAuraTest.NonActiveWindowRequestImeFocus DragTestInteractive.DragTest WidgetCaptureTest.Capture Any advice on how to proceed?
,
Jan 5
Actually, it seems that many tests have this crash stack: https://chromium-swarm.appspot.com/task?id=4233d7dda9118f10&refresh=10&show_raw=1 |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by rsesek@chromium.org
, Apr 11 2018