GNOME Bugzilla – Bug 788666
Gnome 3.26 with Xorg backend crashes when I close a maximized app
Last modified: 2021-07-05 14:26:07 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).
Unfortunately the log is not very helpful without debug symbols. Please compile gtk3, mutter and gnome-shell with debug symbols and reproduce the crash.
(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.
Florian Müllner: I'm on the same system as @Kateryna and I will post logs with debug mode enabled soon.
Created attachment 361141 [details] stack trace after closing Liferea Stack trace with symbols after closing maximized Liferea window and gnome-shell crash
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.
Created attachment 361142 [details] bt of crash
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).
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).
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
(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.
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.
(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
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
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)'
(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.
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.
Created attachment 361191 [details] [review] patch to fix the problem This patch should fix the problem.
*stops uploading identical patch*
(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.
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.
(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.
Can confirm this resolving issue (using update in Solus) in GNOME Shell. +1 for patch.
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
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!
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.
(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.
(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 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.
*** Bug 788729 has been marked as a duplicate of this bug. ***
(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
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.
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 on attachment 361191 [details] [review] patch to fix the problem git-bz failed on me. Pushed as commit f9c625924.
@Carlos Garnacho thank you for the push. Just a detail: the commit link redirects to gnome-shell git instead of mutter.
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.
Daniel Boles: Agree.
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?
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.
(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
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.
...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 ;)
(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.
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!
*** Bug 789242 has been marked as a duplicate of this bug. ***
*** Bug 789593 has been marked as a duplicate of this bug. ***
*** Bug 789802 has been marked as a duplicate of this bug. ***
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.