Crash when starting vtkRenderer

Support
1

Hello,

I am working on a program which computes a particular polynomial in
the complex plane, then uses VTK to make a colorized 2D plot of the
polynomial. My program is written in C++ and uses VTK-9.X for
visualization. I have written a custom interactor style to capture
mouse events so I can do particular things when interacting with the
plot. The program initially sets up the usual VTK rendering pipline.
I then run a loop in which the polynomial is computed. Then I start
the renderer and then the interactor. When the user interacts with
the mouse, the interactor will exit, the mouse interaction handled,
and a new polynomial is computed. The loop then runs again – starts
the renderer and the interactor and waits for the next user
interaction.

I have run my program on two computers so far. The first is an Ubuntu
system with VTK-9.1 The program runs fine there – no problem.
However, on my second computer – a workstation running VTK-9.2 – the
program crashes after the user interacts with the the image and
the renderer is started again. That is, the first image display is fine
and the crash happens after the user has interacted with it and the loop
enters its second iteration (and render is started again).

The crash happens deep within VTK and down into OpenGL. I attach a
stack trace and a system config report below.

I can’t expect you to debug my program – that’s my job. But since
this is a mysterious crash to me perhaps you can look at the stack
trace and offer a few suggestions about what kinds of failures cause
such a crash? Am I doing something wrong with the renderer – that
is, should I stop and start it upon every loop iteration? Or is
there something in the graphics setup which is misconfigured on this
workstation?

I am mystified since the image is rendered in the first loop iteration.
Also, I have successfully used VTK to make other plots in other programs
– I don’t think my system is misconfigured, but I don’t know why
else I would get a crash deep down in OpenGL.

Thank you,
Stuart Brorson

brorson@brorson-Precision-Tower-7910:~/VTKLambdaPoly/build$ gdb LambdaPoly
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 LambdaPoly…
(gdb) r
Starting program: /home/brorson/VTKLambdaPoly/build/LambdaPoly
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/x86_64-linux-gnu/libthread_db.so.1”.
Create initial image window …
Create rendering stuff …
Initialize interactor…

Computing Mandelbrot set … done!

Do rendering…
[New Thread 0x7fffeba55700 (LWP 171009)]
[New Thread 0x7fffeb254700 (LWP 171010)]
[New Thread 0x7fffeaa53700 (LWP 171011)]
[Thread 0x7fffeba55700 (LWP 171009) exited]
[New Thread 0x7fffea252700 (LWP 171012)]
[Thread 0x7fffeb254700 (LWP 171010) exited]
[New Thread 0x7fffe9a51700 (LWP 171013)]
[New Thread 0x7fffe9250700 (LWP 171014)]
[New Thread 0x7fffe8a4f700 (LWP 171015)]
[Thread 0x7fffeaa53700 (LWP 171011) exited]
[New Thread 0x7fffe824e700 (LWP 171016)]
[Thread 0x7fffea252700 (LWP 171012) exited]
[New Thread 0x7fffe7a4d700 (LWP 171017)]
[Thread 0x7fffe9a51700 (LWP 171013) exited]
[New Thread 0x7fffe724c700 (LWP 171018)]
[Thread 0x7fffe9250700 (LWP 171014) exited]
[New Thread 0x7fffe6a4b700 (LWP 171019)]
[Thread 0x7fffe8a4f700 (LWP 171015) exited]
[New Thread 0x7fffe624a700 (LWP 171020)]
[Thread 0x7fffe724c700 (LWP 171018) exited]
[Thread 0x7fffe824e700 (LWP 171016) exited]
[New Thread 0x7fffe5a49700 (LWP 171021)]
[Thread 0x7fffe7a4d700 (LWP 171017) exited]
[New Thread 0x7fffe5248700 (LWP 171022)]
[Thread 0x7fffe6a4b700 (LWP 171019) exited]
[New Thread 0x7fffe4a47700 (LWP 171023)]
[Thread 0x7fffe624a700 (LWP 171020) exited]
[Thread 0x7fffe5a49700 (LWP 171021) exited]
[Thread 0x7fffe5248700 (LWP 171022) exited]
[Thread 0x7fffe4a47700 (LWP 171023) exited]
Start interactor event loop…
MouseWheelBackward …
[i,j] = [340, 291]
Coords of event [p[0], p[1], p[2], p[3]] = [340, 291, 340, 291]
New x0 = 1.405676, y0 = -0.085142, w = 7.800000e+00, h = 7.800000e+00

Computing Mandelbrot set … done!

Do rendering…

