In the attached patch, I've edited debian/changelog to include the LP
bug # as requested. I also went ahead and added some
description/reference links to the patch itself--I ended up creating a
new debdiff to do this since I wasn't sure how to manually update line
numbers in a way that would be safe. I renamed the original patch to
1-gvfs for clarity. The substance of the patch is unchanged.

I'll update the bug description momentarily. Sorry for the delay!

** Patch added: "2-gvfs.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1927100/+attachment/5548854/+files/2-gvfs.debdiff

** Description changed:

+ [Description]
+ glib GFileMonitors can cause deadlocks if not explicitly cancelled before 
unref-ing (as of Dec 2021; see 
https://gitlab.gnome.org/GNOME/glib/-/issues/1941). In gvfs <1.46.2, 
gvfsd-trash can cause this deadlock, leading to 25s delays in spawning gtk+ 
dialogs system-wide. The best userspace workaround is explicitly pkill-ing 
gvfsd-trash at a sometimes frequent interval.
+ 
+ This issue was reported and fixed in gvfs 
+ issue: https://gitlab.gnome.org/GNOME/gvfs/-/issues/485
+ commit: 
https://gitlab.gnome.org/GNOME/gvfs/-/commit/dc21a0948bcbe8a6d79d674bd1e4d63ded57d340
+ merge: https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/96
+ 
+ 
+ [Test Case]
+ To my knowledge, there is not a 100% reproducer for gvfs from userspace as 
this is a probable lock-ordering issue in lower-level code. 
https://gitlab.gnome.org/GNOME/glib/-/issues/1941 contains a reproducer for the 
underlying glib issue.
+ 
+ User reports of gvfsd-trash manifesting this deadlock exist for Focal and 
Focal-based distributions, and it has been acknowledged and worked-around in 
gvfs. See:
+ https://forums.linuxmint.com/viewtopic.php?f=47&t=328966 (Linux Mint forums)
+ https://github.com/linuxmint/nemo/issues/2497 (Linux Mint nemo -- file 
manager)
+ https://gitlab.gnome.org/GNOME/gvfs/-/issues/485 (gvfs bug report, includes 
diagnosis and stacktrace showing the gvfsd-trash thread)
+ 
+ The code change patched-in here has propagated to various other projects. See:
+ https://bugs.launchpad.net/ubuntu/+source/libxmlb/+bug/1890313
+ https://github.com/fwupd/fwupd/issues/2350
+ 
+ 
+ [Regression Potential]
+ This patch explicitly cancels GFileMonitors before "unreferencing" them to 
workaround a known glib issue. Absent any currently-unknown issues with the 
GFileMonitor framework, code added by this patch should be entirely within 
valid usage of GFileMonitors, is already present in gvfs releases in wide 
distribution, and, at worst, should become superfluous if/when the underlying 
glib issue is fixed.
+ 
+ In the event that gvfsd-trash had some (currently unknown) mismanagement
+ of its file watchers, it's possible that attempting to cancel an invalid
+ monitor might behave differently than unref-ing it (which was already
+ happening), but, this scenario would likely be bad either way.
+ 
+ 
+ [Original Description]
+ 
  On Ubuntu Mate 20.04.
  
  Sometime the Open and Save dialogs in GTK applications will over 20
  seconds to display.
  
  I found https://gitlab.gnome.org/GNOME/gvfs/-/issues/485 , which
  suggested this due to gvfsd-trash, and running `killall gvfsd-trash`
  which does temporary solve the problem.
  
  The issue is apparently fixed in gvfs 1.46.2
  
  Please could 1.46.2 or the fix
  https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/96 be backported to
  Ubuntu 20.04

** Description changed:

- [Description]
+ [Description/Impact]
  glib GFileMonitors can cause deadlocks if not explicitly cancelled before 
unref-ing (as of Dec 2021; see 
https://gitlab.gnome.org/GNOME/glib/-/issues/1941). In gvfs <1.46.2, 
gvfsd-trash can cause this deadlock, leading to 25s delays in spawning gtk+ 
dialogs system-wide. The best userspace workaround is explicitly pkill-ing 
gvfsd-trash at a sometimes frequent interval.
  
- This issue was reported and fixed in gvfs 
+ This issue was reported and fixed in gvfs
  issue: https://gitlab.gnome.org/GNOME/gvfs/-/issues/485
  commit: 
https://gitlab.gnome.org/GNOME/gvfs/-/commit/dc21a0948bcbe8a6d79d674bd1e4d63ded57d340
  merge: https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/96
- 
  
  [Test Case]
  To my knowledge, there is not a 100% reproducer for gvfs from userspace as 
this is a probable lock-ordering issue in lower-level code. 
https://gitlab.gnome.org/GNOME/glib/-/issues/1941 contains a reproducer for the 
underlying glib issue.
  
  User reports of gvfsd-trash manifesting this deadlock exist for Focal and 
Focal-based distributions, and it has been acknowledged and worked-around in 
gvfs. See:
  https://forums.linuxmint.com/viewtopic.php?f=47&t=328966 (Linux Mint forums)
  https://github.com/linuxmint/nemo/issues/2497 (Linux Mint nemo -- file 
manager)
  https://gitlab.gnome.org/GNOME/gvfs/-/issues/485 (gvfs bug report, includes 
diagnosis and stacktrace showing the gvfsd-trash thread)
  
  The code change patched-in here has propagated to various other projects. See:
  https://bugs.launchpad.net/ubuntu/+source/libxmlb/+bug/1890313
  https://github.com/fwupd/fwupd/issues/2350
  
- 
  [Regression Potential]
  This patch explicitly cancels GFileMonitors before "unreferencing" them to 
workaround a known glib issue. Absent any currently-unknown issues with the 
GFileMonitor framework, code added by this patch should be entirely within 
valid usage of GFileMonitors, is already present in gvfs releases in wide 
distribution, and, at worst, should become superfluous if/when the underlying 
glib issue is fixed.
  
  In the event that gvfsd-trash had some (currently unknown) mismanagement
  of its file watchers, it's possible that attempting to cancel an invalid
  monitor might behave differently than unref-ing it (which was already
  happening), but, this scenario would likely be bad either way.
- 
  
  [Original Description]
  
  On Ubuntu Mate 20.04.
  
  Sometime the Open and Save dialogs in GTK applications will over 20
  seconds to display.
  
  I found https://gitlab.gnome.org/GNOME/gvfs/-/issues/485 , which
  suggested this due to gvfsd-trash, and running `killall gvfsd-trash`
  which does temporary solve the problem.
  
  The issue is apparently fixed in gvfs 1.46.2
  
  Please could 1.46.2 or the fix
  https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/96 be backported to
  Ubuntu 20.04

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1927100

Title:
  Slow file dialogs, open and save

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1927100/+subscriptions


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

Reply via email to