Seg faults on Render() call

Development
1

I’m getting seg fault in my Ubuntu system:

vtk version       : 9.2.2
python version    : 3.9.13 (main, Aug 25 2022, 23:26:10) [GCC 11.2.0]
python interpreter: /home/musy/soft/anaconda3/bin/python
system            : Linux 5.4.0-131-generic posix x86_64

with

import vtk
import time

cone = vtk.vtkConeSource()

mapper = vtk.vtkPolyDataMapper()
mapper.SetInputConnection(cone.GetOutputPort())

actor = vtk.vtkActor()
actor.SetMapper(mapper)

ren = vtk.vtkRenderer()
ren.SetBackground(0.1, 0.2, 0.4)
ren.AddActor(actor)

renwin = vtk.vtkRenderWindow()
renwin.SetSize(500, 500)
renwin.AddRenderer(ren)

iren = vtk.vtkRenderWindowInteractor()
iren.SetRenderWindow(renwin)

# renwin.Render()
# iren.Initialize()
iren.Start()

print("sleep")
time.sleep(1)
print("slept")

iren.Render()  # Segmentation fault (core dumped)
iren.Start()   # is always ignored

VTK 9.0.3 the same works fine as expected.

2

I can also confirm that this regression did not exist in VTK 9.1.0, but it does exist in the VTK master branch.

Here’s a partial stack trace from where the vtkXOpenGLRenderWindow is attempting to create a new X Window to replace the one that had previously been destroyed:

10      vtk9::vtkXOpenGLRenderWindow::CreateAWindow() + 220
9       vtk9::vtkXOpenGLRenderWindow::GetDesiredVisualInfo() + 99
8       lib/libvtkRenderingOpenGL2-9.2.so.1(+0x1d29b9)
7       lib/libvtkRenderingOpenGL2-9.2.so.1(+0x1d2924)
6       glXChooseFBConfig + 35

My guess would be an invalid DisplayId when glXChooseFBConfig() is called.

3

The test program doesn’t crash if I revert 7ce7fd78f6. I think the Finalize() method will need to be fixed, which is strange because it already clears the DisplayId like it should. Maybe there are other variables that it also needs to clear so that CreateAWindow() can safely be called. @mwestphal

Edit: I think I see the problem. The DisplayId is cleared in the interactor, but the DisplayId of the window is not cleared (dangling pointer).

4

I created the following patch which seems to fix the regression: !9686.

@marcomusy you can work around this problem by adding the following line after each iren.Start():

iren.GetRenderWindow().SetDisplayId("_0_p_void")

This will manually clear the DisplayId that VTK should have been clearing automatically.

1 Like
5

Thanks for the quick fix! It doesn’t crash anymore but still the second Start() is ingnored:

import vtk

cone = vtk.vtkConeSource()

mapper = vtk.vtkPolyDataMapper()
mapper.SetInputConnection(cone.GetOutputPort())

actor = vtk.vtkActor()
actor.SetMapper(mapper)

ren = vtk.vtkRenderer()
ren.AddActor(actor)

renwin = vtk.vtkRenderWindow()
renwin.AddRenderer(ren)

iren = vtk.vtkRenderWindowInteractor()
iren.SetRenderWindow(renwin)

iren.Start()
iren.GetRenderWindow().SetDisplayId("_0_p_void")

iren.Render()
iren.Start()   # ignored
iren.GetRenderWindow().SetDisplayId("_0_p_void")
6

The vtkXRenderWindowInteractor::Finalize() method apparently puts the interactor into an unusable state. This should be easy to fix in the VTK codebase.

In the meantime, I think that your only option is to create a new interactor:

 iren.Start()
 iren.GetRenderWindow().SetDisplayId("_0_p_void")

+iren = vtk.vtkRenderWindowInteractor()
+iren.SetRenderWindow(renwin)
 iren.Render()
 iren.Start()
1 Like