Seg fault in Rendering/OpenGL2/vtkOpenGLTexture.cxx 8.2.0

Development
1

I’d been chasing a seg fault for some months now, trying to come up with a small reproducible test, but haven’t been able to trim it down to less that 100Ks of lines of code. I passed it off to a colleague who was looking for something interesting to do, and he isolated it to this change by @ken-martin in commit 8a9fd38fa03e449c91cff04de4886043e86c5e8f, the diff looks like this:

@@ -173,7 +173,7 @@ void vtkOpenGLTexture::Load(vtkRenderer *ren)
         inputTime > this->LoadTime.GetMTime() ||
         (this->GetLookupTable() && this->GetLookupTable()->GetMTime () >
          this->LoadTime.GetMTime()) ||
-         renWin != this->RenderWindow.GetPointer() ||
+         renWin->GetGenericContext() != this->RenderWindow->GetGenericContext() ||
          renWin->GetContextCreationTime() > this->LoadTime)
     {

And it turns out the set fault occurs when this-RenderWindow is null (and we’ve only seen it occur at the site of the first of the two changes in this commit).

My fix, which fixes all of our failing test cases, is as follows.

if (this->GetMTime() > this->LoadTime.GetMTime() ||
    inputTime > this->LoadTime.GetMTime() ||
    (this->GetLookupTable() && this->GetLookupTable()->GetMTime () >
     this->LoadTime.GetMTime()) ||
     this->RenderWindow == nullptr ||    // My new clause.
     renWin->GetGenericContext() != this->RenderWindow->GetGenericContext() ||
     renWin->GetContextCreationTime() > this->LoadTime)
{

Could one of you core devs give it a glance and either bless or curse it?

Thanks,
Eric

2

Would your issue involve multiple render windows by any chance? I ask because I ended up making that fix, and then removed it as I felt this https://gitlab.kitware.com/vtk/vtk/merge_requests/5902#26b3b0f0e61f2704f94bd87143464f886477d851 was the real fix. But you could be hitting some other case.

3

Also along with this fix here https://gitlab.kitware.com/vtk/vtk/merge_requests/5984 which is also texture related

4

Basically the symptom you are seeing should be the result of a render window being deleted without freeing it’s texture resources. That shouldn’t happen, but it did for you and it did for me :slight_smile: We should probably instead stick a test in the beginning of Load() to make sure RenderWindow is set and if it isn’t report an error (and return) because something bad happened.

5

Yes, indeed, all of our tests that were crashing involved at least two render windows. I’ll see if we can get your subsequent fixes in and try out the problematic tests, I’ll let you know.

6

Well, I just grabbed HEAD and built that, it still gets to the same seg fault condition. So, back to the drawing board, trying to find how it actually gets in such a state… For the time being, I’m just going to hack in that nullptr check in 8.2 and see if we can upgrade from our current 8.1.2 installation, but I’ll try to get some time to characterize how we’re bypassing the texture management code so effectively.

7

I’ll whip up a MR with a check for nullptr so it gets caught more gracefully.

8

See https://gitlab.kitware.com/vtk/vtk/merge_requests/6033