Units tests run with -fsanitize=address have numerous issues.

[NAThompson]

First, an issue which has been fixed in VTK-m has been inherited:

5: Running main() from gtest_main.cc
5: [==========] Running 1 test from 1 test case.
5: [----------] Global test environment set-up.
5: [----------] 1 test from vtkh_clip
5: [ RUN      ] vtkh_clip.vtkh_box_clip
5: ~/vtk-m/vtkm/cont/ArrayHandle.hxx:214:58: runtime error: member call on address 0x6020000002f0 which does not point to an object of type 'ArrayHandleExecutionManagerBase'
5: 0x6020000002f0: note: object is of type 'vtkm::cont::internal::ArrayHandleExecutionManager<int, vtkm::cont::StorageTagImplicit<vtkm::cont::detail::ArrayPortalImplicit<vtkm::cont::detail::IndexFunctor> >, vtkm::cont::DeviceAdapterTagSerial>'
5:  05 00 80 70  b8 3d 2b ef 61 7f 00 00  80 20 00 00 30 60 00 00  00 00 00 00 00 00 00 00  00 00 00 00

Next, a runtime error for an invalid load:

5: ~/vtk-h/src/vtkh/rendering/Image.hpp:11:8: runtime error: load of value 253, which is not a valid value for type 'bool'

Memory leaks of 8kb in a unit test:

6: =================================================================
6: ==7949==ERROR: LeakSanitizer: detected memory leaks
6:
6: Direct leak of 8192 byte(s) in 32 object(s) allocated from:
6:     #0 0x7f33ce8d4f40 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdef40)
6:     #1 0x7f33b74addf2  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xa7df2)
6:
6: SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 32 allocation(s).
 6/23 Test  #6: t_vtk-h_clip_field ...............***Failed    2.59 sec
test 7
      Start  7: t_vtk-h_device_control

A direct leak from vtkh::Lagrangian::DoExecute:

13: [       OK ] vtkh_lagrangian.vtkh_serial_lagrangian (2708 ms)
13: [----------] 1 test from vtkh_lagrangian (2708 ms total)
13:
13: [----------] Global test environment tear-down
13: [==========] 1 test from 1 test case ran. (2708 ms total)
13: [  PASSED  ] 1 test.
13:
13: =================================================================
13: ==7993==ERROR: LeakSanitizer: detected memory leaks
13:   
13: Direct leak of 560 byte(s) in 10 object(s) allocated from:
13:     #0 0x7f1715eef458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
13:     #1 0x7f170738c495 in vtkh::Lagrangian::DoExecute() /home/4nt/vtk-h/src/vtkh/filters/Lagrangian.cpp:77
13:     #2 0x7f1706df4e13 in vtkh::Filter::Update() /home/4nt/vtk-h/src/vtkh/filters/Filter.cpp:33
13:     #3 0x55ea10821e76 in vtkh_lagrangian_vtkh_serial_lagrangian_Test::TestBody() /home/4nt/vtk-h/src/tests/vtkh/t_vtk-h_lagrangian.cpp:1$
13:     #4 0x7f1715781ed0 in void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testi$
13:     #5 0x7f1715781ed0 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing:$
13:     #6 0x7f171570ed9d in testing::Test::Run() /home/4nt/vtk-h/src/blt/thirdparty_builtin/googletest-master-2018-02-01/googletest/src/gte$
13:     #7 0x7f171570f5ff in testing::TestInfo::Run() /home/4nt/vtk-h/src/blt/thirdparty_builtin/googletest-master-2018-02-01/googletest/src$
13:     #8 0x7f171571041d in testing::TestCase::Run() /home/4nt/vtk-h/src/blt/thirdparty_builtin/googletest-master-2018-02-01/googletest/src$
13:     #9 0x7f17157136ba in testing::internal::UnitTestImpl::RunAllTests() /home/4nt/vtk-h/src/blt/thirdparty_builtin/googletest-master-201$
13:     #10 0x7f1715783f70 in bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing:$
13:     #11 0x7f1715783f70 in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::in$

and numerous other leaks, as is shown in the ctest log

Steps to reproduce: Add the following lines to src/CMakeLists.txt:

