Skip to content

Search: monitoring assertion triggered in thunar_list_model_files_removed() when (e.g.) Vim overwrites .viminfo files

This one came up during my work on hidden files searching in Merge Request 246, but it's reproducible on main as of 909efefe. Reproduction is tricky, and may depend on your vim behaviour.

Steps to reproduce

(I've edited this to tidy it up and make it easier to reproduce)

  1. Make sure you have Vim installed.

  2. Open Thunar, and navigate to an empty directory.

  3. Start a search with Ctrl+F that doesn't match anything, e.g. fsafdasfd.

  4. Start Vim, and write a viminfo file into the directory in 2. Use :wviminfo DIRNAME/a.viminfo.

  • Thunar does not crash if the viminfo file was created by this action.
  1. Repeat the vim command in 4.
  • Thunar now crashes with the following assertion:
thunar:ERROR:thunar-list-model.c:1535:thunar_list_model_files_removed: assertion failed: (g_slist_find (store->hidden, lp->data) != ((void *)0))
Bail out! thunar:ERROR:thunar-list-model.c:1535:thunar_list_model_files_removed: assertion failed: (g_slist_find (store->hidden, lp->data) != ((void *)0))
Aborted

When Thunar starts again, the view has changed to list mode (like search results). This however is a consequence of the crash, not part of the incorrect behaviour here.

Observations

Vim regularly overwrites .viminfo files in the user's $HOME as part of its normal operation, when vim quits. In practice, this means that Vim will cause Thunar to due unexpectedly a lot, if Thunar users start searches in their $HOME.

While the search results are active, the directory being searched is still being monitored for added and removed files. I do not think this should be happening. To demonstrate it, perform as search in a directory, and then separately create a new file in the directory. The newly created file appears in the search results regardless of the search terms used.

More notes for folks trying to reproduce this

Vim has a command :wviminfo which can be used to write .viminfo information to an arbitrary file. Using this, I was able to narrow this bug down to happening when:

  • Thunar is searching and the arbitrary viminfo did not come up in the search results (you can start by searching for something that matches nothing at all)
  • Vim calls ":wviminfo file.viminfo" to UPDATE that file. It must already exist from an earlier call, and it must NOT already be part of the search results.
  • The viminfo file doesn't have to be a dotfile, and you don't have to have Show Hidden turned off or on.

To me it looks like a file monitoring issue, so the easiest and most correct solution would probably be to switch off file monitoring while search results are visible. However, understanding wtf Vim is doing with those .viminfo files might help us make the Thunar codebase more robust.

This also has the feel of a race condition. I really hope it's Not Just Me! Maybe some debug prints in thunar_list_model_files_removed() and thunar_list_model_files_added() would shed some light on it.

Edited by Andrew Chadwick