We have a program using Qt and VTK that runs on both Windows and Linux, and which I am now trying to get running on Mac OS. I have managed to get it to build and run there, but when loading a dataset (which triggers showing a few QT+vtk windows), the application crashes, typically in vtkTextureObject.cxx, line 440, in vtkTextureObject::Bind(), with signal SIGABRT because assert(this->Handle) fails.
Two or three times out of ten or so, it instead failed in vtkOpenGLVertexArrayObject.cxx, line 101 with EXC_BAD_ACCESS.
On the first errors, I so far only found a mailing list entry with no conclusive solution so far (http://vtk.1045678.n5.nabble.com/vtkTextureObject-bind-error-td5744068i20.html).
I could not reproduce the problem with a very simple VTK program: https://lorensen.github.io/VTKExamples/site/Cxx/GeometricObjects/CylinderExample/ works.
As a side note, when trying if this problem due to the qt/vtk integration, I came across this: https://gitlab.kitware.com/vtk/vtk/-/tree/master/Examples/GUI/Qt/ImageViewer,
but I couldn’t get it to run since (1) the CMakeLists.txt is written only for VTK >= 9 and (2) it is missing a QVTKRenderWidget.h which is contained neither in the example nor in VTK as far as I could see (maybe it’s part of vtk 9?).
I will try finding other simple examples to find a minimum example reproducing this problem.
I am hoping maybe someone here could provide some guidance where this error might come from! Thanks in advance for your help!
Mysterious crashes involving 3D rendering are usually caused by an outdated graphics card driver. Less common is the case of an old or low-end graphics hardware if you don’t use defensive programming (e.g. prior testing of available OpenGL features, etc.).
But, as you said the simple example worked, I’d suspect of the size of the texture. Have you tried your own program with a small texture (e.g. 100 x 100 pixels)? It is possible that you’re running out of texture memory. Graphics card memory is generally a limited resource, unless on those high-end cards costing thousands of dollars.
Sorry for the long delay, no time until now…
Mysterious crashes involving 3D rendering are usually caused by an outdated graphics card driver.
Potentially could be a driver issue, I guess; I’ll try checking this… any hints? Tried running ParaView, this works, so I suppose this indicates this to be not a driver issue but an implementation issue on our side?
But, as you said the simple example worked, I’d suspect of the size of the texture. Have you tried your own program with a small texture (e.g. 100 x 100 pixels)?
This was actually not using textures, but volume rendering.
I did a bit more of experimentation. Tried switching to VTK 9.0.1, no change - except that now it always seems to crash in
vtkOpenGLVertexArrayObject::Private::Initialize, line 100 (where
glGenVertexArray is called). The console output says:
**vtkOpenGLFramebufferObj:356 ERR| vtkOpenGLFramebufferObject (0x60000303b8d0): failed at glGenFramebuffers 1 OpenGL errors detected**
**0 : (1280) Invalid enum**
From what I can tell from the call stack, the problem appears somewhere in
QVTKOpenGLNativeWidget::event, as a reaction to the Widget containing that QVTKOpenGLNativeWidget being shown.
What is your Qt version?
When I first reported, I used Qt 5.14.2, now I’m on 5.15.0
I just saw this post: Fail to use vtk on mac 10.15
failed at glGenFramebuffers VTK error seems to always appear on Mac OS (i.e. unrelated to the specific issue of my EXC_BAD_ACCESS
It doesn’t seem old. But I’d guess at something trying to make, for example, OpenGL 3 operations in an OpenGL 2 context. Please, make sure your graphics card is up-to-date. The fact that ParaView works doesn’t mean your driver is ok for your program. What backend did you configure when you compiled VTK?
The EXC_BAD_ACCESS is fixed, it was actually the problem hinted at here: Fail to use vtk on mac 10.15
QSurfaceFormat::setDefaultFormat(QVTKOpenGLNativeWidget::defaultFormat()); mentioned in QVTKOpenGLNativeWidget.h fixed it.
Now, I’ve got still another problem though - the QVTKOpenGLNativeWidgets don’t yet show what they are supposed to show; they show a copy of some other parts of the screen…