Thread 1 “LambdaPoly” received signal SIGSEGV, Segmentation fault.
0x00007ffff0c5d395 in xcb_writev () from /lib/x86_64-linux-gnu/libxcb.so.1
(gdb) bt
#0 0x00007ffff0c5d395 in xcb_writev () from /lib/x86_64-linux-gnu/libxcb.so.1
#1 0x00007ffff175390e in _XSend () from /lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff1749c2a in XQueryExtension () from /lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff16e8ecd in ?? () from /lib/x86_64-linux-gnu/libGLX.so.0
#4 0x00007ffff16e9478 in ?? () from /lib/x86_64-linux-gnu/libGLX.so.0
#5 0x00007ffff16e2d53 in glXChooseFBConfig () from /lib/x86_64-linux-gnu/libGLX.so.0
#6 0x00007ffff7a7ed30 in vtkXOpenGLRenderWindowTryForFBConfig (DisplayId=0x55555565f580, drawable_type=1, doublebuff=1,
stereo=0, stencil=0, srgb=false) at /usr/local/src/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:167
#7 0x00007ffff7a7eded in vtkXOpenGLRenderWindowGetDesiredFBConfig (DisplayId=0x55555565f580, win_stereo=@0x55555562cbc0: 0,
win_doublebuffer=@0x55555562cb44: 1, drawable_type=1, stencil=@0x55555562cc18: 0, srgb=false)
at /usr/local/src/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:207
#8 0x00007ffff7a7f13c in vtkXOpenGLRenderWindow::GetDesiredVisualInfo (this=0x55555562cad0)
at /usr/local/src/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:261
#9 0x00007ffff7a80b6a in vtkXOpenGLRenderWindow::CreateAWindow (this=0x55555562cad0)
at /usr/local/src/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:481
#10 0x00007ffff7a8273f in vtkXOpenGLRenderWindow::WindowInitialize (this=0x55555562cad0)
at /usr/local/src/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:810
#11 0x00007ffff7a8280e in vtkXOpenGLRenderWindow::Initialize (this=0x55555562cad0)
at /usr/local/src/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:831
#12 0x00007ffff7a82be1 in vtkXOpenGLRenderWindow::Start (this=0x55555562cad0)
at /usr/local/src/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:941
#13 0x00007ffff73fa5ad in vtkRenderWindow::Render (this=0x55555562cad0)
at /usr/local/src/VTK/Rendering/Core/vtkRenderWindow.cxx:310
#14 0x00007ffff7979110 in vtkOpenGLRenderWindow::Render (this=0x55555562cad0)
at /usr/local/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx:2343
#15 0x00007ffff7a8682a in vtkXOpenGLRenderWindow::Render (this=0x55555562cad0)
at /usr/local/src/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:1598
#16 0x00005555555608bf in main (argc=1, argv=0x7fffffffe088) at /home/brorson/VTKLambdaPoly/LambdaPoly.cxx:361
(gdb)

brorson@brorson-Precision-Tower-7910:~/VTKLambdaPoly$ inxi -F
System: Host: brorson-Precision-Tower-7910 Kernel: 5.13.0-51-generic x86_64 bits: 64 Desktop: Cinnamon 4.4.8
Distro: Ubuntu 20.04.4 LTS (Focal Fossa)
Machine: Type: Desktop System: Dell product: Precision Tower 7910 v: N/A serial: <superuser/root required>
Mobo: Dell model: 0NK5PH v: A00 serial: <superuser/root required> UEFI: Dell v: A34 date: 10/19/2020
CPU: Topology: 2x Quad Core model: Intel Xeon E5-2623 v3 bits: 64 type: MT MCP SMP L2 cache: 20.0 MiB
Speed: 1200 MHz min/max: 1200/3500 MHz Core speeds (MHz): 1: 1204 2: 1198 3: 1198 4: 1198 5: 1198
6: 1198 7: 1200 8: 1198 9: 1241 10: 1199 11: 1197 12: 1198 13: 1197 14: 1197 15: 1198 16: 1198
Graphics: Device-1: NVIDIA GK208B [GeForce GT 730] driver: nvidia v: 470.129.06
Device-2: NVIDIA GK210GL [Tesla K80] driver: nvidia v: 470.129.06
Device-3: NVIDIA GK210GL [Tesla K80] driver: nvidia v: 470.129.06
Display: x11 server: X.Org 1.20.13 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
resolution: 1280x1024~60Hz
OpenGL: renderer: NVIDIA GeForce GT 730/PCIe/SSE2 v: 4.6.0 NVIDIA 470.129.06
Audio: Device-1: Intel C610/X99 series HD Audio driver: snd_hda_intel
Device-2: NVIDIA GK208 HDMI/DP Audio driver: snd_hda_intel
Sound Server: ALSA v: k5.13.0-51-generic
Network: Device-1: Intel Ethernet I217-LM driver: e1000e
IF: enp0s25 state: down mac: 48:4d:7e:f6:a7:77
Device-2: Intel I210 Gigabit Network driver: igb
IF: enp8s0 state: up speed: 100 Mbps duplex: full mac: 48:4d:7e:f6:a7:92
Drives: Local Storage: total: 465.76 GiB used: 31.68 GiB (6.8%)
ID-1: /dev/sda vendor: Seagate model: ST500DM009-2F110A size: 465.76 GiB
Partition: ID-1: / size: 456.96 GiB used: 31.68 GiB (6.9%) fs: ext4 dev: /dev/sda2
Sensors: System Temperatures: cpu: 49.0 C mobo: N/A sodimm: 26.0 C gpu: nvidia temp: 40 C
Fan Speeds (RPM): cpu: 1001 gpu: nvidia fan: 40%
Info: Processes: 434 Uptime: 13d 2h 56m Memory: 62.82 GiB used: 4.03 GiB (6.4%) Shell: bash inxi: 3.0.38
brorson@brorson-Precision-Tower-7910:~/VTKLambdaPoly$

