VTK static lib bug report about vtkInformationXXKey when using more than one copy of vtk libs

Support
1

I have problem running my exe linked against static vtk libs, involving such as vtkImageSlice. The case is I have a project consisting of a core lib and a test exe. The core lib links against vtk static libs and the test exe links against vtk static or dynamic libs. After my debugging efforts, I found the problem is systematic. The cause is each copy of vtk lib batch have their own static vtkInformationXXKey* (in vtkDataObject.h). When passing a vtkImageData pointer from the test exe to the core lib, as input for vtkImageSlice, then running vtkImageSlice::update(). During which process, the codes MapType::const_iterator i = this->Internal->Map.find(key); in vtkInformation.cxx will result invalid iter. that is because the Map using vtkInformationKey*(static vtkInformationXXKey* in vtkDataObject.h) as key instead of just std::string. That means vtkInformation is systematiclly not fit for crossing copies of vtk libs(translation units)

2

please share steps to reproduce.

3

a test.exe and a core.lib, both link against vtk static libs
test.exe first load a vtkImageData with a vtkDICOMImageReader, to a var(imageData), then pass that vtkImageData pointer to core.lib function like XX->SetInputData(imageData)。
SetInputData is like:
XX::SetInputData(vtkImageData* imageData)
{
vtkSmartPointer imageSlab = vtkImageSlab::New();
imageSlab->SetInputData(imageData);
imageSlab->Update();
int ext[6] = {0};
imageSlab->GetUpdateExtent(ext);// here we get invalid ext
}
//If dynamic vtk libs are used, that problem is not exist

4

I’m afraid an actual project that can be compiled will be needed.

5

Sorry, new users can not upload attachments. :unamused:

6

Try again :slight_smile:

7

vtk_static_lib_issue_demo.7z (3.5 KB)

8

fails to build for Qt related reasons.

[glow@arch ~/tmp/test/build]$ cmake ./
-- Found Embree v4.1.0: /usr/lib/libembree4.so.4
-- Found Open VKL v1.3.2: /usr/lib/libopenvkl.so.1.3.2
-- Found Embree v4.1.0: /usr/lib/libembree4.so.4
-- Found Open VKL v1.3.2: /usr/lib/libopenvkl.so.1.3.2
-- Configuring done (0.1s)
CMake Warning (dev) in TestRenderer3D/CMakeLists.txt:
  AUTOGEN: No valid Qt version found for target TestRenderer3D.  AUTOMOC,
  AUTOUIC and AUTORCC disabled.  Consider adding:

    find_package(Qt<QTVERSION> COMPONENTS Widgets)

  to your CMakeLists.txt file.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done (0.0s)
-- Build files have been written to: /home/glow/tmp/test/build
[glow@arch ~/tmp/test/build]$ make
[ 16%] Automatic MOC and UIC for target Renderer3D
[ 16%] Built target Renderer3D_autogen
[ 33%] Building CXX object Renderer3D/CMakeFiles/Renderer3D.dir/src/RenderModel.cpp.o
In file included from /home/glow/tmp/test/Renderer3D/include/Render/Renderer3D/RenderModel.h:4,
                 from /home/glow/tmp/test/Renderer3D/src/RenderModel.cpp:1:
/home/glow/tmp/test/Renderer3D/include/Render/Renderer3D/Render_Renderer3D_global.h:4:10: fatal error: QtCore/qglobal.h: No such file or directory
    4 | #include <QtCore/qglobal.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Renderer3D/CMakeFiles/Renderer3D.dir/build.make:90: Renderer3D/CMakeFiles/Renderer3D.dir/src/RenderModel.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:144: Renderer3D/CMakeFiles/Renderer3D.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
9

vtk_static_lib_issue_demo_v2.7z (3.1 KB)
Qt Removed

10

I’m able to build against a statically linked VTK without issue:

[glow@arch ~/tmp/test2/build]$ make
[ 25%] Building CXX object Renderer3D/CMakeFiles/Renderer3D.dir/src/RenderModel.cpp.o
[ 50%] Linking CXX shared library libRender-Renderer3D.so
[ 50%] Built target Renderer3D
[ 75%] Building CXX object TestRenderer3D/CMakeFiles/TestRenderer3D.dir/main.cpp.o
[100%] Linking CXX executable TestRenderer3D
[100%] Built target TestRenderer3D

[glow@arch ~/tmp/test2/build]$ ./TestRenderer3D/TestRenderer3D 
2023-07-28 10:12:25.962 (   0.000s) [        ]vtkDICOMImageReader.cxx:145    ERR| vtkDICOMImageReader (0x5630d98e9be0): Couldn't open E:/DicomDataset/manifest-1617826555824/Pseudo-PHI-DICOM-Data/3209648408/09-23-1999-NA-CT UROGRAM-31798/3.000000-PARENCHYMAL PHASE Sep1999-95798
2023-07-28 10:12:25.963 (   0.000s) [        ]vtkDICOMImageReader.cxx:237    ERR| vtkDICOMImageReader (0x5630d98e9be0): Either a filename was not specified or the specified directory does not contain any DICOM images.
2023-07-28 10:12:25.963 (   0.000s) [        ]       vtkExecutive.cxx:741    ERR| vtkCompositeDataPipeline (0x5630d98c87b0): Algorithm vtkDICOMImageReader (0x5630d98e9be0) returned failure for request: vtkInformation (0x5630d98eb6c0)
  Debug: Off
  Modified Time: 143
  Reference Count: 1
  Registered Events: (none)
  Request: REQUEST_DATA
  FROM_OUTPUT_PORT: 0
  ALGORITHM_AFTER_FORWARD: 1
  FORWARD_DIRECTION: 0
11

Build is not the problem.
Do you have a dicom image folder? Please specify a directory in main.cpp, then build again.
After you can run the excutable. Check out the running result: std::cout << ext[1]; It should return invalid value as -1

12

Global static data is evil. VTK has quite a bit of it, however. I’m afraid you’re going to have to either use dynamic libraries everywhere or funnel all VTK calls through one library that links to VTK statically so that there is just one source of VTK in the process.

I’d love to excise static global data everywhere, but it’s never on the top of the urgency list :confused: .

1 Like