g_file_monitor broken in glib-2.72.1 update

edscott · 2022-05-04 16:16:18

After a system update yesterday (pacman -Syu) the call to g_file_monitor() from my gtk3 filemanager (http://xffm.org) stopped working. Does not respond to the "changed"signal"; glib2 package was updated to version 2.72.1

If I download glib-2.72.1.tar.xz, unpack, compile and use the generated libraries with LD_LIBRARY_PATH, g_file_monitor() works fine, so the problem does not appear to be upstream.

Some kind of bug affects the updated glib2 binary package (glib2-2.72.1-1-x86_64.pkg.tar.zst).

How can I check the source and build procedure for the current glib2 package to try to figure out the problem and report a bug? And where would I report the bug?

Any pointers on how to proceed is appreciated.

V1del · 2022-05-04 16:25:53

Every package has a PKGBUILD containing the instructions that have been used to build it: https://github.com/archlinux/svntogit-p … k/PKGBUILD (you can find that link under the "View Sources") in the package page on the web interface.

For generally acquiring/building those yourself the ABS page on the wiki has some pointers the only direct change to what used to be built was an opt dep on gvfs, maybe being built now may have lead to some internal dependency on that for that function. Do you get a visible error in the terminal or does the relevant function just not work?

Last edited by V1del (2022-05-04 16:27:48)

edscott · 2022-05-04 16:48:46

Thank you for your reply, V1del.

No visible error appears in the terminal. Debugging the source code that calls the g_file_monitor() function shows that GFileMonitor object is created successfully and no error is reported when the object is connected to the "changed" signal. The problem appears to be that the "changed" signal is never generated when it is supposed to.

The filemanager is running on an i3 environment, not Gnome. But gvfs is installed anyway:

$ pacman -S gvfs
warning: gvfs-1.50.1-1 is up to date -- reinstalling

Maybe the Gnome environment turns gvfs on and i3 does not?

V1del · 2022-05-04 16:53:10

Possibly a broken DBUS session, how exactly are you starting your i3 session? post your .xinitrc if so and maybe

printenv | grep DBUS
systemctl --user status

edscott · 2022-05-04 17:19:44

Ah! DBUS.

This is how I start my i3 session from the console with .xinitrc:

#!/bin/sh
setxkbmap latam
xrandr --output DVI-I-1 --primary --auto --rotate left --output DVI-I-1-2 --auto --rotate left --left-of DVI-I-1
gkrellm&
uxterm&
xscreensaver&
export PATH=$PATH:/home/edscott/bin
pulseaudio --daemonize
exec i3

DBUS environment variable value:

$ printenv | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1300/bus

and systemctl status:

$ systemctl --user status
● arch-0
    State: degraded
     Jobs: 0 queued
   Failed: 2 units
    Since: Mon 2022-05-02 14:59:56 CDT; 1 day 21h ago
   CGroup: /user.slice/user-1300.slice/user@1300.service
           ├─app.slice
           │ ├─at-spi-dbus-bus.service
           │ │ ├─ 3345 /usr/lib/at-spi-bus-launcher
           │ │ ├─ 3805 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf -->
           │ │ └─ 3813 /usr/lib/at-spi2-registryd --use-gnome-session
           │ └─dconf.service
           │   └─ 1647779 /usr/lib/dconf-service
           ├─init.scope
           │ ├─ 2222 /usr/lib/systemd/systemd --user
           │ └─ 2223 "(sd-pam)"
           └─session.slice
             ├─dbus.service
             │ └─ 3070 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-act>
             ├─gvfs-daemon.service
             │ ├─    3294 /usr/lib/gvfsd
             │ ├─    3299 /usr/lib/gvfsd-fuse /run/user/1300/gvfs -f
             │ ├─ 1647509 /usr/lib/gvfsd-trash --spawner :1.8 /org/gtk/gvfs/exec_spaw/0
             │ ├─ 1647529 /usr/lib/gvfsd-network --spawner :1.8 /org/gtk/gvfs/exec_spaw/1
             │ └─ 1647534 /usr/lib/gvfsd-dnssd --spawner :1.8 /org/gtk/gvfs/exec_spaw/2
             ├─gvfs-metadata.service
             │ └─ 1647326 /usr/lib/gvfsd-metadata
             └─gvfs-udisks2-volume-monitor.service
               └─ 1647463 /usr/lib/gvfs-udisks2-volume-monitor
lines 1-29/29 (END)

DBUS seems to be up and running:

$ ps aux |grep -i dbus
dbus         617  0.0  0.0   8988  4596 ?        Ss   May02   0:02 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
edscott     3070  0.0  0.0   8832  4204 ?        Ss   May02   0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
edscott     3805  0.0  0.0   8472  4096 ?        S    May02   0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/run/user/1300/at-spi/bus

Maybe the --use-gnome-session option in at-spi-dbus-bus.service has something to do?

But that still leaves me in the dark as to why my locally compiled vanilla glib2-2.72.1 works fine.

progandy · 2022-05-04 17:28:22

This test program works for me with glib2 2.72.1-1:
https://gist.github.com/simu/0ed1e9b128 … e73eeeb8e1

edscott · 2022-05-04 18:05:33

Thank you for your response, Progandy. I downloaded and compiled your test program, and it works correctly with both the glib2 binary package and the locally compiled vanilla glib-2.72.1.

The difference I find in the source code is the manner in which the glib event loop is started. Your code uses a direct glib call:

    GMainLoop *ws = g_main_loop_new(NULL, FALSE);
    assert(ws);
...
   g_main_loop_run(ws);

While the xffm filemanager uses an old fashion proxy call from the gtk library:

    gtk_main();

So apparently the event loop created by gtk_main() does not receive the "changed" signal, but the loop created by g_main_loop_run(ws) does.

Maybe the differences between the binary package glib2 and the locally compiled vanilla glib-2.72.1 requires the GMainLoop to be specifically created and supplied?

progandy · 2022-05-04 18:30:52

Just changed it to gtk_main and it still works...

edscott · 2022-05-04 18:31:24

Nope: the g_main_loop_run/gtk_main difference is not the issue.

The GFileMonitor will not receive the changed signal either way in the gtk filemanager using the binary glib2 package.

This really baffles me

Maybe it has something to do with the binary gtk3 package?

edscott · 2022-05-04 21:07:09

Okay. I'm finished checking the differences between the ABS build for glib2, installed by package at /usr and a locally compiled version installed at /opt:

There is no difference.

Even if I uninstall with pacman -R -d -d glib2 and install the locally compiled glib2 into /usr, g_file_monitor will still not work, although the exact same binaries work as a charm when installed at /opt.

So there is no problem with the glib2 binary package. There must be some quirk in the xffm filemanager, although it has been working without problems for years in the stable gtk-3.24.xx series.

I hope to figure it out soon.

Thank you for your kind responses.

Last edited by edscott (2022-05-04 21:08:38)

jasonwryan · 2022-05-04 21:13:55

Your xinitrc is incomplete (see the wiki page) which probably explains why your session is broken:

$ systemctl --user status
● arch-0
    State: degraded

edscott · 2022-05-06 17:09:30

Problem has been solved, but not explained.

Other problems were also detected. Notably Firefox would inevitably crash whenever download of any file was attempted.

So I did a clean install of Archlinux on a fresh partition and g_file_monitor works fine now and Firefox does not crash.

So apparently the upgrade broke something and made system --user status report a degraded state. Now it reports a running state.

It has nothing to do with ~/.xinitrc.

I'm sorry I cannot explain how pacman -Syu broke the system, but the fix is a clean install of the Archlinux system and binary packages.

You might find someone else encountering a crash in Firefox while trying to download a file, due to the same issue.

I vote for some mishap related to DBUS, as V1del sugested. Probably some DBUS dependency not correctly updated. But that is just my wild guess.

Thanks again to all for you kind responses.

Arch Linux

#1 2022-05-04 16:16:18

g_file_monitor broken in glib-2.72.1 update

#2 2022-05-04 16:25:53

Re: g_file_monitor broken in glib-2.72.1 update

#3 2022-05-04 16:48:46

Re: g_file_monitor broken in glib-2.72.1 update

#4 2022-05-04 16:53:10

Re: g_file_monitor broken in glib-2.72.1 update

#5 2022-05-04 17:19:44

Re: g_file_monitor broken in glib-2.72.1 update

#6 2022-05-04 17:28:22

Re: g_file_monitor broken in glib-2.72.1 update

#7 2022-05-04 18:05:33

Re: g_file_monitor broken in glib-2.72.1 update

#8 2022-05-04 18:30:52

Re: g_file_monitor broken in glib-2.72.1 update

#9 2022-05-04 18:31:24

Re: g_file_monitor broken in glib-2.72.1 update

#10 2022-05-04 21:07:09

Re: g_file_monitor broken in glib-2.72.1 update

#11 2022-05-04 21:13:55

Re: g_file_monitor broken in glib-2.72.1 update

#12 2022-05-06 17:09:30

Re: g_file_monitor broken in glib-2.72.1 update

Board footer