GYP vs GN: ubsan_vptr behaves differently |
|||
Issue descriptionIt turns out that GN and GYP produce different behavior in ubsan_vptr mode. To reproduce: 1. Build cc_unittests with GYP: git checkout 0614eafcb01516c1ea51a7cbb7790af1243f8f3f # This corresponds to https://build.chromium.org/p/chromium.fyi/builders/ClangToTLinuxUBSanVptr%20tester/builds/419 (green with GYP) export GYP_DEFINES='ubsan_vptr' gclient sync ninja -C out/Release cc_unittests out/Release/cc_unittests The tests are expected to pass. 2. Build cc_unittests with GN: gn gen //out/gn '--args=is_ubsan_vptr=true is_debug=false' --check ninja -C out/gn cc_unittests out/gn/cc_unittests We get a lot of errors like: [ RUN ] LayerTreeHostReadbackPixelTests/LayerTreeHostReadbackPixelTest.ReadbackNonRootLayer/1 Received signal 11 SEGV_MAPERR 000000000018 #0 0x000002757e36 base::debug::(anonymous namespace)::StackDumpSignalHandler() #1 0x7f5775dff340 <unknown> #2 0x7f577606a153 __dynamic_cast #3 0x00000058597d __ubsan::checkDynamicType() #4 0x000000584a62 HandleDynamicTypeCacheMiss() #5 0x000000584a32 __ubsan_handle_dynamic_type_cache_miss #6 0x7f5771763c3d <unknown> #7 0x7f5771699032 <unknown> #8 0x7f577164096e <unknown> #9 0x000002629a0b gpu::gles2::Shader::DoCompile() #10 0x0000026112a0 gpu::gles2::Program::CompileAttachedShaders() #11 0x0000026107d0 gpu::gles2::Program::Link() #12 0x0000025a51a6 gpu::gles2::GLES2DecoderImpl::DoLinkProgram() #13 0x000002539d78 gpu::gles2::GLES2DecoderImpl::HandleLinkProgram() #14 0x00000258b07a gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<>() #15 0x0000024f194f gpu::CommandParser::ProcessCommands() #16 0x0000024f3f9b gpu::CommandExecutor::PutChanged() #17 0x0000025f546d _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0EEEENS0_9BindStateINS0_15RunnableAdapterIMN3gpu22InProcessCommandBufferEFvvEEEFvPS7_EJRNS_7WeakPtrIS7_EEEEENS0_12InvokeHelperILb1EvSA_EEFvvEE3R unEPNS0_13BindStateBaseE #18 0x0000025ef73d gpu::InProcessCommandBuffer::FlushOnGpuThread() #19 0x0000025f5818 _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0ELm1ELm2EEEENS0_9BindStateINS0_15RunnableAdapterIMN3gpu22InProcessCommandBufferEFvijEEEFvPS7_ijEJRNS_7WeakPtrIS7_EERiRKjEEENS0_12InvokeHelperIL b1EvSA_EEFvvEE3RunEPNS0_13BindStateBaseE #20 0x0000027d4173 base::debug::TaskAnnotator::RunTask() #21 0x000002768c5c base::MessageLoop::RunTask() #22 0x000002769559 base::MessageLoop::DeferOrRunPendingTask() #23 0x000002769bc4 base::MessageLoop::DoWork() #24 0x00000276c7d3 base::MessagePumpDefault::Run() #25 0x00000278b7f9 base::RunLoop::Run() #26 0x000002767cfd base::MessageLoop::Run() #27 0x0000027a0554 base::Thread::ThreadMain() #28 0x00000279af1b base::(anonymous namespace)::ThreadFunc() #29 0x7f5775df7182 start_thread #30 0x7f577590e47d clone r8: 0000000000000018 r9: 00000000ffffffff r10: 00007f5775bd0fe0 r11: 00007f577599bc70 r12: 00007f57762f3c30 r13: 00002f0f1d0a92c8 r14: 00007f5771970490 r15: 4c73b92bf7c58447 di: 0000000000000018 si: 00007f57762f4b40 bp: 00007f5770472f50 bx: 0000000000000018 dx: 00007f57762f3c30 ax: 000000000429e9a0 cx: 0000000000000000 sp: 00007f57704727d0 ip: 00007f577606a153 efl: 0000000000010202 cgf: 0000000000000033 erf: 0000000000000004 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000018 [end of stack trace]
,
Apr 22 2016
Most likely it's mesa: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/mesa/mesa.gyp&q=fsanitize=vptr&sq=package:chromium&type=cs&l=84 ['ubsan_vptr == 1', { 'cflags!': [ # UBsan's vptr is not compatible with -fno-rtti, # which is used by gallium/auxiliary/Makefile. '-fsanitize=null', '-fsanitize=vptr', '-fsanitize-coverage=<(sanitizer_coverage)', ], }],
,
Apr 22 2016
Fix posted: https://codereview.chromium.org/1917603002/
,
Apr 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6017f972ef987939b1777dc54b37a9c9aecc1b92 commit 6017f972ef987939b1777dc54b37a9c9aecc1b92 Author: krasin <krasin@google.com> Date: Wed Apr 27 23:51:36 2016 third_party/mesa: turn off ubsan_vptr, since it's compiled without rtti. This is a port of a corresponding functionality in GYP: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/mesa/mesa.gyp&q=fsanitize=vptr&sq=package:chromium&type=cs&l=84 BUG= 606003 Review-Url: https://codereview.chromium.org/1917603002 Cr-Commit-Position: refs/heads/master@{#390240} [modify] https://crrev.com/6017f972ef987939b1777dc54b37a9c9aecc1b92/build/config/sanitizers/BUILD.gn [modify] https://crrev.com/6017f972ef987939b1777dc54b37a9c9aecc1b92/third_party/mesa/BUILD.gn
,
Apr 29 2016
There's still a small difference remaining. At the moment of writing, ToT bot based on GYP is green: https://build.chromium.org/p/chromium.fyi/builders/ClangToTLinuxUBSanVptr%20tester/builds/439 GN based bot is red: https://build.chromium.org/p/chromium.fyi/builders/UBSanVptr%20Linux/builds/54 Failed test suites: browser_tests components_unittests content_unittests ipc_tests net_unittests webkit_unit_tests Will take a look at this today.
,
Apr 29 2016
,
Apr 29 2016
I've started to look into ipc_tests failures. Stack trace: krasin@krasin2:~/chr21/src$ gdb --args ./out/gn/ipc_tests --gtest_filter=UnixDomainSocketUtil.Connect ... (gdb) b HandleDynamicTypeCacheMiss Breakpoint 1 at 0x43d260 (gdb) r Starting program: /usr/local/google/home/krasin/chr21/src/out/gn/ipc_tests --gtest_filter=UnixDomainSocketUtil.Connect [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/grte/v4/lib64/libthread_db.so.1". Breakpoint 1, 0x000000000043d260 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) () (gdb) bt #0 0x000000000043d260 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) () #1 0x000000000043d252 in __ubsan_handle_dynamic_type_cache_miss () #2 0x000000000051a470 in DefaultSysAllocator::DefaultSysAllocator() () at ../../third_party/tcmalloc/chromium/src/system-alloc.cc:312 #3 0x000000000051a70c in InitSystemAllocators () at ../../third_party/tcmalloc/chromium/src/system-alloc.cc:594 #4 TCMalloc_SystemAlloc () at ../../third_party/tcmalloc/chromium/src/system-alloc.cc:620 #5 0x000000000050b85e in tcmalloc::MetaDataAlloc(unsigned long) () at ../../third_party/tcmalloc/chromium/src/common.cc:205 #6 0x0000000000518217 in New () at ../../third_party/tcmalloc/chromium/src/page_heap_allocator.h:72 #7 0x0000000000518e9c in Init () at ../../third_party/tcmalloc/chromium/src/page_heap_allocator.h:60 #8 InitStaticVars () at ../../third_party/tcmalloc/chromium/src/static_vars.cc:54 #9 0x000000000051b7e8 in InitModule () at ../../third_party/tcmalloc/chromium/src/thread_cache.cc:324 #10 0x000000000051c5be in GetCache () at ../../third_party/tcmalloc/chromium/src/thread_cache.h:412 #11 do_malloc () at ../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1105 #12 0x00000000006cdb05 in do_malloc_or_cpp_alloc () at ../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1045 #13 tc_malloc () at ../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1579 #14 0x0000000000504dbe in ShimMalloc () at ../../base/allocator/allocator_shim.cc:164 #15 0x00007ffff70f96fb in g_rw_lock_impl_new () at /build/buildd/glib2.0-2.40.2/./glib/gthread-posix.c:431 #16 0x00007ffff70f9765 in g_rw_lock_get_impl (lock=0x7ffff77c9f50 <type_rw_lock>) at /build/buildd/glib2.0-2.40.2/./glib/gthread-posix.c:455 #17 0x00007ffff70f9ae9 in g_rw_lock_writer_lock (rw_lock=<optimized out>) at /build/buildd/glib2.0-2.40.2/./glib/gthread-posix.c:534 #18 0x00007ffff7584452 in gobject_init_ctor () at /build/buildd/glib2.0-2.40.2/./gobject/gtype.c:4321 #19 0x00007ffff7dea13a in call_init (l=<optimized out>, argc=argc@entry=2, argv=argv@entry=0x7fffffffd648, env=env@entry=0x7fffffffd660) at dl-init.c:78 #20 0x00007ffff7dea223 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:36 #21 _dl_init (main_map=0x7ffff7ffe1c8, argc=2, argv=0x7fffffffd648, env=0x7fffffffd660) at dl-init.c:126 #22 0x00007ffff7ddb30a in _dl_start_user () at rtld.c:875
,
Apr 29 2016
Actually, no. That was a red herring. The real stack trace that causes the issue is: 0x00007ffff5ff0153 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) bt #0 0x00007ffff5ff0153 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x000000000043e196 in __ubsan::checkDynamicType(void*, void*, unsigned long) () at ../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1017 #2 0x000000000043d282 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) () at ../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1017 #3 0x000000000043d252 in __ubsan_handle_dynamic_type_cache_miss () at ../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1017 #4 0x00000000004c184e in Run<base::MessagePumpLibevent::FileDescriptorWatcher* const&> () at ../../base/bind_internal.h:181 #5 MakeItSo<(anonymous namespace)::SocketAcceptor*, base::MessagePumpLibevent::FileDescriptorWatcher* const&> () at ../../base/bind_internal.h:321 #6 Run () at ../../base/bind_internal.h:372 #7 0x000000000060aa53 in Run () at ../../base/callback.h:397 #8 RunTask () at ../../base/debug/task_annotator.cc:51 #9 0x00000000005a4a6c in RunTask () at ../../base/message_loop/message_loop.cc:484 #10 0x00000000005a5369 in DeferOrRunPendingTask () at ../../base/message_loop/message_loop.cc:493 #11 0x00000000005a5da4 in DoWork () at ../../base/message_loop/message_loop.cc:610 #12 0x00000000005ac886 in Run () at ../../base/message_loop/message_pump_libevent.cc:230 #13 0x00000000005c8749 in base::RunLoop::Run() () at ../../base/run_loop.cc:35 #14 0x00000000005a37ad in base::MessageLoop::Run() () at ../../base/message_loop/message_loop.cc:300 #15 0x00000000005e1b64 in ThreadMain () at ../../base/threading/thread.cc:254 #16 0x00000000005dc43b in ThreadFunc () at ../../base/threading/platform_thread_posix.cc:70 #17 0x00007ffff5a77182 in start_thread (arg=0x7ffff36b3700) at pthread_create.c:312 #18 0x00007ffff558e47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
,
Apr 29 2016
Reproduced ipc_tests failure with gyp as well. Turns out that the existing UBSan Vptr ToT buildbot runs fewer test suites: https://build.chromium.org/p/chromium.fyi/builders/ClangToTLinuxUBSanVptr%20tester/builds/439 (ipc_tests are not there)
,
Apr 29 2016
Actually, none of the currently failing tests run on that bot: browser_tests components_unittests content_unittests ipc_tests net_unittests webkit_unit_tests :(
,
Apr 29 2016
I will disable this tests on 'UBSanVptr Linux', as we never had them green on the ToT bot. I filed https://crbug.com/607996 to track this.
,
Apr 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4e1a01ea5781f1ddce3c38c2d96ba1ba18b95d1a commit 4e1a01ea5781f1ddce3c38c2d96ba1ba18b95d1a Author: krasin <krasin@google.com> Date: Sat Apr 30 02:51:07 2016 gn: add is_ubsan_no_recover to halt the program on the first problem. BUG= 606003 Review-Url: https://codereview.chromium.org/1942563002 Cr-Commit-Position: refs/heads/master@{#390841} [modify] https://crrev.com/4e1a01ea5781f1ddce3c38c2d96ba1ba18b95d1a/build/config/sanitizers/BUILD.gn [modify] https://crrev.com/4e1a01ea5781f1ddce3c38c2d96ba1ba18b95d1a/build/config/sanitizers/sanitizers.gni [modify] https://crrev.com/4e1a01ea5781f1ddce3c38c2d96ba1ba18b95d1a/tools/mb/mb_config.pyl
,
Jun 13 2016
is this done?
,
Jun 13 2016
I think so. |
|||
►
Sign in to add a comment |
|||
Comment 1 by krasin@chromium.org
, Apr 22 2016