Infinite loop in favorite-vfs-file-enumerator next_file() freezes system (xdg-desktop-portal floods log)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- c, linux
- Domain
- desktop-dev
Research direction
The affected entry point is favorite-vfs-file-enumerator.c: next_file(); read its loop and the referenced xapp-favorites.c display-name update path first. Verify both the missing-display-name and failed-query cases advance enumeration and terminate or report an error instead of repeating, then confirm the dialog no longer floods logs.
Written by the indexing model from the issue text.
Description
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).
- Dominant language
- C
- Stars
- 167
- Forks
- 49
- Avg merge
- 5d 15h
- Merged PRs (30d)
- 2
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from linuxmint/xapp
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
johnsonjh/emu2-cpm86#68 · 1 comment ·
Maintainers usually reply within 1 day
-
Zenmap CrashOpenZenmap
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
BasedHardware/omi#19306 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
fastfetch-cli/fastfetch#2619 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
serhii-londar/open-source-mac-os-apps#1419 ·
Maintainers usually reply within 5 days