Bug 91687

Summary:	Crash when creating new context after destroying the old one using indirect rendering
Product:	Mesa	Reporter:	Guilherme <gqmelo>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED MOVED	QA Contact:	mesa-dev
Severity:	critical
Priority:	medium	CC:	mforce2
Version:	10.5
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
See Also:	https://bugs.kde.org/show_bug.cgi?id=353763
Whiteboard:
i915 platform:		i915 features:
Attachments:	VTK/Qt Python program that crashes gdb stack trace xtrace with glx commands

Description Guilherme 2015-08-19 14:27:49 UTC

Created attachment 117783 [details]
VTK/Qt Python program that crashes

I tested that on mesa Ubuntu 14.04 (mesa 10.3.2) and 15.10 (mesa 10.5.2). I'm not sure if it is reproducible. The attached traces were gotten on Ubuntu 14.04.

The crash happens when running the attached python program crash_mesa_vtk_qt.py using indirect rendering (specifically I need to run it inside a chroot that has a very old mesa version)

It uses vtk and Qt, I'm sorry I could not come up with a more isolated example, but I'm not very familiar with opengl programming.


In summary, that is what is happening:

1 - A vtk render window is created and rendered the first time (that makes vtk create a new glx context)

2 - The vtk render window is set to render offscreen (it is not using OSMesa). That makes vtk destroy the current context and create a new one associated to a new X offscreen window.

3 - The window is rendered and I could even generate a png file.

4 - The vtk render window is set to render on screen again. That makes vtk destroy the current glx context and create a new one associated to the first X window (the on screen window).

5 - When rendering the vtk window again, X server crashes (stack trace attached).


Looking into vtk code it does not seem it is doing anything wrong. The offscreen related code can be found on:

https://gitlab.kitware.com/vtk/vtk/blob/v6.2.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx#L800

https://gitlab.kitware.com/vtk/vtk/blob/v6.2.0/Rendering/OpenGL/vtkOpenGLRenderWindow.cxx#L1856

https://gitlab.kitware.com/vtk/vtk/blob/v6.2.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx#L943

https://gitlab.kitware.com/vtk/vtk/blob/v6.2.0/Rendering/OpenGL/vtkOpenGLRenderWindow.cxx#L1856

Comment 1 Guilherme 2015-08-19 14:28:45 UTC

Created attachment 117784 [details]
gdb stack trace

Comment 2 Guilherme 2015-08-19 14:29:30 UTC

Created attachment 117785 [details]
xtrace with glx commands

Comment 3 Guilherme 2015-08-19 14:34:59 UTC

As the crash is a seg fault on update_framebuffer_size because surface=NULL, I tried to just make a check if the surface is NULL. Then it does not crash anywhere else, but nothing is rendered.

Comment 4 Jon Burgess 2015-11-02 15:31:57 UTC

Several similar crashes have been reported in KDE due to update_framebuffer_size() being called with surface=NULL during a call to st_Clear().

Comment 5 Marius Cirsta 2016-05-18 20:23:59 UTC

 Happened to me with KDE too.

Thread 1 (Thread 0x7f9b04e05800 (LWP 1082)):
[KCrash Handler]
#6  0x00007f9aea533a09 in update_framebuffer_state () from /usr/lib/dri/r600_dri.so
#7  0x00007f9aea53282c in st_validate_state () from /usr/lib/dri/r600_dri.so
#8  0x00007f9aea53a5d1 in st_Clear () from /usr/lib/dri/r600_dri.so
#9  0x00007f9b14f8b156 in QSGBatchRenderer::Renderer::renderBatches() () from /usr/lib/libQt5Quick.so.5

Comment 6 Timothy Arceri 2019-05-08 04:01:59 UTC

Is this working for you with recent Mesa? I was unable to figure out the examples dependences on my distro so couldn't test.

Comment 7 GitLab Migration User 2019-09-18 20:24:10 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/991.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.