gnome-shell crashes when resizing OpenGL window

Bug #911591 reported by Victor Zamanian on 2012-01-04
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gnome-shell (Ubuntu)

Bug Description

I have a couple of applications that I wrote myself. They are OpenGL graphics applications. One application uses SDL for OpenGL context management, and the other uses GLFW.

When I resize the windows of these applications by dragging the window edges, gnome-shell crashes almost 100 % of the time after a certain amount of resizing back and forth. This does not happen when instantly resizing the window (e.g. with Alt+F10, which effectively does a resize as far as SDL and GLFW are concerned anyway).

Rapidly resizing the window of glxgears does not seem to crash gnome-shell, which confuses me. I guess it is interacting with things differently or something.

Anyways, I'm using the following versions of involved software packages:

gnome-shell: 3.2.1-0ubuntu1.1
nvidia-current: 290.10-0ubuntu1~oneiric~xup1 (from the ubuntu-x-swat PPA)
SDL: 1.2.14-6.1ubuntu4
GLFW: 2.7.2-1

I'm thinking that maybe the two libraries I use (SDL and GLFW) create new OpenGL contexts every time when using their respective resizing mechanisms, whereas glxgears does something different, and requesting new contexts with new sizes too often during a small period of time might not go too well? Not sure at all what details I can provide regarding this problem. Hopefully someone can ask the right questions and I will be able to provide the necessary information.

I will be very lucky if the applications were started from a terminal. That way the undecorated window of the terminal has focus after the crash, and I can relaunch gnome-shell from there.

Any help is appreciated!

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gnome-shell 3.2.1-0ubuntu1.1
ProcVersionSignature: Ubuntu 3.0.0-15.24-generic 3.0.13
Uname: Linux 3.0.0-15-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Wed Jan 4 04:19:48 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

Victor Zamanian (victorz) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-shell (Ubuntu):
status: New → Confirmed
dino99 (9d9) wrote :

EOL reached for that serie

Changed in gnome-shell (Ubuntu):
status: Confirmed → Invalid
James Cuzella (trinitronx) wrote :

I can confirm this bug is still happening on:

Ubuntu 17.10 (Artful Aardvark)
gnome-shell 3.26.1-0ubuntu5

Changed in gnome-shell (Ubuntu):
status: Invalid → Confirmed
James Cuzella (trinitronx) wrote :

As original reporter stated, it usually appears related to OpenGL window resize events. I have also noted that xrandr display resolution changes can trigger the crash.

I see errors in dmesg that mention libmutter:

[15040.472843] gnome-shell[32127]: segfault at 8 ip 00007f327f29d5d0 sp 00007ffeccf94a38 error 4 in[7f327f243000+142000]

James Cuzella (trinitronx) wrote :

Bug seems to be reported also elsewhere:

- ArchLinux:
- RedHat:

The RHEL bug report mentions that they have Xorg configured without RandR support. I do see a message in my logs that says gdm has RandR disabled for some reason:

    Nov 30 15:25:53 saturn /usr/lib/gdm3/gdm-x-session[3918]: (--) RandR disabled

I'm not sure why gdm wants to run with it disabled. I don't seem to have a /etc/X11/xorg.conf file anymore... it's been quite some time since I've even had to edit Xorg config in recent Ubuntu versions. Seems like all this is managed by gdm-x-session now?

James Cuzella (trinitronx) wrote :

Adding journalctl logs for gnome-shell crash. After segfault line, gnome-shell crashes and I'm returned to gdm login screen. Once I login, everything works again until next crash, usually caused by OpenGL window resizing or xrandr resolution changes.

James Cuzella (trinitronx) wrote :

At first glance, bug may be related to this upstream:

dino99 (9d9) wrote :


Please, dont revive a deadly report, its useless and spamming the report with different data. That is not the best way to catch dev attention.
As you can see, that report have not got a single dev question or answer; do you mind why ?

If you still have that problem, then confirm it still exist on a fresh recent install (not on a system that got many dist-upgrades, and polluted with old borked settings. As you are using a nvidia driver, either follow the #8 link's comment about adding nvidia parameters in such a case, or confirm when using 'nouveau' instead. In both cases, install the dev packages to get a usefull report using ubuntu-bug.

Changed in gnome-shell (Ubuntu):
status: Confirmed → Invalid
James Cuzella (trinitronx) wrote :


Happy to open a new bug report on this, as it still appears to be an issue in latest Ubuntu 17.10. Usually when reporting bugs, I opt to prefer adding information to an existing bug report that I have high confidence describes the problem I am seeing. I believe this helps to reduce creating many duplicates and to focus community effort on resolving the main underlying problem rather than bug report management overhead from many duplicates or "me too" comments with no helpful debug info. If this is not preferred on this project, or for some reason doesn't fit the developer bug triage process here, that's fine. I'm happy to add information upstream or in another LaunchPad bug.

Back to this problem:

As it is a segfault reported in upstream gnome-shell which has something to do with OpenGL + resize behavior, I don't believe borked settings are the issue, nothing I've seen yet points towards that, although it'd be nice if the problem could be resolved by a config change instead of code change. This system never had any gnome-shell installed because Unity was there instead. Therefore, no pre-existing gnome-shell configuration can be hanging around. I've posted to upstream bug, but some info was here.

To clarify: I do not have an Nvidia optimus nor do I use noveau, but use older nvidia-340 binary drivers. This is the nvidia recommended set of drivers for my card. Another comment in the upstream report mentions the issue may not have as much to do with Nvidia as it does with Xrandr fast video mode changes. I have confirmed this behavior in my own testing, and have a reproduction test case that works pretty reliably for me:

Reproduction Command:

# Use output and modes that are valid for you...
xrandr --output HDMI-0 --mode 1920x1080 ; xrandr --output HDMI-0 --mode 1920x1080 ; xrandr --output HDMI-0 --mode 800x600 ; xrandr --output HDMI-0 --mode 1920x1080

I've tested this a couple times and it looks like I am able to trigger the crash just with fast xrandr commands.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.