2

Do you really mean that you restart the vtkRenderer or is it the vtkRenderWindow? It looks like that from the stack trace.

Is it really necessary to restart the renderer (renderwindow) and interactor? A more conventional approach would be to have a callback of some sort update the pipeline and re-render the window.

I’m not sure if this is the case here but initializing the window will claim graphics resources which are held until destruction. If you still hold to some resource-owning instances then re-starting a new window may lead to conflicts.

3

Thank you for the ideas.

Regarding restarting the vtkRenderer or the vtkRenderWindow, my reading of the documentation is that you start the renderer by invoking the Start() method on the renderWindow – the Start method in the renderer itself is an abstract class. Therefore, that’s what I did. But others who are more knowlegable that I can correct me if I am wrong.

Regarding callbacks, yes, I am considering that, but my understanding (again, potentially wrong) is that one can either use the standard event loop with callbacks or write a customer InteractorStyle which implements the desired mouse behaviors. I used the second method for reasons of history. Is it better to use the callback method? And why would my InteractorStyle cause the Renderer to barf?

Here’s what I am doing. The crash happens the second time renWin->Render() is called.

while(1) {
std::cout << “----------------------------------------” << std::endl;
std::cout << "Computing polynomial … " << std::flush;
computeMandelbrot(rImageData, N); // My fcn to compute the poly over the whole complex plane.
std::cout << “done!\n” << std::endl;

// Tell pipeline to update
colorComplexPlane->Modified();
imageMapper->Modified();
imageActor->Modified();
renderer->Modified();

// Start rendering thread
cout << "Start rendering thread......" << endl;  
renWin->Render();

// Start interactor event loop
cout << "Start interactor event loop......" << endl;    
iren->Start();
// If we get here it's because an event stopped the loop.    
//  Handle the captured events then loop again.

}

Thanks!

4

You should start iren only once, outside the loop. The separate Render is not necessary since the interactor will take care of that. Also all the Modified calls except the one on imageMapper are unnecessary.

See here https://kitware.github.io/vtk-examples/site/Cxx/Interaction/MouseEventsObserver/ for inspiration on how to respond to mouse events.

5

Thank you for the suggestions. I tried them out and found I get different crash behavior. That’s progress of a sort :slight_smile:

The latest code is below. When I do something with the mouse then the render window crashes, but my program continues running and captures a stream of (nonexistant) mouse events. I guess the render window thread died but the main thread lives on…

One interesting observation I made based on your comments is this: My custom interactor inherits from vtkInteractorStyleImage. This is the version which crashes. When I change the custom interactor to inherit from vtkInteractorStyleTrackball, then I get no crash – but my custom methods are not invoked. Rather, the standard Trackball interactor mouse bindings seem to be used. Not sure what’s up with that… Any thoughts? And why would the interactor determine whether the renderer crashes or not?

I will try using callbacks instead of a custom interactor.

Thanks, Stuart

vtkSmartPointer iStyle =
vtkSmartPointer::New();
iren->SetInteractorStyle(iStyle);

// Start rendering thread
cout << “Start rendering thread…” << endl;
renWin->Render();

//-------------------------------------------------------------------
while(1) {
std::cout << “----------------------------------------” << std::endl;
std::cout << "Computing polynomial … " << std::flush;
computeMandelbrot(rImageData, N); // Compute the whole set.
std::cout << “done!\n” << std::endl;

// Tell pipeline to update
colorComplexPlane->Modified();  // Image won't update without this.
imageMapper->Modified();
//imageActor->Modified();
//renderer->Modified();

// Start interactor event loop
cout << "Start interactor event loop......" << endl;    
iren->Start();
// If we get here it's because an event stopped the loop.
// Process pending events.

}

6

Hello again.

Thank you for your suggestions regarding my crash problem. I have fixed the problem.

My old program would start the event loop, then when the user caused a mouse event, the program would exit the loop, handle the event (in this case, recompute a result), then loop back and restart the event loop – which would call render and crash.

Based on your suggestions, I now start the event loop and leave it running. Then, when the user causes a mouse event, the callbacks call the thing which recomputes the result and then re-renders the image. I will guess this is how VTK is supposed to work.

Now that my program is working, please allow me to show it off. The working program is a CUDA-based Mandelbrot set explorer using VTK for visualization. I put it up on GitHub for public enjoyment here:

Hopefully, it shows off the correct way to use VTK to recompute and update an image as the user interacts with it.

Thanks,
Stuart Brorson