After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788666 - Gnome 3.26 with Xorg backend crashes when I close a maximized app
Gnome 3.26 with Xorg backend crashes when I close a maximized app
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.26.x
Other Linux
: Normal critical
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 788729 789242 789593 789802 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-10-08 13:35 UTC by Kateryna
Modified: 2021-07-05 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
crash log (3.54 KB, text/plain)
2017-10-08 13:35 UTC, Kateryna
  Details
stack trace after closing Liferea (1.92 KB, text/plain)
2017-10-08 17:01 UTC, Stanislav
  Details
bt of crash (22.79 KB, text/plain)
2017-10-08 17:22 UTC, Jonni Westphalen
  Details
bt of crash when closing maximized window (9.80 KB, application/octet-stream)
2017-10-09 13:10 UTC, Térence Clastres
  Details
patch to fix the problem (951 bytes, patch)
2017-10-09 14:23 UTC, Jonni Westphalen
committed Details | Review

Description Kateryna 2017-10-08 13:35:15 UTC
Created attachment 361130 [details]
crash log

The bug was reported by many people for last couple days at Arch Linux forum: 
https://bbs.archlinux.org/viewtopic.php?id=230619

When closing maximized window of any GTK app gnome-shell crashes and restarts.
The crash log is attached.

Packages versions:
gnome-shell 3.26.1-1
xorg-server 1.19.4-1

I was able to reproduce the bug many times with Evolution, Nautilus, Liferea with modesetting Xorg video driver.

