Bug 37193 - Crash while switching between OpenGL window and other window
Summary: Crash while switching between OpenGL window and other window
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-14 03:48 UTC by Mathias Brodala
Modified: 2019-09-18 18:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
X.org log file (39.09 KB, text/plain)
2011-05-15 03:12 UTC, Mathias Brodala
Details
dmesg log file (46.65 KB, text/plain)
2011-05-15 03:12 UTC, Mathias Brodala
Details
kern.log (77.17 KB, text/plain)
2011-05-30 14:51 UTC, Mathias Brodala
Details

Description Mathias Brodala 2011-05-14 03:48:47 UTC
Thanks to the Unigine Heaven demo I was finally able to reliably reproduce an issue which I only experienced with Mplayer before.

Upon switching back and forth between one window where OpenGL is used and another one, quickly the whole input and output of X freezes followed by a hard restart of my system a few moments later.

Conditions to reproduce here:


1) Have the Composite extension enabled
   - the crash does not occur without the Composite extension
   - disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the crashes

2) Have rencer acceleration enabled
   - Setting RenderAccel to "Off" prevents the crashes
   - Crashes occur both with EXA as well as XAA

3) Start an application which opens an OpenGL context with a least amount of complexity wrt the graphics
   - Crash is reproducible with Mplayer using the GL video output
   - Also reproducible with the Unigine Heaven demo
   - Not reproducible with glxgears (seemingly too simple)

4) Open another application window and start switching back and forth between those two


Due to the hard restart I am currently unable to find any traces of debugging information so help for getting started on this is greatly appreciated.

I am aware that there are quite a few other reports which sound similar to this one and I thought about adding a comment on these. However, without any additional info to add, my comment wouldn’t be that much worth. Thus I am mostly hoping for help on gathering as much information as possible.

Aside from using the latest Mesa git master I am also using the latest git master of the xf86-video-ati DDX.

(I also wanted to spare you from this lengthy message in #dri-devel ;-) )
Comment 1 Mathias Brodala 2011-05-14 04:56:39 UTC
(In reply to comment #0)
>    - disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the
> crashes

This should actually read "does not prevent".
Comment 2 Alex Deucher 2011-05-14 09:28:41 UTC
Can you attach your xorg log and dmesg output?
Comment 3 Mathias Brodala 2011-05-15 03:12:32 UTC
Created attachment 46732 [details]
X.org log file
Comment 4 Mathias Brodala 2011-05-15 03:12:52 UTC
Created attachment 46733 [details]
dmesg log file
Comment 5 Mathias Brodala 2011-05-15 03:15:03 UTC
(In reply to comment #2)
> Can you attach your xorg log and dmesg output?

Here they are. I tried to make sure that everything is written to disk by running an endless loop calling "sync" but to no avail. The files contain no traces at all from a crash or the like.
Comment 6 Mathias Brodala 2011-05-25 12:09:16 UTC
Any idea how I at least could prevent the sudden reboots to be able to gather some debugging data?
Comment 7 Mathias Brodala 2011-05-30 14:51:23 UTC
Created attachment 47339 [details]
kern.log 

Here’s at least some output I was able to find in my kern.log. Missing memory space sure sounds odd but maybe this is finally something to get started on.
Comment 8 Mathias Brodala 2011-06-13 12:07:38 UTC
Still experiencing the same issues with revision 2f0b44f981d1715b62b189f465546d865b10d0f3 of mesa. Any idea what else I could do?
Comment 9 GitLab Migration User 2019-09-18 18:58:25 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/395.


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.