GIO trash test sometimes fails: test_trash_symlinks: 'target_mount' should not be NULL

gio/tests/trash.c fails on Ubuntu's Launchpad autobuilders:

1..2
# Start of trash tests
# Bug Reference: https://gitlab.gnome.org/GNOME/glib/issues/251
# File: /tmp/test-trashRH6RUZ (parent st_dev: 64769)
# Home: /<<PKGBUILDDIR>>/debian/build (st_dev: 64769)
ok 1 /trash/not-supported # SKIP The file has to be on another filesystem than the home trash to run this test
# Bug Reference: https://gitlab.gnome.org/GNOME/glib/issues/1522
**
GLib-GIO:ERROR:../../../gio/tests/trash.c:113:test_trash_symlinks: 'target_mount' should not be NULL
Bail out! GLib-GIO:ERROR:../../../gio/tests/trash.c:113:test_trash_symlinks: 'target_mount' should not be NULL

This is a regression between 2.58.1 and 2.58.2, possibly caused by 57cfbc93.

These autobuilders build GLib in a chroot; I'm not sure whether its root is a mount point itself, or a subdirectory of a mount point, or what. On Debian's very similar autobuilders this test works fine.

I get the same test failure (possibly for unrelated reasons) on my laptop, which happens to use btrfs. Minimal reproducer (all subvolumes mentioned are on the same LVM volume):

>>> from gi.repository import Gio
>>> def t(path):
...  entry = Gio.unix_mount_for(path)[0]
...  if entry is None:
...   return '(none)'
...  else:
...   return Gio.unix_mount_get_mount_path(entry)
# / has btrfs subvolume '@' mounted on it
>>> t("/")
'/'
# /home has btrfs subvolume 'home' mounted on it
>>> t("/home")
'/'
# /home/smcv is a subvolume 'home/smcv' that exists inside /home, but is not
# mounted separately (does not appear in /proc/self/mounts)
>>> t("/home/smcv")
'(none)'
# /home/smcv/.local is just a subdirectory
>>> t("/home/smcv/.local")
'(none)'
# /var is just a subdirectory of the root
>>> t("/var")
'/'
# /var/tmp is a subvolume 'var/tmp' that exists inside @/var, but is not
# mounted separately (does not appear in /proc/self/mounts)
>>> t("/var/tmp")
'/'
# /var/tmp/smcv is just a subdirectory
>>> t("/var/tmp/smcv")
'(none)'

The test says "The test assumes that ~/.local always exists" which seems like a wrong assumption and should probably be fixed (in a minimal autobuilder/test environment it's possible that this test is the first thing to try to use that directory). However, creating .local is not sufficient to fix this.

As a short term solution I've written a patch to skip this test if the mount for target or tmp cannot be determined, but that's probably masking a more fundamental problem here?