VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2021-06-01T15:35:05-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/17878[VTK 9.0] Fails with hdf5-config.cmake2021-06-01T15:35:05-04:00Alexander Neumann[VTK 9.0] Fails with hdf5-config.cmakeFirst error of many:
```
CMake Error at /mnt/d/qt2/scripts/buildsystems/vcpkg.cmake:250 (_add_library):
Target "exodusII" links to target "hdf5::hdf5-static" but the target was
not found. Perhaps a find_package() call is missing for...First error of many:
```
CMake Error at /mnt/d/qt2/scripts/buildsystems/vcpkg.cmake:250 (_add_library):
Target "exodusII" links to target "hdf5::hdf5-static" but the target was
not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Call Stack (most recent call first):
CMake/vtkModule.cmake:3328 (add_library)
ThirdParty/exodusII/vtkexodusII/CMakeLists.txt:300 (vtk_module_add_module)
```
Output of configure:
```
-- Found HDF5 at /mnt/d/qt2/installed/x64-linux/share/hdf5 via NO_MODULE. Now trying to extract locations etc.
-- Trying to get properties of target hdf5::hdf5-static
-- Found imported configurations: DEBUG;RELEASE
-- Start search through imported configurations in the following order: Debug;RELWITHDEBINFO;RELEASE;DEBUG;DEBUG
-- Selected imported configuration: RELEASE
-- Found HDF5: hdf5::hdf5-static (found version "1.10.5") found components: C HL
-- HDF5_DIR: /mnt/d/qt2/installed/x64-linux/share/hdf5
-- HDF5_DEFINITIONS:
-- HDF5_INCLUDE_DIRS: /mnt/d/qt2/installed/x64-linux/include
-- HDF5_LIBRARIES: hdf5::hdf5-static
-- HDF5_HL_LIBRARIES: hdf5::hdf5_hl-static
-- HDF5_C_DEFINITIONS:
-- HDF5_C_INCLUDE_DIR:
-- HDF5_C_INCLUDE_DIRS: /mnt/d/qt2/installed/x64-linux/include
-- HDF5_C_LIBRARY: /mnt/d/qt2/installed/x64-linux/lib/libhdf5.a
-- HDF5_C_LIBRARIES: hdf5::hdf5-static
-- HDF5_C_HL_LIBRARY: /mnt/d/qt2/installed/x64-linux/lib/libhdf5_hl.a
-- HDF5_C_HL_LIBRARIES: hdf5::hdf5_hl-static
```
Probably needs to add `set_target_properties(hdf5::hdf5-(shared|static) PROPERTIES IMPORTED_GLOBAL TRUE)` and `set_target_properties(hdf5::hdf5_hl-(shared|static) PROPERTIES IMPORTED_GLOBAL TRUE)`https://gitlab.kitware.com/vtk/vtk/-/issues/17875[VTK 9.0] Ninja build error with external vtk-m2020-05-04T08:41:31-04:00Alexander Neumann[VTK 9.0] Ninja build error with external vtk-mError:
`ninja: error: build.ninja:96011: unknown pool name 'vtkm_pool'`
Probable reason:
```
vtk_module_set_property(VTK::AcceleratorsVTKm
PROPERTY JOB_POOL_COMPILE
VALUE vtkm_pool)
```
Can I simply patch that out?Error:
`ninja: error: build.ninja:96011: unknown pool name 'vtkm_pool'`
Probable reason:
```
vtk_module_set_property(VTK::AcceleratorsVTKm
PROPERTY JOB_POOL_COMPILE
VALUE vtkm_pool)
```
Can I simply patch that out?https://gitlab.kitware.com/vtk/vtk/-/issues/17898[VTK 9.0] Unable to pass Python3_LIBRARY_<CONFIG> or Python3_LIBRARIES via CMake2020-05-29T10:18:57-04:00Alexander Neumann[VTK 9.0] Unable to pass Python3_LIBRARY_<CONFIG> or Python3_LIBRARIES via CMakethe find module seems to simply ignore these. Would be nice if it did not do that or not use `_Python3_LIBRARY_RELEASE` as a hint for `_Python3_LIBRARY_DEBUG` and do a search with `NO_DEFAULT_PATH` on windows.the find module seems to simply ignore these. Would be nice if it did not do that or not use `_Python3_LIBRARY_RELEASE` as a hint for `_Python3_LIBRARY_DEBUG` and do a search with `NO_DEFAULT_PATH` on windows.https://gitlab.kitware.com/vtk/vtk/-/issues/17890[VTK 9.0] warning STL4015: The std::iterator class template (used as a base c...2020-09-04T05:37:57-04:00kireevtf[VTK 9.0] warning STL4015: The std::iterator class template (used as a base class to provide typedefs) is deprecated in C++17Compiling an example (say [https://lorensen.github.io/VTKExamples/site/Cxx/Interaction/Picking/]()) with Visual Studio 2019 and C++17 outputs the warning:
> vtk-9.0\vtkDataArrayTupleRange_Generic.h(385,27): error C4996: 'std::iterator<s...Compiling an example (say [https://lorensen.github.io/VTKExamples/site/Cxx/Interaction/Picking/]()) with Visual Studio 2019 and C++17 outputs the warning:
> vtk-9.0\vtkDataArrayTupleRange_Generic.h(385,27): error C4996: 'std::iterator<std::random_access_iterator_tag,detail::GetAPITypeImpl<ArrayType>::APIType,vtk::ComponentIdType,void,vtk::detail::ConstComponentReference<ArrayType,TupleSize>>': warning STL4015: The std::iterator class template (used as a base class to provide typedefs) is deprecated in C++17. (The <iterator> header is NOT deprecated.) The C++ Standard has never required user-defined iterators to derive from std::iterator. To fix this warning, stop deriving from std::iterator and start providing publicly accessible typedefs named iterator_category, value_type, difference_type, pointer, and reference. Note that value_type is required to be non-const, even for constant iterators. You can define _SILENCE_CXX17_ITERATOR_BASE_CLASS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning.https://gitlab.kitware.com/vtk/vtk/-/issues/19134[VTK 9.2.2] QQuickVTKRenderItem captureScreenshot() always returns the first ...2023-10-25T11:28:54-04:00Antonio Capobianco[VTK 9.2.2] QQuickVTKRenderItem captureScreenshot() always returns the first captured screenshotCalling captureScreenshot() of QQuickVTKRenderItem class will always return the same vtkImageData generated on the first call.
Used environment:
- Qt 6.5.2
- VTK 9.2.2
- MSVC2019 64bit
- Compiler: Microsoft Visual C++ Compiler 16.11.32...Calling captureScreenshot() of QQuickVTKRenderItem class will always return the same vtkImageData generated on the first call.
Used environment:
- Qt 6.5.2
- VTK 9.2.2
- MSVC2019 64bit
- Compiler: Microsoft Visual C++ Compiler 16.11.32510.428 (amd64)
- CMake 3.21.1
- Example to reproduce the issue: [conesrc.zip](/uploads/37f09cf4db5645ad785ece0b4ae1fae0/conesrc.zip)https://gitlab.kitware.com/vtk/vtk/-/issues/17790[vtk8.90] vtkCutter not show scalar information2020-03-16T12:55:48-04:00Yue JIN[vtk8.90] vtkCutter not show scalar informationI use vtkCutter to show a section of an unstructuredgrid. My code works well in vtk 8.2. But in vtk 8.9, the actor of vtkCutter becomes white like shown in the picture attached. All these actors are rendered in QVTKOpenGLNativeWidget.
![...I use vtkCutter to show a section of an unstructuredgrid. My code works well in vtk 8.2. But in vtk 8.9, the actor of vtkCutter becomes white like shown in the picture attached. All these actors are rendered in QVTKOpenGLNativeWidget.
![vktcutter](/uploads/1da2432001d58a9c3dffdf6487c6b8f0/vktcutter.png)https://gitlab.kitware.com/vtk/vtk/-/issues/19279[Windows] Python-VTK remove library hash suffix2024-03-22T09:11:45-04:00Noah[Windows] Python-VTK remove library hash suffixCurrently, the pre-built libraries that VTK ships on windows in its python package (in `vtk.libs`) are suffixed with hashes:
![image](/uploads/54a921d97d644c4b59cf3538a667f948/image.png)
Would it be possible to remove said suffixes and...Currently, the pre-built libraries that VTK ships on windows in its python package (in `vtk.libs`) are suffixed with hashes:
![image](/uploads/54a921d97d644c4b59cf3538a667f948/image.png)
Would it be possible to remove said suffixes and simply keep the names as `vtksys-9.3.dll`?
The reason I'm asking is because we are currently developing a native python module that dynamically links against vtk and in an effort to reduce duplicate libraries we've made our module load the python-vtk libraries at runtime.
This works on Linux as the `.so` files are named as expected. But due to the aforementioned suffixes this approach does not work on windows.https://gitlab.kitware.com/vtk/vtk/-/issues/18644`assert` usage in tests for actual feature testing2022-09-07T05:41:12-04:00Timothee Chabat`assert` usage in tests for actual feature testingThere are tests that relies on `assert` to test some feature, however CI is build in `Release` mode so this causes some features that should be tested to not be tested at all.
Here's a list of tests that are relying on assert :
- [ ] A...There are tests that relies on `assert` to test some feature, however CI is build in `Release` mode so this causes some features that should be tested to not be tested at all.
Here's a list of tests that are relying on assert :
- [ ] Accelerators/Vtkm/Filters/Testing/Cxx/TestVTKMCoordinateSystemTransform.cxx
- [ ] Accelerators/Vtkm/Filters/Testing/Cxx/TestVTKMHistogram.cxx
- [ ] Accelerators/Vtkm/Filters/Testing/Cxx/TestVTKMNDHistogram.cxx
- [ ] Common/DataModel/Testing/Cxx/TestDataObject.cxx
- [ ] Common/DataModel/Testing/Cxx/TestMemkindData.cxx
- [ ] Filters/Hybrid/Testing/Cxx/TestTemporalCacheMemkind.cxx
- [ ] Filters/Sources/Testing/Cxx/TestCapsuleSource.cxx
- [ ] Testing/GenericBridge/vtkBridgeDataSet.cxxhttps://gitlab.kitware.com/vtk/vtk/-/issues/18747`FiltersSelectionCxx-TestLinearSelector3D` fails reliably on at least several...2023-03-10T14:04:19-05:00Sean McBride`FiltersSelectionCxx-TestLinearSelector3D` fails reliably on at least several MacsOn my macOS 12.6.3 Mac, and my colleague @SeunOdutola's also, the `FiltersSelectionCxx-TestLinearSelector3D` test fails reliably in current master with:
```
(lldb) r
Process 73912 launched: '/Users/sean/external/VTK-big-bin/bin/vtkFilte...On my macOS 12.6.3 Mac, and my colleague @SeunOdutola's also, the `FiltersSelectionCxx-TestLinearSelector3D` test fails reliably in current master with:
```
(lldb) r
Process 73912 launched: '/Users/sean/external/VTK-big-bin/bin/vtkFiltersSelectionCxxTests' (x86_64)
Selection (0,0,0)-(0.23,0.04,0.04) contains 54 cells.
Original cell Ids (types): 65 209 353 497 641 785 929 1073 1217 1361 1505 1649 1793 1937 2081 2225 2369 2513 2657 2801 2945 3089 3233 3377 3521 3665 3809 3953 4097 4241 4385 4529 4673 4817 4961 5105 5249 5393 5537 5681 5825 5969 6113 6257 6401 6545 6689 6833 6977 7121 7265 7409 7553 7697
Wrote file ./LinearExtraction3D-0.vtk
Selection (0,0,0)-(0.23,0,0) contains 76 cells.
( 0.214s) [main thread ]TestLinearSelector3D.cx:76 WARN| Incorrect cardinality: 76 != 54
Original cell Ids (types): 0 144 288 432 576 720 864 1008 1152 1296 1440 1584 1728 1872 2016 2160 2304 2448 2592 2736 2880 3024 3168 3312 3456 3600 3744 3888 4032 4176 4320 4464 4608 4752 4896 5040 5184 5328 5472 5616 5760 5904 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057 6058 6059 6060 6072 6084 6096 6108 6120 6132 6144 6156 6168 6180 6192 6336 6480 6624 6768 6912 7056 7200 7344 7488 7632
Wrote file ./LinearExtraction3D-1.vtk
Selection (0.23,0,0)-(0,0,0)-(0.23,0.04,0.04) contains 130 cells.
( 0.348s) [main thread ]TestLinearSelector3D.cx:76 WARN| Incorrect cardinality: 130 != 108
Original cell Ids (types): 0 65 144 209 288 353 432 497 576 641 720 785 864 929 1008 1073 1152 1217 1296 1361 1440 1505 1584 1649 1728 1793 1872 1937 2016 2081 2160 2225 2304 2369 2448 2513 2592 2657 2736 2801 2880 2945 3024 3089 3168 3233 3312 3377 3456 3521 3600 3665 3744 3809 3888 3953 4032 4097 4176 4241 4320 4385 4464 4529 4608 4673 4752 4817 4896 4961 5040 5105 5184 5249 5328 5393 5472 5537 5616 5681 5760 5825 5904 5969 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057 6058 6059 6060 6072 6084 6096 6108 6113 6120 6132 6144 6156 6168 6180 6192 6257 6336 6401 6480 6545 6624 6689 6768 6833 6912 6977 7056 7121 7200 7265 7344 7409 7488 7553 7632 7697
Wrote file ./LinearExtraction3D-2.vtk
Selection (0.23,0,0)-(0.1,0,0)-(0.23,0.01,0.0033) contains 45 cells.
Original cell Ids (types): 0 144 288 432 576 720 864 1008 1152 1296 1440 1584 1728 1872 2016 2160 2304 2448 2592 2736 2880 3024 3168 3312 3456 3600 3744 3888 5616 5760 5904 6624 6768 6912 6913 7056 7057 7200 7201 7344 7345 7488 7489 7632 7633
Wrote file ./LinearExtraction3D-3.vtk
Process 73912 exited with status = 2 (0x00000002)
```
On ***my*** Mac at least, it's the only test that always fails.https://gitlab.kitware.com/vtk/vtk/-/issues/17685`GetEdgePoints` and `GetFacePoints` not implemented in vtkPolyhedron2019-11-13T10:02:59-05:00Yohann Bearzi (Kitware)`GetEdgePoints` and `GetFacePoints` not implemented in vtkPolyhedron`vtkCell3D::GetEdgePoints` and `vtkCell3D::GetFacePoints` are pure virtual methods which are not implemented in `vtkPolyhedron`. I added a warning macro for when they are called in https://gitlab.kitware.com/vtk/vtk/merge_requests/5996 s...`vtkCell3D::GetEdgePoints` and `vtkCell3D::GetFacePoints` are pure virtual methods which are not implemented in `vtkPolyhedron`. I added a warning macro for when they are called in https://gitlab.kitware.com/vtk/vtk/merge_requests/5996 so someone using them is aware that he should not use them, but it should be implemented at some point.https://gitlab.kitware.com/vtk/vtk/-/issues/17353`Illegal hardware instruction` on MacOs 10.13.5 with Xdmf3Readers2021-05-15T15:17:11-04:00Ruben Di Battista`Illegal hardware instruction` on MacOs 10.13.5 with Xdmf3ReadersI'm trying to provide a variant to the VTK Portfile on [macports](https://github.com/macports/macports-ports) that can be used to enable HDF5 readers (and Xdmf).
The problem I'm encountering is that, even if VTK compiles correctly, when...I'm trying to provide a variant to the VTK Portfile on [macports](https://github.com/macports/macports-ports) that can be used to enable HDF5 readers (and Xdmf).
The problem I'm encountering is that, even if VTK compiles correctly, when I run a snippet of code that uses the `vtkXdmf3Reader`, the execution "crashes" with:
`llegal hardware instruction`
if the Xdmf links to HDF5 data file.
You find all the build logs and additional details on [Macports PR](https://github.com/macports/macports-ports/pull/2123).
As a MWE, you can use:
```
#include "vtkNew.h"
#include "vtkXdmf3Reader.h"
int main(int argc, char** argv) {
vtkNew<vtkXdmf3Reader> reader;
reader->SetFileName("scalar.xmf");
reader->DebugOn();
reader->Update();
}
```
Reading an actual `xmf` file that uses HDF5 to store data as [this one](https://github.com/macports/macports-ports/files/2160224/scalar-data.tar.gz).
I cannot understand if it's a bug in VTK or Apple Clang. I also tried to use GCC7, but it seems that the standard library on new MacOS is a bit clobbered and I encounter other errors during the compilation.
This is the backtrace of the execution. The problem seems associated to destruction of the `XdmfRectilinearGrid` object.
Hope you can give me help :)
```
(lldb) target create "rayleigh"
Current executable set to 'rayleigh' (x86_64).
(lldb) run
Process 87150 launched: '/Users/.../git/x/HG/examples/c++/rayleigh/build/rayleigh' (x86_64)
Debug: In /opt/local/var/macports/build/_Users_..._git_macports-ports_graphics_vtk/vtk/work/VTK-7.1.1/Common/Core/vtkObject.cxx, line 861
vtkXdmf3Reader (0x10551b3e0): Registered by vtkCompositeDataPipeline (0x10551c650), ReferenceCount = 2
Process 87150 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0000000100ce683b libvtkxdmf3.dylib`XdmfRectilinearGrid::~XdmfRectilinearGrid() + 47
libvtkxdmf3.dylib`XdmfRectilinearGrid::~XdmfRectilinearGrid:
-> 0x100ce683b <+47>: ud2
0x100ce683d <+49>: nop
0x100ce683e <+0>: pushq %rbp
0x100ce683f <+1>: movq %rsp, %rbp
Target 0: (rayleigh) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
* frame #0: 0x0000000100ce683b libvtkxdmf3.dylib`XdmfRectilinearGrid::~XdmfRectilinearGrid() + 47
frame #1: 0x00007ffeefbfef20
frame #2: 0x0000000100ce6854 libvtkxdmf3.dylib`XdmfRectilinearGrid::~XdmfRectilinearGrid() + 22
frame #3: 0x0000000100ce68ab libvtkxdmf3.dylib`XdmfRectilinearGrid::~XdmfRectilinearGrid() + 15
frame #4: 0x00000001018161cd libXdmfCore.dylib`boost::detail::shared_count::~shared_count() + 45
frame #5: 0x00000001017e4d96 libXdmfCore.dylib`std::__1::__tree<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, std::__1::__map_value_compare<_xmlNode*, std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, std::__1::less<_xmlNode*>, true>, std::__1::allocator<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> > > >::destroy(std::__1::__tree_node<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, void*>*) + 50
frame #6: 0x00000001017e4d8d libXdmfCore.dylib`std::__1::__tree<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, std::__1::__map_value_compare<_xmlNode*, std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, std::__1::less<_xmlNode*>, true>, std::__1::allocator<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> > > >::destroy(std::__1::__tree_node<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, void*>*) + 41
frame #7: 0x00000001017e4d81 libXdmfCore.dylib`std::__1::__tree<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, std::__1::__map_value_compare<_xmlNode*, std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, std::__1::less<_xmlNode*>, true>, std::__1::allocator<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> > > >::destroy(std::__1::__tree_node<std::__1::__value_type<_xmlNode*, boost::shared_ptr<XdmfItem> >, void*>*) + 29
frame #8: 0x00000001017e44c7 libXdmfCore.dylib`XdmfCoreReader::XdmfCoreReaderImpl::closeFile() + 31
frame #9: 0x00000001017e459b libXdmfCore.dylib`XdmfCoreReader::readItems(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const + 65
frame #10: 0x00000001017e48c7 libXdmfCore.dylib`XdmfCoreReader::read(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const + 27
frame #11: 0x0000000100ce5912 libvtkxdmf3.dylib`XdmfReader::read(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const + 14
frame #12: 0x0000000100c3ea32 libvtkIOXdmf3-7.1.1.dylib`vtkXdmf3Reader::Internals::Init(char const*, bool) + 2224
frame #13: 0x0000000100c37ffe libvtkIOXdmf3-7.1.1.dylib`vtkXdmf3Reader::Internals::PrepareDocument(vtkXdmf3Reader*, char const*, bool) + 96
frame #14: 0x0000000100c37ecf libvtkIOXdmf3-7.1.1.dylib`vtkXdmf3Reader::RequestDataObject(vtkInformationVector*) + 57
frame #15: 0x000000010495400f libvtkCommonExecutionModel-7.1.1.dylib`vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 69
frame #16: 0x00000001049499fe libvtkCommonExecutionModel-7.1.1.dylib`vtkCompositeDataPipeline::ExecuteDataObject(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 304
frame #17: 0x000000010494e44e libvtkCommonExecutionModel-7.1.1.dylib`vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 166
frame #18: 0x000000010496b01d libvtkCommonExecutionModel-7.1.1.dylib`vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 543
frame #19: 0x000000010494e968 libvtkCommonExecutionModel-7.1.1.dylib`vtkDemandDrivenPipeline::UpdateInformation() + 48
frame #20: 0x000000010496b438 libvtkCommonExecutionModel-7.1.1.dylib`vtkStreamingDemandDrivenPipeline::Update(int, vtkInformationVector*) + 36
frame #21: 0x0000000100020d1f rayleigh`main(argc=1, argv=0x00007ffeefbff4e8) at rayleigh.cpp:10
frame #22: 0x00007fff64ec9015 libdyld.dylib`start + 1
frame #23: 0x00007fff64ec9015 libdyld.dylib`start + 1
(lldb) exit
```https://gitlab.kitware.com/vtk/vtk/-/issues/17661`ThirdParty/Eigen` incompatible with CUDA 10.12019-08-13T10:33:31-04:00Allison Vacantialliepiper16@gmail.com`ThirdParty/Eigen` incompatible with CUDA 10.1Our Eigen snapshot is causing compile errors when CUDA 10.1 is present, since it directly pulls in some deprecated headers:
https://open.cdash.org/viewBuildError.php?type=1&buildid=6053937
```
Warning while building CUDA object file " R...Our Eigen snapshot is causing compile errors when CUDA 10.1 is present, since it directly pulls in some deprecated headers:
https://open.cdash.org/viewBuildError.php?type=1&buildid=6053937
```
Warning while building CUDA object file " Remote/MomentInvariants/ParallelMomentInvariants/CMakeFiles/ParallelMomentInvariants.dir/vtkPComputeMoments.cxx.o" in target ParallelMomentInvariants
Warning
Source File Remote/MomentInvariants/ParallelMomentInvariants/vtkPComputeMoments.cxx
Command
[+] "/home/kitware/misc/root/cuda-10.1/bin/nvcc"
Directory /home/kitware/buildslave/root/vtk_master-adora-linux-shared-release_cuda_gcc_mpi_optix_python2_tbb_vtkm/build
Standard Error
[CTest: warning suppressed] In file included from /home/kitware/buildslave/root/vtk_master-adora-linux-shared-release_cuda_gcc_mpi_optix_python2_tbb_vtkm/source/ThirdParty/eigen/vtkeigen/eigen/Core:259:0,
[CTest: warning suppressed] from /home/kitware/buildslave/root/vtk_master-adora-linux-shared-release_cuda_gcc_mpi_optix_python2_tbb_vtkm/source/ThirdParty/eigen/vtkeigen/eigen/Dense:1,
[CTest: warning suppressed] from /home/kitware/buildslave/root/vtk_master-adora-linux-shared-release_cuda_gcc_mpi_optix_python2_tbb_vtkm/source/Remote/MomentInvariants/MomentInvariants/vtkMomentsTensor.h:81,
[CTest: warning suppressed] from /home/kitware/buildslave/root/vtk_master-adora-linux-shared-release_cuda_gcc_mpi_optix_python2_tbb_vtkm/source/Remote/MomentInvariants/ParallelMomentInvariants/vtkPComputeMoments.cxx:79:
[CTest: warning matched] /home/kitware/misc/root/cuda-10.1/bin/../targets/x86_64-linux/include/host_defines.h:54:2: warning: #warning "host_defines.h is an internal header file and must not be used directly. This file will be removed in a future CUDA release. Please use cuda_runtime_api.h or cuda_runtime.h instead." [-Wcpp]
#warning "host_defines.h is an internal header file and must not be used directly. This file will be removed in a future CUDA release. Please use cuda_runtime_api.h or cuda_runtime.h instead."
^~~~~~~
```
It looks like this has been fixed in recent versions of Eigen.https://gitlab.kitware.com/vtk/vtk/-/issues/18837`vtkBitArray` is not thread-safe2023-05-11T07:32:33-04:00Julien Fausty`vtkBitArray` is not thread-safeThe `vtkBitArray` class stores bit values in an internal `unsigned char` array where each byte holds 8 bit values. When setting values in this array, bitshift and bitwise operators are used to flip certain bit values of the corresponding...The `vtkBitArray` class stores bit values in an internal `unsigned char` array where each byte holds 8 bit values. When setting values in this array, bitshift and bitwise operators are used to flip certain bit values of the corresponding bytes of the underlying `unsigned char` array.
As such, when processing in a multi-threaded context, multiple threads may look to modify bit values in close proximity to each other leading to a simultaneous modification of the same `unsigned char`. This leads to undefined behavior since the same memory address is modified by two concurrent threads.
This problem is mostly relevant in the `vtkHyperTreeGrid` framework where the internal masking mechanism is controlled through a `vtkBitArray`.https://gitlab.kitware.com/vtk/vtk/-/issues/17906`vtkHyperTree` global index refactoring2021-11-11T14:19:52-05:00Yohann Bearzi (Kitware)`vtkHyperTree` global index refactoringThere are 2 ways to index data in a `vtkHyperTree`.
* Explicit indexing: activated by calling `SetGlobalIndexFromLocal`
* Implicit indexing: activated by calling `SetGlobalIndexStart`
If one calls one of those 2 methods, then the getter...There are 2 ways to index data in a `vtkHyperTree`.
* Explicit indexing: activated by calling `SetGlobalIndexFromLocal`
* Implicit indexing: activated by calling `SetGlobalIndexStart`
If one calls one of those 2 methods, then the getter of the other indexing method crashes because of an `assert`. The design is flawed: you should be able to instantiate one version or another, and not be able to change its behavior at run-time. The solution to this is to do that by inheritance, having for example a `vtkExplicitHyperTree` and a `vtkImplicitHyperTree` implementations inheriting from abstract class `vtkHyperTree`.Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/17904`vtkHyperTreeGrid` ghost types2020-05-22T09:49:40-04:00Yohann Bearzi (Kitware)`vtkHyperTreeGrid` ghost typesCurrently, `vtkHyperTreeGridGhostCellsGenerator` generates binary ghosts: cells (or more precisely vertices) are ghosts, or they are not. However, righting algorithms implicating ghosts might need some extra topological information on su...Currently, `vtkHyperTreeGridGhostCellsGenerator` generates binary ghosts: cells (or more precisely vertices) are ghosts, or they are not. However, righting algorithms implicating ghosts might need some extra topological information on such vertices to avoid unnecessary search / communication.
This issue aims to define what types of ghosts are relevant for an htg. I will propose a set of ghost types, which we can then amend. Note that in the current ghost implementation, an entire hypertree is held by one and only one process, but in the future, it could make sense to split a hypertree among multiple processes.
Before I list a proposal for those types, I think we should call them `TreeVertexGhostType` and not `VertexGhostType`, since if at some point someone wants to do ghosts on graphs that are not trees, it would be more legitimate to keep the pure vertex naming for this case.
Here is what could be defined in `vtkDataSetAttributes.h`:
```
enum TreeVertexGhostType
{
DUPLICATETREEVERTEX = 1, // the vertex is present on multiple processors.
PUREGHOSTTREEVERTEX = 2, // the vertex sub-tree is only composed of ghost vertices.
PUREGHOSTROOTTREEVERTEX = 4, // the vertex is the first pure ghost vertex in the current path to the root of the hypertree.
INCOMPLETETREEVERTEX = 8, // the vertex is refined into a subtree in another process, but is locally a leaf.
HIDDENTREEVERTEX = 16 // the vertex is needed for hypertree topology, but does not hold any data information.
};
```
Adding a `REFINEDTREEVERTEX` would not be relevant in most cases since this information can be accessed through cursors using `IsLeaf()` method. But maybe we want to be able to know about it by only looking at the ghost array without actually traversing the htg. This is to be discussed.
Solving this issue implies changing `vtkHyperTreeGridGhostCellsGenerator` to acknowledge these types.9.1Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/18387`vtkImageReader2` overflows o 2 GB files on Windows2022-01-03T12:11:07-05:00Yohann Bearzi (Kitware)`vtkImageReader2` overflows o 2 GB files on WindowsThis issue stems from this discourse [post](https://discourse.vtk.org/t/reading-raw-data-using-memcpy/7215).
`vtkImageReader2` and its subclasses index positions in the input file using `long` and `unsigned long`, which are only guaran...This issue stems from this discourse [post](https://discourse.vtk.org/t/reading-raw-data-using-memcpy/7215).
`vtkImageReader2` and its subclasses index positions in the input file using `long` and `unsigned long`, which are only guaranteed to be 4 bytes by C++ standard. On windows, they are defined on 4 bytes, which causes this class to not be able to open files larger than 2 GB.
All indexing in these class need to be replaced by `vtkTypeUInt64`.
@ben.boeckel FYIYohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/19187`vtkPolyDataNormals` hangs with problematic data and `SplittingOn` or `Consis...2023-12-01T14:24:59-05:00Aron Helser`vtkPolyDataNormals` hangs with problematic data and `SplittingOn` or `ConsistencyOn`The attached dataset causes an infinite loop and therefore a program hang in `vtkPolyDataNormals` with the default options `Splitting` or `Consistency` enabled. Disabling both these options removes the hang.
It seems to be stuck in a l...The attached dataset causes an infinite loop and therefore a program hang in `vtkPolyDataNormals` with the default options `Splitting` or `Consistency` enabled. Disabling both these options removes the hang.
It seems to be stuck in a loop inside `vtkPolyData::GetCellEdgeNeighbors()` .
In ParaView this can be replicated in the `Generate Surface Normals` filter.
[normals_bug_polydata.vtp](/uploads/7544c9c2cc8c14b6c17e520a3b4e2bd0/normals_bug_polydata.vtp)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/18830`vtkpython -h` raises exception when VTK is compiled with `VTK_PYTHON_FULL_TH...2023-07-03T05:16:05-04:00Christos Tsolakis`vtkpython -h` raises exception when VTK is compiled with `VTK_PYTHON_FULL_THREADSAFE`Compiling a recent vtk (6801d0274d2adac9a8fc23bfc6a9848145eeae6e) with python enabled and `VTK_PYTHON_FULL_THREADSAFE=ON` causes `vtkpython` to fail when an argument is passed like for example `vtkpython -h` or `--version`.
Below the ...Compiling a recent vtk (6801d0274d2adac9a8fc23bfc6a9848145eeae6e) with python enabled and `VTK_PYTHON_FULL_THREADSAFE=ON` causes `vtkpython` to fail when an argument is passed like for example `vtkpython -h` or `--version`.
Below the result of `vtkpython --help`
Python 3.10.10
```
...
PYTHONDEVMODE: enable the development mode.
PYTHONPYCACHEPREFIX: root directory for bytecode cache (pyc) files.
PYTHONWARNDEFAULTENCODING: enable opt-in EncodingWarning for 'encoding=None'.
Fatal Python error: PyEval_SaveThread: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL)
Python runtime state: preinitialized
Loguru caught a signal: SIGABRT
Stack trace:
11 0x5569a4b3d45e ./bin/vtkpython(+0x145e) [0x5569a4b3d45e]
10 0x7fcefd561083 __libc_start_main + 243
9 0x5569a4b3d2df ./bin/vtkpython(+0x12df) [0x5569a4b3d2df]
8 0x7fcefd536807 vtkPythonInterpreter::PyMain(int, char**) + 695
7 0x7fcefd53600e vtkPythonInterpreter::InitializeWithArgs(int, int, char**) + 1150
6 0x7fcefcbe76f6 /lib/x86_64-linux-gnu/libpython3.10.so.1.0(+0x1e16f6) [0x7fcefcbe76f6]
5 0x7fcefcbe7ce6 /lib/x86_64-linux-gnu/libpython3.10.so.1.0(+0x1e1ce6) [0x7fcefcbe7ce6]
4 0x7fcefcba3969 /lib/x86_64-linux-gnu/libpython3.10.so.1.0(+0x19d969) [0x7fcefcba3969]
3 0x7fcefca76caf /lib/x86_64-linux-gnu/libpython3.10.so.1.0(+0x70caf) [0x7fcefca76caf]
2 0x7fcefd55f859 abort + 299
1 0x7fcefd58000b gsignal + 203
0 0x7fcefd580090 /lib/x86_64-linux-gnu/libc.so.6(+0x43090) [0x7fcefd580090]
( 0.001s) [main thread ] :0 FATL| Signal: SIGABRT
Aborted (core dumped)
```
python 3.9.16 exhibits the same issue.
The signal comes from:
```
Program received signal SIGABRT, Aborted.
0x00007ffff7dfa00b in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff7dfa00b in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff7dd9859 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff72f0caf in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#3 0x00007ffff741d969 in _Py_FatalErrorFunc () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#4 0x00007ffff7461ce6 in _Py_FatalError_TstateNULL () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#5 0x00007ffff74616f6 in PyEval_SaveThread () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#6 0x00007ffff7db000e in vtkPythonInterpreter::InitializeWithArgs (initsigs=1, argc=2, argv=0x555555580000) at ../vtk/Utilities/PythonInterpreter/vtkPythonInterpreter.cxx:344
#7 0x00007ffff7db0807 in vtkPythonInterpreter::PyMain (argc=<optimized out>, argv=<optimized out>) at ../vtk/Utilities/PythonInterpreter/vtkPythonInterpreter.cxx:595
#8 0x00005555555552df in main (argc=2, argv=0x7fffffffdba8) at ../vtk/Wrapping/Python/vtkPythonAppInit.cxx:119
```
which points to https://gitlab.kitware.com/vtk/vtk/-/blob/master/Utilities/PythonInterpreter/vtkPythonInterpreter.cxx#L344
for python 3.8.10 the issue is similar but the signal comes from `PyEval_InitThreads()` a few lines above.
https://gitlab.kitware.com/vtk/vtk/-/blob/master/Utilities/PythonInterpreter/vtkPythonInterpreter.cxx#L339https://gitlab.kitware.com/vtk/vtk/-/issues/18842`vtkStaticCellLocator::BuildLocatorInternal` data race found by TSan2023-04-20T04:15:26-04:00Sean McBride`vtkStaticCellLocator::BuildLocatorInternal` data race found by TSanI have a repro case in my own app, which I could reduce to something small if necessary, but maybe it will be obvious from the TSan output:
```
==================
WARNING: ThreadSanitizer: data race (pid=84848)
Write of size 4 at 0x7b...I have a repro case in my own app, which I could reduce to something small if necessary, but maybe it will be obvious from the TSan output:
```
==================
WARNING: ThreadSanitizer: data race (pid=84848)
Write of size 4 at 0x7b94002996f4 by thread T72:
#0 int* std::__1::__fill_n<int*, int, long>(int*, int, long const&) fill_n.h:31 (Brainsight:x86_64+0x1068e666d)
#1 int* std::__1::fill_n<int*, int, long>(int*, int, long const&) fill_n.h:40 (Brainsight:x86_64+0x1068e649e)
#2 (anonymous namespace)::MapOffsets<int>::operator()(long long, long long) vtkStaticCellLocator.cxx:488 (Brainsight:x86_64+0x1068e634e)
#3 vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>::Execute(long long, long long) vtkSMPTools.h:97 (Brainsight:x86_64+0x1068e5c03)
#4 void vtk::detail::smp::ExecuteFunctorSTDThread<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false> >(void*, long long, long long, long long) vtkSMPToolsImpl.txx:47 (Brainsight:x86_64+0x1068e5e51)
#5 decltype(static_cast<void (*&>(fp)(static_cast<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*&>(fp0), static_cast<long long&>(fp0), static_cast<long long&>(fp0), static_cast<long long&>(fp0))) std::__1::__invoke<void (*&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*&, long long&, long long&, long long&>(void (*&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*&, long long&, long long&, long long&) type_traits:3918 (Brainsight:x86_64+0x1068eb7bb)
#6 std::__1::__bind_return<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, std::__1::tuple<>, __is_valid_bind_return<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, std::__1::tuple<> >::value>::type std::__1::__apply_functor<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, 0ul, 1ul, 2ul, 3ul, std::__1::tuple<> >(void (*&)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>&, std::__1::__tuple_indices<0ul, 1ul, 2ul, 3ul>, std::__1::tuple<>&&) bind.h:257 (Brainsight:x86_64+0x1068eb672)
#7 std::__1::__bind_return<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, std::__1::tuple<>, __is_valid_bind_return<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, std::__1::tuple<> >::value>::type std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>::operator()<>() bind.h:292 (Brainsight:x86_64+0x1068eb56e)
#8 decltype(static_cast<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&>(fp)()) std::__1::__invoke<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&>(std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&) type_traits:3918 (Brainsight:x86_64+0x1068eb483)
#9 void std::__1::__invoke_void_return_wrapper<void, true>::__call<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&>(std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&) invoke.h:61 (Brainsight:x86_64+0x1068eb39b)
#10 std::__1::__function::__alloc_func<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>, std::__1::allocator<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&> >, void ()>::operator()() function.h:178 (Brainsight:x86_64+0x1068eb31b)
#11 std::__1::__function::__func<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>, std::__1::allocator<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&> >, void ()>::operator()() function.h:352 (Brainsight:x86_64+0x1068e8617)
#12 std::__1::__function::__value_func<void ()>::operator()() const function.h:505 (Brainsight:x86_64+0x1027a0ae1)
#13 std::__1::function<void ()>::operator()() const function.h:1182 (Brainsight:x86_64+0x102797583)
#14 vtk::detail::smp::vtkSMPThreadPool::ThreadJob() vtkSMPThreadPool.cxx:80 (Brainsight:x86_64+0x10475c54c)
#15 decltype(*(static_cast<vtk::detail::smp::vtkSMPThreadPool*&>(fp0)).*fp()) std::__1::__invoke<void (vtk::detail::smp::vtkSMPThreadPool::*&)(), vtk::detail::smp::vtkSMPThreadPool*&, void>(void (vtk::detail::smp::vtkSMPThreadPool::*&)(), vtk::detail::smp::vtkSMPThreadPool*&) type_traits:3859 (Brainsight:x86_64+0x104764682)
#16 std::__1::__bind_return<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, std::__1::tuple<>, __is_valid_bind_return<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, std::__1::tuple<> >::value>::type std::__1::__apply_functor<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, 0ul, std::__1::tuple<> >(void (vtk::detail::smp::vtkSMPThreadPool::*&)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>&, std::__1::__tuple_indices<0ul>, std::__1::tuple<>&&) bind.h:257 (Brainsight:x86_64+0x10476456b)
#17 std::__1::__bind_return<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, std::__1::tuple<>, __is_valid_bind_return<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, std::__1::tuple<> >::value>::type std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>::operator()<>() bind.h:292 (Brainsight:x86_64+0x1047644be)
#18 decltype(static_cast<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>>(fp)()) std::__1::__invoke<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) type_traits:3918 (Brainsight:x86_64+0x104764363)
#19 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >&, std::__1::__tuple_indices<>) thread:287 (Brainsight:x86_64+0x1047641f3)
#20 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> > >(void*) thread:298 (Brainsight:x86_64+0x104762d59)
Previous write of size 4 at 0x7b94002996f4 by thread T52:
#0 int* std::__1::__fill_n<int*, int, long>(int*, int, long const&) fill_n.h:31 (Brainsight:x86_64+0x1068e666d)
#1 int* std::__1::fill_n<int*, int, long>(int*, int, long const&) fill_n.h:40 (Brainsight:x86_64+0x1068e649e)
#2 (anonymous namespace)::MapOffsets<int>::operator()(long long, long long) vtkStaticCellLocator.cxx:488 (Brainsight:x86_64+0x1068e634e)
#3 vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>::Execute(long long, long long) vtkSMPTools.h:97 (Brainsight:x86_64+0x1068e5c03)
#4 void vtk::detail::smp::ExecuteFunctorSTDThread<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false> >(void*, long long, long long, long long) vtkSMPToolsImpl.txx:47 (Brainsight:x86_64+0x1068e5e51)
#5 decltype(static_cast<void (*&>(fp)(static_cast<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*&>(fp0), static_cast<long long&>(fp0), static_cast<long long&>(fp0), static_cast<long long&>(fp0))) std::__1::__invoke<void (*&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*&, long long&, long long&, long long&>(void (*&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*&, long long&, long long&, long long&) type_traits:3918 (Brainsight:x86_64+0x1068eb7bb)
#6 std::__1::__bind_return<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, std::__1::tuple<>, __is_valid_bind_return<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, std::__1::tuple<> >::value>::type std::__1::__apply_functor<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, 0ul, 1ul, 2ul, 3ul, std::__1::tuple<> >(void (*&)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>&, std::__1::__tuple_indices<0ul, 1ul, 2ul, 3ul>, std::__1::tuple<>&&) bind.h:257 (Brainsight:x86_64+0x1068eb672)
#7 std::__1::__bind_return<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, std::__1::tuple<>, __is_valid_bind_return<void (*)(void*, long long, long long, long long), std::__1::tuple<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long, long long, long long>, std::__1::tuple<> >::value>::type std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>::operator()<>() bind.h:292 (Brainsight:x86_64+0x1068eb56e)
#8 decltype(static_cast<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&>(fp)()) std::__1::__invoke<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&>(std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&) type_traits:3918 (Brainsight:x86_64+0x1068eb483)
#9 void std::__1::__invoke_void_return_wrapper<void, true>::__call<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&>(std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>&) invoke.h:61 (Brainsight:x86_64+0x1068eb39b)
#10 std::__1::__function::__alloc_func<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>, std::__1::allocator<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&> >, void ()>::operator()() function.h:178 (Brainsight:x86_64+0x1068eb31b)
#11 std::__1::__function::__func<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&>, std::__1::allocator<std::__1::__bind<void (&)(void*, long long, long long, long long), vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>*, long long&, long long&, long long&> >, void ()>::operator()() function.h:352 (Brainsight:x86_64+0x1068e8617)
#12 std::__1::__function::__value_func<void ()>::operator()() const function.h:505 (Brainsight:x86_64+0x1027a0ae1)
#13 std::__1::function<void ()>::operator()() const function.h:1182 (Brainsight:x86_64+0x102797583)
#14 vtk::detail::smp::vtkSMPThreadPool::ThreadJob() vtkSMPThreadPool.cxx:80 (Brainsight:x86_64+0x10475c54c)
#15 decltype(*(static_cast<vtk::detail::smp::vtkSMPThreadPool*&>(fp0)).*fp()) std::__1::__invoke<void (vtk::detail::smp::vtkSMPThreadPool::*&)(), vtk::detail::smp::vtkSMPThreadPool*&, void>(void (vtk::detail::smp::vtkSMPThreadPool::*&)(), vtk::detail::smp::vtkSMPThreadPool*&) type_traits:3859 (Brainsight:x86_64+0x104764682)
#16 std::__1::__bind_return<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, std::__1::tuple<>, __is_valid_bind_return<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, std::__1::tuple<> >::value>::type std::__1::__apply_functor<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, 0ul, std::__1::tuple<> >(void (vtk::detail::smp::vtkSMPThreadPool::*&)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>&, std::__1::__tuple_indices<0ul>, std::__1::tuple<>&&) bind.h:257 (Brainsight:x86_64+0x10476456b)
#17 std::__1::__bind_return<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, std::__1::tuple<>, __is_valid_bind_return<void (vtk::detail::smp::vtkSMPThreadPool::*)(), std::__1::tuple<vtk::detail::smp::vtkSMPThreadPool*>, std::__1::tuple<> >::value>::type std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>::operator()<>() bind.h:292 (Brainsight:x86_64+0x1047644be)
#18 decltype(static_cast<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>>(fp)()) std::__1::__invoke<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) type_traits:3918 (Brainsight:x86_64+0x104764363)
#19 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >&, std::__1::__tuple_indices<>) thread:287 (Brainsight:x86_64+0x1047641f3)
#20 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> > >(void*) thread:298 (Brainsight:x86_64+0x104762d59)
Location is heap block of size 8404 at 0x7b9400299000 allocated by main thread:
#0 operator new(unsigned long) <null>:2 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x82fbd)
#1 void* std::__1::__libcpp_operator_new<unsigned long>(unsigned long) new:235 (Brainsight:x86_64+0x10adb1fed)
#2 std::__1::__libcpp_allocate(unsigned long, unsigned long) new:261 (Brainsight:x86_64+0x10adb1d2a)
#3 std::__1::allocator<int>::allocate(unsigned long) allocator.h:108 (Brainsight:x86_64+0x10adb4b2c)
#4 std::__1::allocator_traits<std::__1::allocator<int> >::allocate(std::__1::allocator<int>&, unsigned long) allocator_traits.h:262 (Brainsight:x86_64+0x10adb467d)
#5 std::__1::vector<int, std::__1::allocator<int> >::__vallocate(unsigned long) vector:1015 (Brainsight:x86_64+0x10adb9f4d)
#6 std::__1::vector<int, std::__1::allocator<int> >::vector(unsigned long) vector:1148 (Brainsight:x86_64+0x1003478f9)
#7 std::__1::vector<int, std::__1::allocator<int> >::vector(unsigned long) vector:1142 (Brainsight:x86_64+0x10031831c)
#8 std::__1::__shared_ptr_emplace<std::__1::vector<int, std::__1::allocator<int> >, std::__1::allocator<std::__1::vector<int, std::__1::allocator<int> > > >::__shared_ptr_emplace<long long>(std::__1::allocator<std::__1::vector<int, std::__1::allocator<int> > >, long long&&) shared_ptr.h:298 (Brainsight:x86_64+0x1068da00a)
#9 std::__1::__shared_ptr_emplace<std::__1::vector<int, std::__1::allocator<int> >, std::__1::allocator<std::__1::vector<int, std::__1::allocator<int> > > >::__shared_ptr_emplace<long long>(std::__1::allocator<std::__1::vector<int, std::__1::allocator<int> > >, long long&&) shared_ptr.h:292 (Brainsight:x86_64+0x1068d97b3)
#10 std::__1::shared_ptr<std::__1::vector<int, std::__1::allocator<int> > > std::__1::allocate_shared<std::__1::vector<int, std::__1::allocator<int> >, std::__1::allocator<std::__1::vector<int, std::__1::allocator<int> > >, long long, void>(std::__1::allocator<std::__1::vector<int, std::__1::allocator<int> > > const&, long long&&) shared_ptr.h:1106 (Brainsight:x86_64+0x1068d94b8)
#11 std::__1::shared_ptr<std::__1::vector<int, std::__1::allocator<int> > > std::__1::make_shared<std::__1::vector<int, std::__1::allocator<int> >, long long, void>(long long&&) shared_ptr.h:1115 (Brainsight:x86_64+0x1068d5d20)
#12 (anonymous namespace)::CellProcessor<int>::CellProcessor(vtkCellBinner*) vtkStaticCellLocator.cxx:327 (Brainsight:x86_64+0x1068d59e8)
#13 (anonymous namespace)::CellProcessor<int>::CellProcessor(vtkCellBinner*) vtkStaticCellLocator.cxx:321 (Brainsight:x86_64+0x1068767f3)
#14 vtkStaticCellLocator::BuildLocatorInternal() vtkStaticCellLocator.cxx:1549 (Brainsight:x86_64+0x10687617c)
#15 vtkStaticCellLocator::BuildLocator() vtkStaticCellLocator.cxx:1470 (Brainsight:x86_64+0x106874f25)
#16 -[BSStageView makeSurface:] BSStageView.mm:4017 (Brainsight:x86_64+0x10244976a)
#17 -[BSStageView makeReconstructions:] BSStageView.mm:4544 (Brainsight:x86_64+0x102453de7)
#18 -[BSStageView consumeReconstructionsMask] BSStageView.mm:10522 (Brainsight:x86_64+0x1024b55f5)
#19 -[BSStageView updateScene] BSStageView.mm:15522 (Brainsight:x86_64+0x10250ee66)
#20 -[BSStageView updateSceneAndRender] BSStageView.mm:2258 (Brainsight:x86_64+0x102426938)
#21 -[BSStageViewLayer drawInCGLContext:pixelFormat:forLayerTime:displayTime:] BSStageViewLayer.m:88 (Brainsight:x86_64+0x101020dc8)
#22 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) <null>:2 (QuartzCore:x86_64+0xc25be)
#23 start <null>:2 (dyld:x86_64+0x552d)
Thread T72 (tid=17788019, running) created by main thread at:
#0 pthread_create <null>:2 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x2df1f)
#1 std::__1::__libcpp_thread_create(_opaque_pthread_t**, void* (*)(void*), void*) __threading_support:421 (Brainsight:x86_64+0x104762c77)
#2 std::__1::thread::thread<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>, void>(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) thread:314 (Brainsight:x86_64+0x1047628a5)
#3 std::__1::thread::thread<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>, void>(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) thread:306 (Brainsight:x86_64+0x104762713)
#4 void std::__1::allocator<std::__1::thread>::construct<std::__1::thread, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::thread*, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) allocator.h:154 (Brainsight:x86_64+0x10476268f)
#5 void std::__1::allocator_traits<std::__1::allocator<std::__1::thread> >::construct<std::__1::thread, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>, void>(std::__1::allocator<std::__1::thread>&, std::__1::thread*, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) allocator_traits.h:290 (Brainsight:x86_64+0x10476246b)
#6 void std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread> >::__construct_one_at_end<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) vector:948 (Brainsight:x86_64+0x1047620c4)
#7 void std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread> >::emplace_back<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) vector:1706 (Brainsight:x86_64+0x10475c2ba)
#8 vtk::detail::smp::vtkSMPThreadPool::vtkSMPThreadPool(int) vtkSMPThreadPool.cxx:33 (Brainsight:x86_64+0x10475be81)
#9 vtk::detail::smp::vtkSMPThreadPool::vtkSMPThreadPool(int) vtkSMPThreadPool.cxx:29 (Brainsight:x86_64+0x10475c65f)
#10 void vtk::detail::smp::vtkSMPToolsImpl<(vtk::detail::smp::BackendType)1>::For<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false> >(long long, long long, long long, vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>&) vtkSMPToolsImpl.txx:80 (Brainsight:x86_64+0x1068e582d)
#11 void vtk::detail::smp::vtkSMPToolsAPI::For<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false> >(long long, long long, long long, vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>&) vtkSMPToolsAPI.h:114 (Brainsight:x86_64+0x1068e54a3)
#12 vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>::For(long long, long long, long long) vtkSMPTools.h:101 (Brainsight:x86_64+0x1068e52f3)
#13 void vtkSMPTools::For<(anonymous namespace)::MapOffsets<int> >(long long, long long, long long, (anonymous namespace)::MapOffsets<int>&) vtkSMPTools.h:246 (Brainsight:x86_64+0x1068e51ae)
#14 void vtkSMPTools::For<(anonymous namespace)::MapOffsets<int> >(long long, long long, (anonymous namespace)::MapOffsets<int>&) vtkSMPTools.h:270 (Brainsight:x86_64+0x106876a57)
#15 vtkStaticCellLocator::BuildLocatorInternal() vtkStaticCellLocator.cxx:1553 (Brainsight:x86_64+0x106876279)
#16 vtkStaticCellLocator::BuildLocator() vtkStaticCellLocator.cxx:1470 (Brainsight:x86_64+0x106874f25)
#17 -[BSStageView makeSurface:] BSStageView.mm:4017 (Brainsight:x86_64+0x10244976a)
#18 -[BSStageView makeReconstructions:] BSStageView.mm:4544 (Brainsight:x86_64+0x102453de7)
#19 -[BSStageView consumeReconstructionsMask] BSStageView.mm:10522 (Brainsight:x86_64+0x1024b55f5)
#20 -[BSStageView updateScene] BSStageView.mm:15522 (Brainsight:x86_64+0x10250ee66)
#21 -[BSStageView updateSceneAndRender] BSStageView.mm:2258 (Brainsight:x86_64+0x102426938)
#22 -[BSStageViewLayer drawInCGLContext:pixelFormat:forLayerTime:displayTime:] BSStageViewLayer.m:88 (Brainsight:x86_64+0x101020dc8)
#23 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) <null>:2 (QuartzCore:x86_64+0xc25be)
#24 start <null>:2 (dyld:x86_64+0x552d)
Thread T52 (tid=17788020, finished) created by main thread at:
#0 pthread_create <null>:2 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x2df1f)
#1 std::__1::__libcpp_thread_create(_opaque_pthread_t**, void* (*)(void*), void*) __threading_support:421 (Brainsight:x86_64+0x104762c77)
#2 std::__1::thread::thread<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>, void>(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) thread:314 (Brainsight:x86_64+0x1047628a5)
#3 std::__1::thread::thread<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>, void>(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) thread:306 (Brainsight:x86_64+0x104762713)
#4 void std::__1::allocator<std::__1::thread>::construct<std::__1::thread, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::thread*, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) allocator.h:154 (Brainsight:x86_64+0x10476268f)
#5 void std::__1::allocator_traits<std::__1::allocator<std::__1::thread> >::construct<std::__1::thread, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>, void>(std::__1::allocator<std::__1::thread>&, std::__1::thread*, std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) allocator_traits.h:290 (Brainsight:x86_64+0x10476246b)
#6 void std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread> >::__construct_one_at_end<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) vector:948 (Brainsight:x86_64+0x1047620c4)
#7 void std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread> >::emplace_back<std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*> >(std::__1::__bind<void (vtk::detail::smp::vtkSMPThreadPool::*)(), vtk::detail::smp::vtkSMPThreadPool*>&&) vector:1706 (Brainsight:x86_64+0x10475c2ba)
#8 vtk::detail::smp::vtkSMPThreadPool::vtkSMPThreadPool(int) vtkSMPThreadPool.cxx:33 (Brainsight:x86_64+0x10475be81)
#9 vtk::detail::smp::vtkSMPThreadPool::vtkSMPThreadPool(int) vtkSMPThreadPool.cxx:29 (Brainsight:x86_64+0x10475c65f)
#10 void vtk::detail::smp::vtkSMPToolsImpl<(vtk::detail::smp::BackendType)1>::For<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false> >(long long, long long, long long, vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>&) vtkSMPToolsImpl.txx:80 (Brainsight:x86_64+0x1068e582d)
#11 void vtk::detail::smp::vtkSMPToolsAPI::For<vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false> >(long long, long long, long long, vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>&) vtkSMPToolsAPI.h:114 (Brainsight:x86_64+0x1068e54a3)
#12 vtk::detail::smp::vtkSMPTools_FunctorInternal<(anonymous namespace)::MapOffsets<int>, false>::For(long long, long long, long long) vtkSMPTools.h:101 (Brainsight:x86_64+0x1068e52f3)
#13 void vtkSMPTools::For<(anonymous namespace)::MapOffsets<int> >(long long, long long, long long, (anonymous namespace)::MapOffsets<int>&) vtkSMPTools.h:246 (Brainsight:x86_64+0x1068e51ae)
#14 void vtkSMPTools::For<(anonymous namespace)::MapOffsets<int> >(long long, long long, (anonymous namespace)::MapOffsets<int>&) vtkSMPTools.h:270 (Brainsight:x86_64+0x106876a57)
#15 vtkStaticCellLocator::BuildLocatorInternal() vtkStaticCellLocator.cxx:1553 (Brainsight:x86_64+0x106876279)
#16 vtkStaticCellLocator::BuildLocator() vtkStaticCellLocator.cxx:1470 (Brainsight:x86_64+0x106874f25)
#17 -[BSStageView makeSurface:] BSStageView.mm:4017 (Brainsight:x86_64+0x10244976a)
#18 -[BSStageView makeReconstructions:] BSStageView.mm:4544 (Brainsight:x86_64+0x102453de7)
#19 -[BSStageView consumeReconstructionsMask] BSStageView.mm:10522 (Brainsight:x86_64+0x1024b55f5)
#20 -[BSStageView updateScene] BSStageView.mm:15522 (Brainsight:x86_64+0x10250ee66)
#21 -[BSStageView updateSceneAndRender] BSStageView.mm:2258 (Brainsight:x86_64+0x102426938)
#22 -[BSStageViewLayer drawInCGLContext:pixelFormat:forLayerTime:displayTime:] BSStageViewLayer.m:88 (Brainsight:x86_64+0x101020dc8)
#23 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) <null>:2 (QuartzCore:x86_64+0xc25be)
#24 start <null>:2 (dyld:x86_64+0x552d)
SUMMARY: ThreadSanitizer: data race fill_n.h:31 in int* std::__1::__fill_n<int*, int, long>(int*, int, long const&)
==================
```
If I switch from `vtkStaticCellLocator` to `vtkCellLocator` the issue goes away.
Not sure if it matters, but I'm using the STDThread SMP backend.Will SchroederWill Schroederhttps://gitlab.kitware.com/vtk/vtk/-/issues/18437`vtkThreshold` should output ghost points when necessary2022-01-11T14:16:05-05:00Yohann Bearzi (Kitware)`vtkThreshold` should output ghost points when necessaryWhen applying `vtkThreshold` on a `vtkImageData` input, ghost points are not generated at the interface between ranks. As a consequence, downstream filters can fail if they need unique points. Reducing the opacity display an unwanted int...When applying `vtkThreshold` on a `vtkImageData` input, ghost points are not generated at the interface between ranks. As a consequence, downstream filters can fail if they need unique points. Reducing the opacity display an unwanted interface when rendering.
![threshold](/uploads/5eca975ac4597e1f614e2bcade600d62/threshold.png)