Hardware: Intel Ivybridge Mobile; kernel modules: i915, nouveau (discrete video card).
Comment 1 Florian Müllner 2017-10-08 13:42:35 UTC
Unfortunately the log is not very helpful without debug symbols. Please compile gtk3, mutter and gnome-shell with debug symbols and reproduce the crash.
Comment 2 Kateryna 2017-10-08 14:01:23 UTC
(In reply to Florian Müllner from comment #1)
> Unfortunately the log is not very helpful without debug symbols. Please
> compile gtk3, mutter and gnome-shell with debug symbols and reproduce the
> crash.

Unfortunately Arch Linux doesn't provide symbols and re-building may take a while. Could anyone of your team try to reproduce the issue in the meantime?

From my experience the crash may happen from the 2nd attempt, rarely from the 3rd attempt.
Comment 3 Térence Clastres 2017-10-08 14:46:08 UTC
Florian Müllner: I'm on the same system as @Kateryna and I will post logs with debug mode enabled soon.
Comment 4 Stanislav 2017-10-08 17:01:27 UTC
Created attachment 361141 [details]
stack trace after closing Liferea

Stack trace with symbols after closing maximized Liferea window and gnome-shell crash
Comment 5 Stanislav 2017-10-08 17:05:18 UTC
Stack trace in attachment 361141 [details] was created after re-building and re-installing these Arch Linux packages, one-by-one:

gtk3 3.22.24-1
mutter 3.26.1-1
gnome-shell 3.26.1-1

Please let me know if that's helpful.
Comment 6 Jonni Westphalen 2017-10-08 17:22:17 UTC
Created attachment 361142 [details]
bt of crash
Comment 7 Cédric Bellegarde 2017-10-09 08:38:38 UTC
Do you have an idea to reproduce the issue? Happened to me one time on ArchLinux. But here on F27, I am unable to reproduce the issue and so unable to get a full backtrace (with all symbols).
Comment 8 Cédric Bellegarde 2017-10-09 08:55:56 UTC
Ok, looks like an issue in mutter/gnome-shell 3.26.1.

Downgrading to 3.26.0 fixes the issue here. It would explain why I'm not unable to reproduce on Fedora 27 (3.26.0).
Comment 9 foss.freedom 2017-10-09 09:24:46 UTC
note - if you turnoff animations via Tweaks, then crashing whilst maximised/tiled does not occur (or at least much harder to invoke a crash) 

Ubuntu 17.10 beta2 - + all updates since - mutter 3.26.1
Comment 10 Stanislav 2017-10-09 10:27:32 UTC
(In reply to foss.freedom from comment #9)

Have animations always turned off on my two computers - the crash happens often enough to be very annoying.
Comment 11 lei.pero 2017-10-09 11:36:27 UTC
It's mutter problem, commit 43eeb009ce78588db9fba48574f377629d5de1aa introduces the bug. Simply reverting that commit (and the one that follows sicne it's fix for this one) solves the problem.
Comment 12 foss.freedom 2017-10-09 11:46:00 UTC
(In reply to lei.pero from comment #11)
> It's mutter problem, commit 43eeb009ce78588db9fba48574f377629d5de1aa
> introduces the bug. Simply reverting that commit (and the one that follows
> sicne it's fix for this one) solves the problem.

link is wrong - do you mean this commit? https://git.gnome.org/browse/mutter/commit/?id=43eeb009ce78588db9fba48574f377629d5de1aa
Comment 13 lei.pero 2017-10-09 13:05:21 UTC
Yeah, but it isn't that one anyway, I'm sorry I mixed them up...

It's this one:
https://git.gnome.org/browse/mutter/commit/?id=e198c8452bb2e3b711645fdb106b5f8b8fe16dfc
Comment 14 Térence Clastres 2017-10-09 13:10:16 UTC
Created attachment 361183 [details]
bt of crash when closing maximized window

Steps to reproduce:
 -Maximize any window
 -Close it

Expected behavior:
 -Window exits normally

What happens:
 -Gnome-Shell crashes due to an X Window System error: ''BadWindow (invalid Window parameter)'
Comment 15 Ben Daines 2017-10-09 13:37:36 UTC
(In reply to lei.pero from comment #13)
> Yeah, but it isn't that one anyway, I'm sorry I mixed them up...
> 
> It's this one:
> https://git.gnome.org/browse/mutter/commit/
> ?id=e198c8452bb2e3b711645fdb106b5f8b8fe16dfc

Can confirm the issue is within this commit.
Comment 16 Stanislav 2017-10-09 14:05:57 UTC
Today I've noticed similar system log messages caused by gnome-shell crashes on x11 backend. However the actions were not related to closing any windows.

In total gnome-shell crashed twice for me today and user actions were not the same as described here.

Sorry for off-topic post, but I have a feeling that additional testing for Gnome on x11 backend is required.
Comment 17 Jonni Westphalen 2017-10-09 14:23:47 UTC
Created attachment 361191 [details] [review]
patch to fix the problem

This patch should fix the problem.
Comment 18 Ikey Doherty 2017-10-09 14:27:10 UTC
*stops uploading identical patch*
Comment 19 Ben Daines 2017-10-09 14:30:57 UTC
(In reply to jonny.westphalen from comment #17)
> Created attachment 361191 [details] [review] [review]
> patch to fix the problem
> 
> This patch should fix the problem.

Seems to work here.
Comment 20 Ikey Doherty 2017-10-09 14:33:51 UTC
FWIW we've also done the same thing in Solus, came up with the same patch, but can confirm that it fixes the crashes:

https://dev.solus-project.com/R2123:f132583f030dff10af30d43ca555b091c4ffe14d

So +1 to the proposed patch from our testing.
Comment 21 lei.pero 2017-10-09 14:45:49 UTC
(In reply to jonny.westphalen from comment #17)
> Created attachment 361191 [details] [review] [review]
> patch to fix the problem
> 
> This patch should fix the problem.

Can confirm, works well so far, and animations are no longer random, they work every time it seems.
Comment 22 Joshua Strobl 2017-10-09 14:49:38 UTC
Can confirm this resolving issue (using update in Solus) in GNOME Shell. +1 for patch.
Comment 23 alex diavatis 2017-10-09 15:55:52 UTC
in Solus and Budgie (Mutter) at least this patch gives a different issue. if you try tile windows with headerbars in unscientific space, the app will crash

to reproduce
1. Open GNOME Terminal
2. Tile it on 1/2
3. Resize it on a big area. eg 8/9
4. Open GNOME MPV (or any other app with headerbars)
5. Try to tile it on the remaining 1/9

Output: GNOME MPV will crash
Expected Behavior: GNOME MPV should scale to 1/2 (or not scale at all?)

if you set GNOME MPV to use classic titlebars (from options) and repeat the steps above, the GNOME MPV wont crash, it wont just scale
Comment 24 alex diavatis 2017-10-09 16:01:31 UTC
unsc(In reply to alex diavatis from comment #23)
> in Solus and Budgie (Mutter) at least this patch gives a different issue. if
> you try tile windows with headerbars in unscientific space, the app will
> crash
> 


by "unscientific" i meant insufficient!

also i can reproduce the same with Chrome custom decoration (crashes) and Chrome GTK decorations (not crashing)

sorry for testing on Budgie, but cant test on Shell right now!
Comment 25 Ikey Doherty 2017-10-09 16:09:58 UTC
I don't believe the issue you're seeing is related to this Mutter patch, alex.
I actually think its a similar regression within GTK itself.
Comment 26 lei.pero 2017-10-09 16:13:33 UTC
(In reply to alex diavatis from comment #23)
> in Solus and Budgie (Mutter) at least this patch gives a different issue. if
> you try tile windows with headerbars in unscientific space, the app will
> crash
> 
> to reproduce
> 1. Open GNOME Terminal
> 2. Tile it on 1/2
> 3. Resize it on a big area. eg 8/9
> 4. Open GNOME MPV (or any other app with headerbars)
> 5. Try to tile it on the remaining 1/9
> 
> Output: GNOME MPV will crash
> Expected Behavior: GNOME MPV should scale to 1/2 (or not scale at all?)
> 
> if you set GNOME MPV to use classic titlebars (from options) and repeat the
> steps above, the GNOME MPV wont crash, it wont just scale

U can't reproduce that on Gnome-Shell, it looks like issue with GNOME-MPV, if i try to do that with gedit it goes into 1/2 screen mode, GNOME-MPV just do not resize at all, but does not crash.
Comment 27 alex diavatis 2017-10-09 16:27:57 UTC
(In reply to lei.pero from comment #26)
> (In reply to alex diavatis from comment #23)

> U can't reproduce that on Gnome-Shell, it looks like issue with GNOME-MPV,
> if i try to do that with gedit it goes into 1/2 screen mode, GNOME-MPV just
> do not resize at all, but does not crash.

thats correct. i just built Shell/Mutter and i tried (Xorg) with/out this patch. the apps dont't crash, but they doesn't resize either. which was the same behavior before that patch anyway

so my previous comment only affects Budgie
Comment 28 Carlos Garnacho 2017-10-09 18:59:24 UTC
Comment on attachment 361191 [details] [review]
patch to fix the problem

Patch looks correct, but I do miss some explanation on the commit log, after having needed to read the full bug to find a relation between the patch and the provided backtraces.

I can take care of that though.
Comment 29 Henry Snow 2017-10-09 21:15:29 UTC
*** Bug 788729 has been marked as a duplicate of this bug. ***
Comment 30 Florian Müllner 2017-10-09 21:50:04 UTC
(In reply to Carlos Garnacho from comment #28)
> Comment on attachment 361191 [details] [review] [review]
> patch to fix the problem
> 
> Patch looks correct

Error trapping looks like a good idea there, but if we are reproducably triggering the error in a particular situation, then we should also avoid the call instead of relying on the error handling to catch it IMHO
Comment 31 Carlos Garnacho 2017-10-09 22:20:53 UTC
Ah, I had the impression it was intermittent, thus could well lie around mutter changing properties on a window that's on its way to being destroyed.
Comment 32 Carlos Garnacho 2017-10-10 12:04:47 UTC
Changed commit log and pushed. Will leave open in case fmuellner thinks there's
more investigation required, but it seems that set_wm_state() (which calls into update_gtk_edge_constraints) also does set up traps around XChangeProperty
calls, so it seems inherent to the times this function may be called.
Comment 33 Carlos Garnacho 2017-10-10 12:06:42 UTC
Comment on attachment 361191 [details] [review]
patch to fix the problem

git-bz failed on me. Pushed as commit f9c625924.
Comment 34 Térence Clastres 2017-10-10 12:10:38 UTC
@Carlos Garnacho thank you for the push.
Just a detail: the commit link redirects to gnome-shell git instead of mutter.
Comment 35 Daniel Boles 2017-10-10 12:25:13 UTC
It will, for as long as the product is gnome-shell; the link is generated based on the product.

If there's nothing left to do, this could be closed while moving it to mutter so that the link will work for future readers.
Comment 36 Térence Clastres 2017-10-10 12:43:22 UTC
Daniel Boles: Agree.
Comment 37 Zfkerr 2017-10-12 10:39:06 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=788650
This bug report appeared later than I created my own, so it is a duplicate of my report bug which is about the same problem that has already been solved and therefore closed. Therefore, I think that this bug report should also be closed. What do you think about this? Should you close the bug if the problem is solved?
Comment 38 Daniel Boles 2017-10-12 10:56:07 UTC
I figured we were keeping it open for Florian to confirm this:

(In reply to Carlos Garnacho from comment #32)
> Changed commit log and pushed. Will leave open in case fmuellner thinks
> there's
> more investigation required, but it seems that set_wm_state() (which calls
> into update_gtk_edge_constraints) also does set up traps around
> XChangeProperty
> calls, so it seems inherent to the times this function may be called.
Comment 39 Zfkerr 2017-10-12 11:07:43 UTC
(In reply to Daniel Boles from comment #38)
> I figured we were keeping it open for Florian to confirm this:
> 
> (In reply to Carlos Garnacho from comment #32)
> > Changed commit log and pushed. Will leave open in case fmuellner thinks
> > there's
> > more investigation required, but it seems that set_wm_state() (which calls
> > into update_gtk_edge_constraints) also does set up traps around
> > XChangeProperty
> > calls, so it seems inherent to the times this function may be called.

https://bugzilla.gnome.org/show_bug.cgi?id=123861

Sometimes it happens that some people after the bug was fixed is not reported about it. For example, you still have opened bug reports created in 2004 for GNOME2. Will these bug reports ever be closed?

https://bugzilla.gnome.org/buglist.cgi?bug_status=__open__&content=gnome%20shell&list_id=254930&order=changeddate%2Cpriority%2Cbug_severity&query_based_on=&query_format=specific
Comment 40 Daniel Boles 2017-10-12 11:09:19 UTC
I have no idea why you're asking me or what completely different bug reports have to do with this. Please stay on-topic.

If you want old bug reports to be closed, you could always roll your sleeves up and help the community to triage them.
Comment 41 Daniel Boles 2017-10-12 11:10:53 UTC
...apologies, I just realised that you specifically meant for obsolete products.

In which case, that's a good point. Ideally a sysadmin could write a script that would automatically close all such objectively obsolete bugs.

But then, whether automatic or manual, that still requires someone finding time to close them all ;)
Comment 42 Zfkerr 2017-10-12 11:51:20 UTC
(In reply to Daniel Boles from comment #40)
> I have no idea why you're asking me or what completely different bug reports
> have to do with this. Please stay on-topic.
> 
> If you want old bug reports to be closed, you could always roll your sleeves
> up and help the community to triage them.

I'm sorry, but I did not mean to reproach you for anything. I hope that you will understand me correctly that I did not want to offend anyone. You misunderstood what I wanted to say. In fact, the bug described in this bug report has already been resolved. But, the creator of this bug report may not tell you that this bug is already solved.

I just gave an example to say that some bug reports remain open despite the fact that it have long been factually have been resolved or even completely ceased to be relevant. But, they remain open only because those who reported those bugs simply did not report that the problem had already been solved and most likely would never already report about it. Still open bug reports created in 2004 for GNOME2 have clearly ceased to be relevant because GNOME2 has long ceased to exist, because now the current GNOME version is GNOME3. Therefore, it will not be possible to fix this. But, despite this, those bug reports are still open. And it can happen that this bug report will also never be closed, despite the fact that in fact this bug has already been resolved.
Comment 43 Daniel Boles 2017-10-12 12:11:55 UTC
No problem - it's me who needed to apologise for not fully reading/understanding your original message!

You're totally right that old bugs pile up. Unfortunately we don't, far as I know, have any unified or particularly easy way to solve that - other than eagle-eyed readers like you pointing them out, which is always appreciated.

If you had edit access, I doubt anyone would mind you closing bugs that are clearly obsolete. Otherwise, when you find them - in products that are still open, but where the bug is obsolete - it's appreciated if you can post, so hopefully someone who can close it will see your message and be able to help tidy it up.

In cases where entire products are obsolete, then I think the best thing would be to go onto the IRC, in the room #bugs, and let someone know that the product still exists and has open bugs. Maybe then they can get it closed off.

Thanks for taking an interest in keeping things tidy and up to date, always very useful!
Comment 44 Rui Matos 2017-10-20 12:18:13 UTC
*** Bug 789242 has been marked as a duplicate of this bug. ***
Comment 45 Guido Trentalancia 2017-10-28 15:44:30 UTC
*** Bug 789593 has been marked as a duplicate of this bug. ***
Comment 46 Florian Müllner 2017-11-02 10:34:13 UTC
*** Bug 789802 has been marked as a duplicate of this bug. ***
Comment 47 GNOME Infrastructure Team 2021-07-05 14:26:07 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.