New issue
Advanced search Search tips

Issue 831676 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome
Pri: 3
Type: Bug



Sign in to add a comment

services_unittests fails under msan

Project Member Reported by thakis@chromium.org, Apr 11 2018

Issue description

I'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.
 

Comment 1 by rsesek@chromium.org, Apr 11 2018

Labels: -OS-Mac OS-Chrome OS-Linux

Comment 2 by piman@chromium.org, 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.
Project Member

Comment 3 by bugdroid1@chromium.org, 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

Comment 4 by thakis@chromium.org, 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?

Comment 5 by piman@chromium.org, May 21 2018

Owner: sadrul@chromium.org
@#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.

Comment 6 by thakis@chromium.org, Jun 21 2018

sadrul: ping?

Comment 7 by sadrul@chromium.org, Jun 21 2018

Owner: sky@chromium.org
-> sky@

The associated code for these tests will be removed soon. So I think this would be a WontFix?

Comment 8 by sky@chromium.org, Jun 21 2018

Owner: sadrul@chromium.org
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.
Status: Assigned (was: Untriaged)
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
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?
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