if(CMAKE_BUILD_TYPE MATCHES "Debug")
  if(CMAKE_CXX_COMPILER_ID MATCHES "^(AppleClang|Clang|GNU)")
    set(CMAKE_CXX_FLAGS_DEBUG "-Wall -g -O2 -Wfatal-errors -fsanitize=address -fsanitize=undefined -fno-omit-frame-pointer")
  endif()
endif()

[mclarsen]

@NAThompson Do you have a sense of what percentage of these come from VTK-m versus VTK-h?

[NAThompson]

Yes: The head VTK-m is completely clean; in fact it was completely clean at VTK-m release 1.4. The only problem from VTK-m with this (since VTK-h is pinned to a particular VTK-m commit) is the member call on address error. The rest are from VTK-h.

[mclarsen]

Ok. I am going to move up the VTK-m commit in the very near future, and I will try to figure out where they are coming for. Thanks!

[NAThompson]

@mclarsen : Huge thanks for taking this seriously! We're preparing to put this code through some big runs in the coming weeks, so hopefully this will preempt most of the classical "bugs at scale".

[mclarsen]

Updating to the latest vtkm still yields a bunch of:

/Users/larsen30/research/test_builds/latest/vtk-m/install/include/vtkm-1.4/vtkm/cont/ArrayHandleVirtual.h:147:30: runtime error: member call on address 0x607000000268 which does not point to an object of type 'vtkm::cont::internal::detail::StorageVirtual'
0x607000000268: note: object is of type 'vtkm::cont::internal::detail::StorageVirtualImpl<vtkm::Vec<double, 3>, vtkm::cont::StorageTagImplicit<vtkm::internal::ArrayPortalUniformPointCoordinates> >'
 00 00 00 00  20 2e 22 08 01 00 00 00  00 00 00 00 00 00 00 00  d8 02 00 00 70 60 00 00  c0 02 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~

[mclarsen]

Same story with clip with field:

/Users/larsen30/research/test_builds/latest/vtk-m/install/include/vtkm-1.4/vtkm/cont/ArrayHandleVirtual.h:147:30: runtime error: member call on address 0x6070000005e8 which does not point to an object of type 'vtkm::cont::internal::detail::StorageVirtual'
0x6070000005e8: note: object is of type 'vtkm::cont::internal::detail::StorageVirtualImpl<double, vtkm::cont::StorageTagBasic>'
 00 00 00 00  c0 fd ea 00 01 00 00 00  00 00 00 00 00 00 00 00  58 06 00 00 70 60 00 00  40 06 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'vtkm::cont::internal::detail::StorageVirtualImpl<double, vtkm::cont::StorageTagBasic>'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/larsen30/research/test_builds/latest/vtk-m/install/include/vtkm-1.4/vtkm/cont/ArrayHandleVirtual.h:147:30 in 

but the memory leak does not appear for me. Could be updating to the latest vtkm.

[mclarsen]

Seems like calling anything in vtkm (all vtkh unit test, even no_op) is generating this and I am not getting any helpful information about how to locate where this is happening. I am not seeing the memory leaks in the Lagrange either. Perhaps we have vtkms configured differently.

[mclarsen]

Hmm, after closer inspection these "errors" could be due to vtkm trying to cast a virtual to all possible types to find the right one.

[NAThompson]

@mclarsen : What is the commit hash of your VTK-m?

[mclarsen]

1a73641f9d9f061aef4cb0a8e979a0ac1a4247e3

[mclarsen]

How do I get a full stack trace to figure out where this stuff is coming from?

[NAThompson]

@mclarsen : The AddressSanitizer delivers a full stack trace. The UBSan doesn't.

It looks to me like what you're seeing from VTK-m has just popped up. Since it looks like you've already built VTK-m with sanitizers enabled, could you run ctest -V in your build_vtk-m directory and submit a bug report to them? (If it's not trivial I'll get on it tomorrow.)

[mclarsen]

I didn't build vtkm with sanitizers enabled. It probably looks like it because we are compiling the vtkm code, since there isn't a library for filters. One of VTKh's main purposes is to compile vtkm code and protect downstream consumers.

[robertmaynard]

In general I have seen issue like this when symbol visibility is mismatching. The comparison uses the typeid(T).hash() functionality and LLVM uses a hash function which includes the visibility.

[mclarsen]

@robertmaynard Noted. Adding the proper exports has been on my list of things to do for a while. I will see if I can get it done in the next day or so.

[mclarsen]

I changed the default visibility of symbols to hidden.