Created attachment 6939 gdb stacktrace (Thunar 1.6.10git-45fb3a15) An assertion failure (stack trace attached) can be triggered reliably by navigating thunar to a folder containing the script 'exercise.py' and running that script (which randomly creates and renames files to check whether file system events are handled correctly). Error analysis (thunar-folder.c): 1) thunar_folder_reload starts a new job and returns 2) thunar_folder_content_type_loader is called from a different context and sets content_type_idle_id 3) thunar_folder_finished is called when the job finishes and causes the failure because content_type_idle_id != 0 Goodie: I will also attach a stack trace for step 2 in case this helps (obtained by adding a check for folder->job == NULL in thunar_folder_content_type_loader). It's certainly easy to provide workarounds but I don't understand the logic well enough to provide a proper fix. Cheers, Christoph
Created attachment 6940 stack trace for step 2
Created attachment 6941 script for stress testing
Can you try with Thunar 1.6.11 ? (https://mail.xfce.org/pipermail/xfce-announce/2017-February/000495.html) Tons of bugs has been fixed in this release.
Created attachment 7154 1.6.11git-f5221396 stacktrace A
Created attachment 7155 1.6.11git-f5221396 stacktrace B
Created attachment 7156 1.6.11git-f5221396 stacktrace C
I've obtained the three attached stacktraces (distinct, but related) with 1.6.11git-f5221396.
The attached stacktraces for 1.6.11 only exist because g_warning becomes fatal with '--enable-debug=full'; after removing that warning, I haven't been able to trigger any issue, so 1.6.11 seems to have fixed this bug.