VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2018-10-03T08:45:38-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/17401Context2D API: Can we provide something like vtkProperty for vtkContextItems?2018-10-03T08:45:38-04:00Scott WittenburgContext2D API: Can we provide something like vtkProperty for vtkContextItems?Similar to how we use `vtkProperty` to customize the appears of a `vtkActor`, it could be nice to do something similar for `vtkContextItem`. Currently we use some limited "DrawHints" which are provided via `vtkFieldData` added to the `v...Similar to how we use `vtkProperty` to customize the appears of a `vtkActor`, it could be nice to do something similar for `vtkContextItem`. Currently we use some limited "DrawHints" which are provided via `vtkFieldData` added to the `vtkPolyData` which is wrapped in `vtkPolyDataItem`, a subclass of `vtkContextItem`.
See !4696 for some discussion.Scott WittenburgScott Wittenburghttps://gitlab.kitware.com/vtk/vtk/-/issues/15468Contour display not working for quad polygons from Java2017-10-27T08:52:59-04:00Kitware RobotContour display not working for quad polygons from Java**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15468). Further discussion may take place here.**
---
Hi,
I have modified the vtkDemo sample to reproduce the problem that I am ha...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15468). Further discussion may take place here.**
---
Hi,
I have modified the vtkDemo sample to reproduce the problem that I am having with displaying contours on a quad polygon based model. I have assigned scalar values in the polydata and defined a multi-color lookup table, but all the facets are displayed with a single color.
The attached file has a method createCube() that performs all the data preparation for contouring as I understand it should be. The rest of the code is just the standard vtkDemo.
I would like to know if I am doing something wrong, or there is a problem in the Java implementation related to contouring. I have had a post on the VTK forum (Nabble) for a few days, but no one has responded to it. https://gitlab.kitware.com/vtk/vtk/-/issues/17789Contour scaling not working in vtkOrientedGlyphContourRepresentation2020-02-27T05:57:43-05:00Gerald LodronContour scaling not working in vtkOrientedGlyphContourRepresentationat line 514 of vtkOrientedGlyphContourRepresentation.cxx:
```
worldPos[0] = centroid[0] + ratio * ( ref[0] - centroid[0] );
worldPos[1] = centroid[0] + ratio * ( ref[1] - centroid[1] );
worldPos[2] = centroid[0] + ratio * ( ref[2]...at line 514 of vtkOrientedGlyphContourRepresentation.cxx:
```
worldPos[0] = centroid[0] + ratio * ( ref[0] - centroid[0] );
worldPos[1] = centroid[0] + ratio * ( ref[1] - centroid[1] );
worldPos[2] = centroid[0] + ratio * ( ref[2] - centroid[2] );
```
should be:
```
worldPos[0] = centroid[0] + ratio * ( ref[0] - centroid[0] );
worldPos[1] = centroid[1] + ratio * ( ref[1] - centroid[1] );
worldPos[2] = centroid[2] + ratio * ( ref[2] - centroid[2] );
```
for some reason the right button event onto a node of the vtkContourWidget's polygon also doesnt work/doesnt call callback. I added the lines
```
GetEventTranslator()->RemoveTranslation( vtkCommand::RightButtonPressEvent );
GetEventTranslator()->RemoveTranslation( vtkCommand::RightButtonReleaseEvent );
GetEventTranslator()->SetTranslation(
vtkCommand::RightButtonPressEvent,
vtkEvent::NoModifier, 103, 0, NULL,
vtkWidgetEvent::AddFinalPoint );
GetEventTranslator()->SetTranslation(
vtkCommand::RightButtonPressEvent,
vtkEvent::ShiftModifier, 103, 0, NULL,
vtkWidgetEvent::Scale );
GetEventTranslator()->SetTranslation(
vtkCommand::RightButtonReleaseEvent,
vtkEvent::NoModifier, 103, 0, NULL,
vtkWidgetEvent::EndScale );
GetEventTranslator()->SetTranslation(
vtkCommand::RightButtonReleaseEvent,
vtkEvent::ShiftModifier, 103, 0, NULL,
vtkWidgetEvent::EndScale );
```
to get it working if i use scaling with shift modifier, but it should work without shift modifier as intended... so there are 2 issues....https://gitlab.kitware.com/vtk/vtk/-/issues/727contourbands and contourlines2016-08-12T06:19:18-04:00Kitware Robotcontourbands and contourlines**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=727). Further discussion may take place here.**
---
Hi all again,
I am still stucked on the problem of isofilled and isolines cont...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=727). Further discussion may take place here.**
---
Hi all again,
I am still stucked on the problem of isofilled and isolines contours.
See: http://public.kitware.com/pipermail/vtkusers/2004-March/022780.html
I have prepared 2 tcl examples showing my
impossiblity to get exact line contours over isofilled contours.
See:
http://dods.ipsl.jussieu.fr/brocksce/vtk_bugs/bandcontours/iso_02_annotate.png
All examples in tcl are available at:
http://dods.ipsl.jussieu.fr/brocksce/vtk_bugs/bandcontours/
Any help very welcome.
Patrickhttps://gitlab.kitware.com/vtk/vtk/-/issues/3691Contouring of new nonlinear cells incorrect2016-08-12T06:37:48-04:00Kitware RobotContouring of new nonlinear cells incorrect**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3691). Further discussion may take place here.**
---
The contour is not calculated correctly, because the point id numbering
while c...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=3691). Further discussion may take place here.**
---
The contour is not calculated correctly, because the point id numbering
while contouring is incorrect in most of the new nonlinear cell implementations.
I have fixed this bug.
I didnt recognized this bug ealier, because i have tested the contouring
with only one cell .... .
Futhermore i have extended the quadCellConsistency.cxx test with most of
the new cell types.
Unfortunately the vtkQuadraticLinearWedge fails the "face" test, because
the of vtkQuadraticLineareQuad
numbering.
The cvs diff is attached.https://gitlab.kitware.com/vtk/vtk/-/issues/14728Contradictory documentation2017-10-27T08:52:59-04:00Kitware RobotContradictory documentation**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=14728). Further discussion may take place here.**
---
Documentation of vtkThreshold::ThresholdByLower and vtkThreshold::ThresholdByUp...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=14728). Further discussion may take place here.**
---
Documentation of vtkThreshold::ThresholdByLower and vtkThreshold::ThresholdByUpper is contradictory: "Criterion is cells whose scalars are less or equal to lower threshold." and "Criterion is cells whose scalars are greater or equal to upper threshold." But an UPPER limit keeps LOWER values and vice versa. So the user has to go to the implementing code in order to know, which function function determines which threshold.https://gitlab.kitware.com/vtk/vtk/-/issues/9080Contribution for a new vtkImplicitFunction that represent a torus.2016-08-12T07:06:43-04:00Kitware RobotContribution for a new vtkImplicitFunction that represent a torus.**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=9080). Further discussion may take place here.**
---
The contribution contains a README on own to integrate into VTK and a C++ class ...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=9080). Further discussion may take place here.**
---
The contribution contains a README on own to integrate into VTK and a C++ class with a vtkTorus header and C++ file.
Some visual testing have been done by clipping a structured dataset with this implicit function and validating the resulting shape.
https://gitlab.kitware.com/vtk/vtk/-/issues/17307Convert cells to higher-order versions automatically?2018-10-23T10:53:22-04:00Andrew TaberConvert cells to higher-order versions automatically?I'm wondering if it's possible to take, say, a Hex cell and automatically instantiate a TriQuadraticHex from its data?I'm wondering if it's possible to take, say, a Hex cell and automatically instantiate a TriQuadraticHex from its data?https://gitlab.kitware.com/vtk/vtk/-/issues/16814convert projects to the third party update scripts2019-02-23T16:20:46-05:00Ben Boeckelconvert projects to the third party update scriptsProjects:
* [x] alglib
* [x] AutobahnPython
* [x] constantly
* [x] diy2
* [x] exodusII
* [x] expat
* [x] freerange
* [ ] freetype
* [x] gl2ps
* [x] glew
* [x] hdf5
* [x] hyperlink
* [x] incremental
* [x] jpeg
* [x] jsoncp...Projects:
* [x] alglib
* [x] AutobahnPython
* [x] constantly
* [x] diy2
* [x] exodusII
* [x] expat
* [x] freerange
* [ ] freetype
* [x] gl2ps
* [x] glew
* [x] hdf5
* [x] hyperlink
* [x] incremental
* [x] jpeg
* [x] jsoncpp
* [x] libharu
* [x] libproj4
* [x] libxml2
* [x] lz4
* [x] mpi4py
* [ ] netcdf
* [x] oggtheora
* [x] png
* [x] SixPython
* [ ] sqlite
* [ ] TclTk
* [x] tiff
* [x] Twisted
* [x] txaio
* [ ] utf8
* [ ] verdict
* [ ] VPIC
* [x] xdmf2
* [x] xdmf3
* [x] wslink
* [x] zfp
* [x] zlib
* [x] ZopeInterface
* [x] GitSetup (!3457)
* [x] KWIML
* [x] KWSys
* [x] MetaIOBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17477Convert verdict to use an import script2022-03-04T08:42:07-05:00Ben BoeckelConvert verdict to use an import scriptVerdict has a repository at https://gitlab.kitware.com/verdict/verdict. VTK should import its copy based on code from that repository.Verdict has a repository at https://gitlab.kitware.com/verdict/verdict. VTK should import its copy based on code from that repository.Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/1402Converting color RGB/HSV from int to double and double to int2016-08-12T06:23:26-04:00Kitware RobotConverting color RGB/HSV from int to double and double to int**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=1402). Further discussion may take place here.**
---
Some multiplatform GUI toolkits provides colors based on int RGB or HSV values (...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=1402). Further discussion may take place here.**
---
Some multiplatform GUI toolkits provides colors based on int RGB or HSV values (Qt for example)
http://doc.trolltech.com/3.3/qcolor.html
It will be nice to have converter color RGB/HSV from int to double and double to int inside vtkMath.
Example:
// Description:
// Convert color RGB from int to double and double to int.
// The input color is not modified.
static void RGBTorgb(int RGB[3], double rgb[3])
{
RGBTorgb(RGB[0], RGB[1], RGB[2], rgb, rgb+1, rgb+2);
}
static void RGBTorgb(int R, int G, int B, double *r, double *g, double *b);
static void rgbToRGB(double rgb[3], int RGB[3])
{
rgbToRGB(rgb[0], rgb[1], rgb[2], RGB, RGB+1, RGB+2);
}
static void rgbToRGB(double r, double g, double b, int *R, int *G, int *B);
// Description:
// Convert color HSV from int to double and double to int.
// The input color is not modified.
static void HSVTohsv(int HSV[3], double hsv[3])
{
HSVTohsv(HSV[0], HSV[1], HSV[2], hsv, hsv+1, hsv+2);
}
static void HSVTohsv(int H, int S, int V, double *h, double *s, double *v);
static void hsvToHSV(double hsv[3], int HSV[3])
{
hsvToHSV(hsv[0], hsv[1], hsv[2], HSV, HSV+1, HSV+2);
}
static void hsvToHSV(double h, double s, double v, int *H, int *S, int *V);https://gitlab.kitware.com/vtk/vtk/-/issues/5111coordinate conversions inconsistent2016-08-12T06:45:02-04:00Kitware Robotcoordinate conversions inconsistent**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5111). Further discussion may take place here.**
---
There are myriad ways to convert point locations between DISPLAY, VIEWPORT, VIEW...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=5111). Further discussion may take place here.**
---
There are myriad ways to convert point locations between DISPLAY, VIEWPORT, VIEW, and WORLD coordinates. For example: vtkRenderer provides SetWorldPoint(), WorldToDisplay(), and GetDisplayPoint() which can be strung together to transform world coordinates to display coordinates; on the other hand vtkCoordinate provides SetCoordinateSystemToWorld(), SetValue() and GetComputedDoubleDisplayValue() which should do the same transformation.
However, the two methods don't always agree.
There are more examples of conversion inconsistency between vtkRenderer and vtkCoordinate, as demonstrated by the attached test case.https://gitlab.kitware.com/vtk/vtk/-/issues/18198Coplanar surfaces blending with dual depth peeling2021-05-05T11:39:52-04:00Arnaud afaCoplanar surfaces blending with dual depth peelingWhen coincident surfaces are rendered, I have observed differences whether you use alpha blending, legacy or dual depth peeling. The example is using a composite dataset and mapper. I also tested with separated mappers/actors with same r...When coincident surfaces are rendered, I have observed differences whether you use alpha blending, legacy or dual depth peeling. The example is using a composite dataset and mapper. I also tested with separated mappers/actors with same results.
When rendering surfaces from vertices sharing the same coordinates, it seems that the colors are just summed up leading to lighter result instead of expected darker result.
I am testing with 3 cubes all with opacity (0.3) and overlapping in different ways:
1. cube1 is blue/green (0., 0.8, 0.8)
2. cube2 is red (0.8, 0., 0.) and translated in a way that some of its vertices are perfectly overlapping cube1's
3. cube3 is light grey (0.8, 0.8, 0.8) translated and rotated in a way that its vertices are not overlapping other cubes' but still have co-planar surfaces with cube2
Here are the results. I am not really interested in cube3 artifacts. To me the blending of cube1 and cube2 is more worrying:
* Top-left alpha blending: seems like the correct blending to me between cube1 and cube2. I guess that both cubes are rendered separately and the renders blent together at the end?
* Top-right legacy depth peeling: cube2 is taking over cube1. Is it because the depth buffer keeps the last fragments if it finds two at the same place?
* Bottom-left dual depth peeling: The overlapping area is (0.8, 0.8, 0.8). This is surprising as I would expect the front peel to be red, same for the back peel, resulting in red like legacy depth peeling
* Bottom-right dual depth peeling, cube1 is slightly offset: offset can be x, y or z. Now we have the correct color but with artifacts
![coplanar](/uploads/21a1a5e82dec745d59ffa3829ec4e211/coplanar.png)
By using dual depth peeling, I was hoping to render with the correct color hopefully without artifacts. **Is the render bottom-left expected?**
Here is a script. You can set the transparency methods at the top. Offset can be applied easily to each cubes distinctly.
[mini_coplanar.py](/uploads/8603fafa1fde5e155794d6c3ef52f24d/mini_coplanar.py)https://gitlab.kitware.com/vtk/vtk/-/issues/19206copy-paste error in vtkCCSFindTrueEdges() of the vtkContourTriangulator algor...2024-01-02T05:40:31-05:00Dan Sebaldcopy-paste error in vtkCCSFindTrueEdges() of the vtkContourTriangulator algorithmThe vtkContourTriangulator algorithm is really nice. I'll likely have more to write, but in working with the algorithm, I noticed what looks like a copy/paste error in the update to the next edge which is using p2 twice.
Here's the hun...The vtkContourTriangulator algorithm is really nice. I'll likely have more to write, but in working with the algorithm, I noticed what looks like a copy/paste error in the update to the next edge which is using p2 twice.
Here's the hunk of suspect code:
~~~
// Rotate to the next point
p0[0] = p2[0];
p0[1] = p2[1];
p0[2] = p2[2];
p1[0] = p2[0];
p1[1] = p2[1];
p1[2] = p2[2];
v1[0] = v2[0];
v1[1] = v2[1];
v1[2] = v2[2];
l1 = l2;
~~~
Notice how the right column has p2 for the first six assignments. Just above the loop in which this code appears is the definition/initialization
~~~
v2[0] = p2[0] - p1[0];
v2[1] = p2[1] - p1[1];
v2[2] = p2[2] - p1[2];
l2 = vtkMath::Dot(v2, v2);
~~~
If the iteration is to remain consistent, with v2 becoming v1, then p2 becomes p1 and p1 (not p2) becomes p0.
Attached is a patch in which I made some changes. The patch isn't from git, just a unified-diff. I'm not building the whole of VTK via git checkout, rather "patching" a library of sorts by introducing a routine of nearly the same name (irrelevant).
[edge_rotate_copy_paste_error_vtkContourTriangulator.diff](/uploads/27f1e4ba1e6191185c484d0ceb92232d/edge_rotate_copy_paste_error_vtkContourTriangulator.diff)
In the patch I've included some non-bug mods that one can take-or-leave. There are a few places where a Boolean is declared or inherent in the expression, and bit-wise-and (&) is used rather than logical-and (&&). I've seen bit-wise-and used quite a bit in the VTK code I've looked at, but in most instances the variable is declared as an "int", which I'd be fine with.
Then there are a few cases where I moved a variable update and its associated range-check next to one another, e.g.,
~~~
size_t midIdx = idx1 + 1;
if (midIdx >= n)
{
midIdx -= n;
}
~~~
because the optimizing-compiler programmer in me thinks it could save one or two machine cycles by leaving the result in a register, then perform the range limit immediately after. (But there are so many registers in modern CPUs, who knows?)
What I would say about the vtkContourTriangulator's edge finding for non-closed segments is that I tried it. Although I didn't find it working as desired, it's always difficult to be conclusive when simply trying to get off the ground with model data and some sort of reasonable result. I figured my expectations were probably too great, i.e., that a generalized approach probably wouldn't achieve something better than what can be done by incorporating the known characteristics of the application. So, I moved on to closing open segments before passing the contours onto vtkContourTriangulator. Would the above mod have made a difference? Doubt it. It's a subtle effect, I'm guessing. I noticed there are some data sets for testing vtkContourTriangulator, but haven't gotten as far as working with those files yet.https://gitlab.kitware.com/vtk/vtk/-/issues/1590Copying input instead of source point data in vtkGlyph3D2016-08-12T06:24:44-04:00Kitware RobotCopying input instead of source point data in vtkGlyph3D**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=1590). Further discussion may take place here.**
---
As far as I understand, for vtkGlyph3D, the point data copied to the output must...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=1590). Further discussion may take place here.**
---
As far as I understand, for vtkGlyph3D, the point data copied to the output must come from the SOURCE and not the INPUT. This was correct in VTK < 4.5.
In vtkGlyph3D.cxx, line 268 is currently:
pd = input->GetPointData();
This should be:
pd = source->GetPointData();
And then on line 576:
outputPD->CopyData(pd,inPtId,ptIncr+i);
Should be:
outputPD->CopyData(pd,i,ptIncr+i);https://gitlab.kitware.com/vtk/vtk/-/issues/17470Copyright comments need updated2019-01-25T09:00:11-05:00Ben BoeckelCopyright comments need updatedThe copyright comments in these files reference Kitware's old address. They should be updated to match the rest of VTK:
- Rendering/OpenGL2/glsl/vtkEDLBilateralFilterFS.glsl
- Rendering/OpenGL2/glsl/vtkEDLComposeFS.glsl
- Renderin...The copyright comments in these files reference Kitware's old address. They should be updated to match the rest of VTK:
- Rendering/OpenGL2/glsl/vtkEDLBilateralFilterFS.glsl
- Rendering/OpenGL2/glsl/vtkEDLComposeFS.glsl
- Rendering/OpenGL2/glsl/vtkEDLShadeFS.glsl
- Rendering/OpenGL2/vtkDepthImageProcessingPass.cxx
- Rendering/OpenGL2/vtkDepthImageProcessingPass.h
- Rendering/OpenGL2/vtkEDLShading.cxx
- Rendering/OpenGL2/vtkEDLShading.h
- ThirdParty/mpi4py/CMakeLists.txt
Cc: @ken\-martinhttps://gitlab.kitware.com/vtk/vtk/-/issues/17842Could not build VTK on LinuxMint2020-04-13T07:36:35-04:00Innokenty ZhdanovCould not build VTK on LinuxMintHello.
I'm trying to build VTK for LinuxMint. I've followed https://vtk.org/Wiki/VTK/Building/Linux this one tutorial and installed QT5.14.2 and then have tried to make VTK project. Unfortunately, i've got this message:
/home/daddyweske...Hello.
I'm trying to build VTK for LinuxMint. I've followed https://vtk.org/Wiki/VTK/Building/Linux this one tutorial and installed QT5.14.2 and then have tried to make VTK project. Unfortunately, i've got this message:
/home/daddywesker/VTK/Rendering/UI/vtkXRenderWindowInteractor.cxx:36:10: fatal error: X11/Shell.h: No such file or directory
Have tried to search for this file manually and got it here
libxt-dev: /usr/include/X11/Shell.h
How to point out this file via making project? THanks.https://gitlab.kitware.com/vtk/vtk/-/issues/18046Could VTK be used to re-construct colorful 3D using colorful CT images?2020-11-06T05:05:51-05:00ardealCould VTK be used to re-construct colorful 3D using colorful CT images?
Hi,
There are 300 colorful CT slice images. Could I use VTK to re-construct colorful 3D using those colorful CT images?
Is there any example code for my reference?
Thanks and Best Regards,
Ardeal
Hi,
There are 300 colorful CT slice images. Could I use VTK to re-construct colorful 3D using those colorful CT images?
Is there any example code for my reference?
Thanks and Best Regards,
Ardealhttps://gitlab.kitware.com/vtk/vtk/-/issues/19080Crash - Failure in ~vtkRenderWindowInteractor2023-09-20T19:16:24-04:00Lyle CollinsCrash - Failure in ~vtkRenderWindowInteractorI'm using VTK 8.2.0 (Release) and the following stacktrace gets generated when calling in main:
`viewer = nullptr;`
The line previous is:
`std::cout << "Viewer refcount: " << viewer.use_count() << std::endl;`
Which prints:
`Viewer r...I'm using VTK 8.2.0 (Release) and the following stacktrace gets generated when calling in main:
`viewer = nullptr;`
The line previous is:
`std::cout << "Viewer refcount: " << viewer.use_count() << std::endl;`
Which prints:
`Viewer refcount: 1`
viewer is defined as so:
`std::shared_ptr<scrimmage::Viewer> viewer = std::make_shared<scrimmage::Viewer>();`
The error message reported is:
`Segmentation fault (core dumped)`
The stack trace is:
```
$ gdb scrimmage /var/lib/apport/coredump/<DUMP_FILE>
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.`
`For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from scrimmage...
[New LWP 1591358]
[New LWP 1591372]
[New LWP 1591374]
[New LWP 1591373]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by 'scrimmage <FILE>.xml'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f4509ed86af in vtkRenderWindowInteractor::~vtkRenderWindowInteractor (this=0x562b99680b10, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindowInteractor.cxx:147
147 this->InteractorStyle->UnRegister(this);
[Current thread is 1 (Thread 0x7f4506128800 (LWP 1591358))]
(gdb) bt
#0 0x00007f4509ed86af in vtkRenderWindowInteractor::~vtkRenderWindowInteractor (this=0x562b99680b10, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindowInteractor.cxx:147
#1 0x00007f4509ed87b4 in vtkRenderWindowInteractor::~vtkRenderWindowInteractor (this=0x562b99680b10, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindowInteractor.cxx:162
#2 0x00007f450b804158 in vtkObjectBase::UnRegisterInternal (this=0x562b99680b10, check=0) at $HOME/Projects/VTK/Common/Core/vtkObjectBase.cxx:240
#3 0x00007f450b802b1b in vtkObject::UnRegisterInternal (this=0x562b99680b10, o=0x562b996e6530, check=0) at $HOME/Projects/VTK/Common/Core/vtkObject.cxx:900
#4 0x00007f450b804016 in vtkObjectBase::UnRegister (this=0x562b99680b10, o=0x562b996e6530) at $HOME/Projects/VTK/Common/Core/vtkObjectBase.cxx:197
#5 0x00007f4509ed8977 in vtkRenderWindowInteractor::UnRegister (this=0x562b99680b10, o=0x562b996e6530) at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindowInteractor.cxx:207
#6 0x00007f4509ecae82 in vtkRenderWindow::SetInteractor (this=0x562b996e6530, rwi=0x0) at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindow.cxx:154
#7 0x00007f4509ecaa3a in vtkRenderWindow::~vtkRenderWindow (this=0x562b996e6530, __in_chrg=<optimized out>) at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindow.cxx:90
#8 0x00007f450bdc16ca in vtkOpenGLRenderWindow::~vtkOpenGLRenderWindow (this=0x562b996e6530, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx:234
#9 0x00007f450be7cf05 in vtkXOpenGLRenderWindow::~vtkXOpenGLRenderWindow (this=0x562b996e6530, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:340
#10 0x00007f450be7cf38 in vtkXOpenGLRenderWindow::~vtkXOpenGLRenderWindow (this=0x562b996e6530, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:354
#11 0x00007f450b804158 in vtkObjectBase::UnRegisterInternal (this=0x562b996e6530, check=0) at $HOME/Projects/VTK/Common/Core/vtkObjectBase.cxx:240
#12 0x00007f450b802b1b in vtkObject::UnRegisterInternal (this=0x562b996e6530, o=0x562b99680b10, check=0) at $HOME/Projects/VTK/Common/Core/vtkObject.cxx:900
#13 0x00007f450b804016 in vtkObjectBase::UnRegister (this=0x562b996e6530, o=0x562b99680b10) at $HOME/Projects/VTK/Common/Core/vtkObjectBase.cxx:197
#14 0x00007f4509ece820 in vtkRenderWindow::UnRegister (this=0x562b996e6530, o=0x562b99680b10) at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindow.cxx:921
#15 0x00007f4509ed8a8b in vtkRenderWindowInteractor::SetRenderWindow (this=0x562b99680b10, aren=0x0) at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindowInteractor.cxx:246
#16 0x00007f4509ed8784 in vtkRenderWindowInteractor::~vtkRenderWindowInteractor (this=0x562b99680b10, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindowInteractor.cxx:161
#17 0x00007f450be6d33c in vtkXRenderWindowInteractor::~vtkXRenderWindowInteractor (this=0x562b99680b10, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/OpenGL2/vtkXRenderWindowInteractor.cxx:108
#18 0x00007f450be6d360 in vtkXRenderWindowInteractor::~vtkXRenderWindowInteractor (this=0x562b99680b10, __in_chrg=<optimized out>)
at $HOME/Projects/VTK/Rendering/OpenGL2/vtkXRenderWindowInteractor.cxx:131
#19 0x00007f450b804158 in vtkObjectBase::UnRegisterInternal (this=0x562b99680b10, check=0) at $HOME/Projects/VTK/Common/Core/vtkObjectBase.cxx:240
#20 0x00007f450b802b1b in vtkObject::UnRegisterInternal (this=0x562b99680b10, o=0x0, check=0) at $HOME/Projects/VTK/Common/Core/vtkObject.cxx:900
#21 0x00007f450b804016 in vtkObjectBase::UnRegister (this=0x562b99680b10, o=0x0) at $HOME/Projects/VTK/Common/Core/vtkObjectBase.cxx:197
#22 0x00007f4509ed8977 in vtkRenderWindowInteractor::UnRegister (this=0x562b99680b10, o=0x0) at $HOME/Projects/VTK/Rendering/Core/vtkRenderWindowInteractor.cxx:207
#23 0x00007f450b8bf169 in vtkSmartPointerBase::~vtkSmartPointerBase (this=0x562b996885e0, __in_chrg=<optimized out>) at $HOME/Projects/VTK/Common/Core/vtkSmartPointerBase.cxx:62
#24 0x00007f450ca7c616 in vtkSmartPointer<vtkRenderWindowInteractor>::~vtkSmartPointer (this=0x562b996885e0, __in_chrg=<optimized out>) at /usr/include/vtk-8.2/vtkSmartPointer.h:30
#25 0x00007f450cac133d in scrimmage::Viewer::~Viewer (this=0x562b996885d0, __in_chrg=<optimized out>) at $HOME/scrimmage/src/viewer/Viewer.cpp:50
#26 0x0000562b995227ba in __gnu_cxx::new_allocator<scrimmage::Viewer>::destroy<scrimmage::Viewer> (this=0x562b996885d0, __p=0x562b996885d0) at /usr/include/c++/9/ext/new_allocator.h:152
#27 0x0000562b9952274f in std::allocator_traits<std::allocator<scrimmage::Viewer> >::destroy<scrimmage::Viewer> (__a=..., __p=0x562b996885d0) at /usr/include/c++/9/bits/alloc_traits.h:496
#28 0x0000562b995225c1 in std::_Sp_counted_ptr_inplace<scrimmage::Viewer, std::allocator<scrimmage::Viewer>, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x562b996885c0)
at /usr/include/c++/9/bits/shared_ptr_base.h:557
#29 0x0000562b9951ca70 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x562b996885c0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
#30 0x0000562b9951bf43 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x7fff2bef3998, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
#31 0x0000562b9951ba8e in std::__shared_ptr<scrimmage::Viewer, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x7fff2bef3990, __in_chrg=<optimized out>)
at /usr/include/c++/9/bits/shared_ptr_base.h:1169
#32 0x0000562b9951dbae in std::__shared_ptr<scrimmage::Viewer, (__gnu_cxx::_Lock_policy)2>::operator= (this=0x7fff2bef3a30, __r=...) at /usr/include/c++/9/bits/shared_ptr_base.h:1265
#33 0x0000562b9951c92e in std::shared_ptr<scrimmage::Viewer>::operator= (this=0x7fff2bef3a30, __r=...) at /usr/include/c++/9/bits/shared_ptr.h:335
#34 0x0000562b99519941 in main (argc=2, argv=0x7fff2bef4408) at $HOME/scrimmage/share/scrimmage/main.cpp:220`
```
Note that frame 25 is the only part that uses a 3rd party library, and gdb reports:
```
(gdb) f
#25 0x00007f450cac133d in scrimmage::Viewer::~Viewer (this=0x562b996885d0, __in_chrg=<optimized out>) at $HOME/scrimmage/src/viewer/Viewer.cpp:50
50 Viewer::~Viewer() {
(gdb) info f
Stack level 25, frame at 0x7fff2bef38b0:
rip = 0x7f450cac133d in scrimmage::Viewer::~Viewer ($HOME/scrimmage/src/viewer/Viewer.cpp:50); saved rip = 0x562b995227ba
called by frame at 0x7fff2bef38d0, caller of frame at 0x7fff2bef3880
source language c++.
Arglist at 0x7fff2bef3878, args: this=0x562b996885d0, __in_chrg=<optimized out>
Locals at 0x7fff2bef3878, Previous frame's sp is 0x7fff2bef38b0
Saved registers:
rbx at 0x7fff2bef3890, rbp at 0x7fff2bef38a0, r12 at 0x7fff2bef3898, rip at 0x7fff2bef38a8
```
The source files of scrimmage can be found at:
`https://github.com/gtri/scrimmage`https://gitlab.kitware.com/vtk/vtk/-/issues/15972Crash at unload library, unregister2017-10-27T08:52:58-04:00Kitware RobotCrash at unload library, unregister**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15972). Further discussion may take place here.**
---
This crash could be reporoduced on Apple (at least on the latest El Capitan sys...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15972). Further discussion may take place here.**
---
This crash could be reporoduced on Apple (at least on the latest El Capitan system) and on Windows also.
But note that on Windows you need to start the attached example in Debug mode (i.e. in Visual Studio IDE you need to use F5 key - "Start Debugging") instead of using Ctrl+F5 "Start Without Debugging".
On Linux I was not able to reproduce this crash.
In minimal example to reproduce this crash (attached) we have two C++ projects (in fact I'm using CMake projects): main executable VTKDynamicLinkingCrash and shared library VTKDynamicLinkingCrashLib.
Also, the crash could be reproduced with VTK 6.2.0, VTK 6.3.0 and VTK 7.0.0.
The VTK library should be built in shared library mode.
If you built VTK in static library mode then this crash is not reproduced.
Only shared library VTKDynamicLinkingCrashLib uses VTK library.
Main executable VTKDynamicLinkingCrash doesn't use VTK library directly.
Also, VTKDynamicLinkingCrash loads VTKDynamicLinkingCrashLib by using LoadLibrary\dlopen functions,
and unload this library respectively (FreeLibrary\dlclose).
When shared library VTKDynamicLinkingCrashLib is being unloaded it's crashing.
It seems that the problem that VTK library tries to unregister some factories which were created in some dynamic libraries which are already (too early) unloaded at the crash time.
Two classes (vtkCommonInformationKeyManager and vtkFilteringInformationKeyManager) have a similar problem.
Their ClassFinalize() method tries to deallocate some objects which were allocated in the modules which are currently unavailable.
P.S.: I'm newbie at VTK matis. What does TBD project means? Should I select another project for this crash?