0.5 (63) regularly crashes

[blueclochard]

I recently upgraded from version 0.3 (61) to version 0.5 (63), because I had upgraded to Ubuntu 22.04 and could not get version 0.3 to work anymore. Unfortunately, version 0.5 does not really work very well for me. Apart from the fact that it sometimes hangs for several seconds when working with folders containing a lot of files (more than 1000), the main problem is that it crashes several times per day. This always happens in the background, when I am not using Sunflower and the focus is on another application. I then get the following error:

(Sunflower:852667): Gtk-CRITICAL : 12:57:33.189: gtk_tree_store_sort_iter_changed: assertion 'G_NODE (iter->user_data)->parent != NULL' failed Gtk:ERROR:../../../../gtk/gtktreestore.c:597:gtk_tree_store_get_path: assertion failed: (G_NODE (iter->user_data)->parent != NULL) Bail out! Gtk:ERROR:../../../../gtk/gtktreestore.c:597:gtk_tree_store_get_path: assertion failed: (G_NODE (iter->user_data)->parent != NULL) Aborted (core dumped)

I know this is a small and not very active project, but I would appreciate any pointers on how this can be fixed. Alternatively, if anyone knows how to get 0.3 (61) working on newer Linux distributions, I would be grateful as well.

[MeanEYE]

Thanks for reporting this issue. I think there are already some that are duplicates. Basically from the first look it seems like it's a racing condition in GTK source code. For example one part of my code is trying to update item in the file list, after item has been removed.

This however shouldn't be happening, as Sunflower updates main list only from a single thread.

Can you provide more information about the directory Sunflower was currently displaying and if there were any updates to those files in background. I'll do my best to help solve this.

To answer second part of the issue, running 0.3 version relied on pygtk package, and 0.4 version onwards relies on python3-gi. Just installing one of the older .deb files should install dependencies. But Ubuntu might have removed them from the repository.

[blueclochard]

Can you provide more information about the directory Sunflower was currently displaying and if there were any updates to those files in background. I'll do my best to help solve this.

This is the case indeed. I always have one folder open on the left, which is my work folder. Once finished with a project, I use Sunflower to move some of the files from my work folder to several other folders that I have open in tabs on the right.

I also have my work folder open in my regular file manager (Thunar) and regularly delete files here. I just ran some tests and I could get Sunflower to crash once out of 10 attempts by deleting a file in Thunar. So it doesn't happen all the time, but it might very well be that Sunflower was not trying to update the file list during those other 9 times.

[MeanEYE]

So to explain what's going on for clarity sake. Sunflower will list the directory first and as fast as possible, then set up inode monitor in that directory for any future updates. Some editors and file managers do weird things, like save file to a random name, then do quick delete of original and move to previous file name. Vim is most notable for doing this.

Things happen so fast that my code finds the inode data, goes on to update it, but during that time it gets removed, hence the racing condition which results in Sunflower trying to update a list item which doesn't exist but it existed a microsecond prior when signal was received.

I tried solving this issue by creating my own inode monitor which queues up updates in thread-safe way, but that helped only to a degree. You can absolutely reproduce this issue if you make a bash script which creates and removes files as fast as possible. I definitely need to find solution to this. Let me dig through code some more.

[MeanEYE]

This is a duplicate of #491