Bug 37193 - Crash while switching between OpenGL window and other window
Summary: Crash while switching between OpenGL window and other window
Status: NEW
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: 2011-06-13 12:07 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

Note You need to log in before you can comment on or make changes to this bug.
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?


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.