System
- Linux Mint 22.3 Cinnamon (X11)
- libxapp1 3.2.3+zena, xdg-desktop-portal-xapp 1.1.3+zena, xdg-desktop-portal-gtk 1.15.1-1build2
What happened
After a file open/save dialog was opened, xdg-desktop-portal-gtk logged
"(../libxapp/favorite-vfs-file-enumerator.c:57):next_file: code should not be reached"
about 200,000 times per second for 78 minutes (5.1M lines kept by journald,
several million more suppressed every 30s) until the desktop froze and needed a hard reboot.
Cause (from reading the source on master)
In next_file(), when xapp_favorites_find_by_display_name() returns NULL,
the code calls g_warn_if_reached() but does not advance priv->current_pos
inside the while loop, so while (priv->current_pos != NULL && info == NULL)
retries the same entry forever. current_pos is only advanced after the loop.
The same applies if g_file_query_info() returns NULL in the else branch
(infinite loop, without the warning).
Trigger
Favorites included a network:///dnssd-server-._smb._tcp location. Its
initial display name (the URI basename) is later replaced by the real display
name (" (File Sharing)") from the async query in xapp-favorites.c. If the
enumerator snapshotted the display names before that update, the old name is
no longer found and the loop never ends. It's timing-dependent: here, opening the
dialog also triggered a slow CIFS automount of another favorite at the same moment.
A favorite for an unmounted ftp:// location (query fails) looks like it could
cause the same loop via the else branch.
Workaround
Removing the network:/// and ftp:// entries from org.x.apps.favorites list.
Suggested fix
Advance priv->current_pos inside the loop on both the not-found and the
query-failure paths (and return/propagate the error instead of spinning).
I did not deliberately reproduce it (it hard-freezes the machine).
System
What happened
After a file open/save dialog was opened, xdg-desktop-portal-gtk logged
"(../libxapp/favorite-vfs-file-enumerator.c:57):next_file: code should not be reached"
about 200,000 times per second for 78 minutes (5.1M lines kept by journald,
several million more suppressed every 30s) until the desktop froze and needed a hard reboot.
Cause (from reading the source on master)
In next_file(), when xapp_favorites_find_by_display_name() returns NULL,
the code calls g_warn_if_reached() but does not advance priv->current_pos
inside the while loop, so
while (priv->current_pos != NULL && info == NULL)retries the same entry forever. current_pos is only advanced after the loop.
The same applies if g_file_query_info() returns NULL in the else branch
(infinite loop, without the warning).
Trigger
Favorites included a network:///dnssd-server-._smb._tcp location. Its
initial display name (the URI basename) is later replaced by the real display
name (" (File Sharing)") from the async query in xapp-favorites.c. If the
enumerator snapshotted the display names before that update, the old name is
no longer found and the loop never ends. It's timing-dependent: here, opening the
dialog also triggered a slow CIFS automount of another favorite at the same moment.
A favorite for an unmounted ftp:// location (query fails) looks like it could
cause the same loop via the else branch.
Workaround
Removing the network:/// and ftp:// entries from org.x.apps.favorites list.
Suggested fix
Advance priv->current_pos inside the loop on both the not-found and the
query-failure paths (and return/propagate the error instead of spinning).
I did not deliberately reproduce it (it hard-freezes the machine).