(In reply to Harald Judt from comment #1)
> Created attachment 6483 [details]
> check-thunar-file-instance-when-comparing-filenames.patch
>
> > gdb backtrace attached - it is strange that the
> > thunar_file_compare_by_name() function is called even for only one file in
> > working directory - both file_a->collate_key_nocase and
> > file_b->collate_key_nocase are NULL. I noticed that sometimes this function
> > is not called, but when it is (it is random), then it crashes.
>
> This is probably related to threading issues and timing-specific. Something
> needs to be protected to avoid being accessed when it shouldn't be. Likely
> the old file is in the process of being destroyed while being compared with
> the new file or something like that.
>
It can be the reason why running Thunar with gdb has about 10 times less crashes. I also noticed that sometimes, when I rename file, there appears second file with the same name like the first one (checked it with "ls -l" - there is only one real file).
> Does the attached workaround prevent the crashes? It is not a proper fix we
> can apply, but until we have a good solution it could help.
Well, this workaround does not help. The problem is that THUNAR_IS_FILE returns true (for file_a and file_b), but pointers to collate_key are NULL. There has to be another test if file_a->collate_key or file_a->collate_key are NULL.
I wonder what makes my system different it crash so often.
(In reply to Harald Judt from comment #1) file-instance- when-comparing- filenames. patch file_compare_ by_name( ) function is called even for only one file in >collate_ key_nocase and >collate_ key_nocase are NULL. I noticed that sometimes this function
> Created attachment 6483 [details]
> check-thunar-
>
> > gdb backtrace attached - it is strange that the
> > thunar_
> > working directory - both file_a-
> > file_b-
> > is not called, but when it is (it is random), then it crashes.
>
> This is probably related to threading issues and timing-specific. Something
> needs to be protected to avoid being accessed when it shouldn't be. Likely
> the old file is in the process of being destroyed while being compared with
> the new file or something like that.
>
It can be the reason why running Thunar with gdb has about 10 times less crashes. I also noticed that sometimes, when I rename file, there appears second file with the same name like the first one (checked it with "ls -l" - there is only one real file).
> Does the attached workaround prevent the crashes? It is not a proper fix we
> can apply, but until we have a good solution it could help.
Well, this workaround does not help. The problem is that THUNAR_IS_FILE returns true (for file_a and file_b), but pointers to collate_key are NULL. There has to be another test if file_a->collate_key or file_a->collate_key are NULL.
I wonder what makes my system different it crash so often.