Thunar SIGSEGV's immediately on start when last directory no longer exists

Thanks for reporting !

I assume you are using the same machine @work and @home ? Which thunar version ?

deep within a network drive.

You have some path ? Is the drive mounted via /etc/fstab or mount ? Or do you connect via sftp /smb / etc ?

Ideally would be to have some minimal reproducer.

immediately segfaults.

For crashes, it's best to get a backtrace to see which method failed to execute.

To get a meaningfull backtrace, you will need to install thunar debug symbols. Check the distro specific backtrace info in the xfce wiki to see how to do so !

It's basically ulimit -c unlimited to produce coredumps on crashes and than using gdb on it to get the backtrace out of the coredump. Here some example: https://serverfault.com/questions/61659/can-you-get-any-program-in-linux-to-print-a-stack-trace-if-it-segfaults

and restart the whole Xfce session (logout+login)

Probably thunar -q;thunar as well will do. (this will end the running thunar daemon)

added 1. Crash / Freeze label

added 3. Need Info label

Yes same notebook at work and at home. Thunar version 4.17.6. I did not have the problem with earlier versions.

It is a windows (smb) drive mounted via "mount" command. The drive is not in fstab. An example for a "last-tabs-left" causing the crash is "file:///home/kk/dhge/daten-mnt/GEMEINSAM/Presseschau/2021" where /home/kk/dhge/daten-mnt/ is the mount point.

I'll try to reproduce and debug (this is on gentoo linux, so I'll have to build a thunar with debug info).

If the bug was introduced between 4.17.5 and 4.17.6, another possibility to track it down would be compiling from source and using git bisect.

Hmm, cannot see any commit in between which looks suspicious.

Only this one sounds related: 363611a2

Though setting the directory to NULL before showing error sounds not problematic to me .. who knows. If you can, you might want to take a try by reverting it.

added 1. Regression label

#0  thunar_file_get_file (file=0x0) at thunar-file.c:1473
#1  0x000055f33d1181ec in thunar_window_get_directories (window=0x55f33d392280, active_page=active_page@entry=0x7fffa9a521ec) at thunar-window.c:4577
#2  0x000055f33d0ecca3 in thunar_session_client_save_yourself (connection=0x55f33d463d70, session_client=<optimized out>, save_type=<optimized out>, shutdown=<optimized out>, 
    interact_style=<optimized out>, fast=<optimized out>) at thunar-session-client.c:391
#3  0x00007f1b0d3e1a18 in _SmcProcessMessage () from /usr/lib64/libSM.so.6
#4  0x00007f1b0d3d0a98 in IceProcessMessages () from /usr/lib64/libICE.so.6
#5  0x000055f33d0bcae0 in thunar_ice_process_messages (channel=<optimized out>, condition=<optimized out>, client_data=0x55f33d3b2720) at thunar-ice.c:65
#6  0x00007f1b0c539f05 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#7  0x00007f1b0c595430 in ?? () from /usr/lib64/libglib-2.0.so.0
#8  0x00007f1b0c53425f in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#9  0x00007f1b0c7621e5 in g_application_run () from /usr/lib64/libgio-2.0.so.0

The argument file=0x0 at #0 looks suspicious to me... NULL dereference?

Ugh ... how do I keep gitlab from messing up line-formatted input?

Fixed line-formatted input ... there's a "insert code" button for that.

I just checked: Same probem with 4.17.5.

Obviously, I had luck and never closed thunar while showing a network directory with the versions before 4.17.6 ...

Thanks for the backtrace, that helped alot !

So it looks like that problem existed for longer time.

I think the problem comes from the _thunar_return_val_if_fail guards inside thunar_window_get_directories. These will only have effect for the debug mode. Further it makes not much sense to return "FALSE" in a method which returns char **.

It would be great if you could give this patch a try before I push it on master:

0001-Replace-debug-guards-with-if-to-prevent-crash-Issue-.patch

The patch fixes the segfault for me.

When "last-tabs-left" contains my non-existing network drive dir, thunar now opens and shows my home dir instead.

When "last-tabs-left" contains an existing dir, thunar opens and shows that dir.

I didn't check for side effects or memory leaks.

Thanks alot for testing ! Now lets polish this thing a bit by only skipping the problematic folders instead of dumping all open tabs if there is a single malicious tab:

0001-Use-GList-over-gchar-for-getting-an-uri-list-Issue-6.patch

I as well noticed a CTRITICAL when e.g. loading a path on a flashdrive which isnot inserted any more .. so here a second patch which should make it more failsafe:

0002-Prevent-thunar-CRITICAL-when-restoring-non-existing-.patch

Soo, if you are motivated to test once more, that would be great ! (Reset to master and apply the new patches instead of the single old one)

Seems to work for my flashdrive, though so far I did not try with remote locations.

Does not work for me.

I applied the two patches not on top of master, but on top of the gentoo source package for thunar 4.17.6 (they applied without problems).

The resulting thunar works fine if the config's "last-tabs-left" contains a single valid directory, but fails when it contains a single invalid dir (and no valid dir).

Error messages: (thunar:479454): GLib-GObject-WARNING **: 17:04:01.832: invalid unclassed pointer in cast to 'GtkNotebook'

(thunar:479454): Gtk-CRITICAL **: 17:04:01.832: gtk_notebook_set_current_page: assertion 'GTK_IS_NOTEBOOK (notebook)' failed

I did not test with multiple tabs.

Quick guess: If the one and only (or all) entries in "last-tabs-left" is invalid, are you trying to open thunar with zero tabs (because the list of valid tabs is empty!), or are you using a default tab instead?

Thanks alot for testing ! Uh, indeed, I can reproduce the crash! Looks like my testing was not sufficient.

Here the fixed patches .. hopefully this time they are fine:

0002-Prevent-thunar-CRITICAL-crash-when-restoring-non-exi.patch

0001-Use-GList-over-gchar-for-getting-an-uri-list-Issue-6.patch

Hmmm...

Again tested on top of 4.17.6 (this time, patches applied with an offset).

The good news: It no longer crashes, it doesn't emit fatal errors.

The bad news: I don't really understand what's going on, the behaviour is inconsistent:

Old directory is on my network drive, the network drive is not present: ==> Current directory is opened instead. Fine.
Old directory is the mount point of a no-longer-present stick: ==> Error dialog "permission denied" (because mount point is now owned by root and 0700) ==> In spite of that, that directory is shown (empty, of course) in the tab, not the current dir.
Old directory is a subdirectory immediately below that mount point of a no-longer-present stick: ==> No error message is shown! ==> That directory is shown in the tree view on the left, and is shown in the tab (empty), although it no longer exists!!! ==> The current dir should have been shown instead?!

Three test cases, three different results. So what is the defined behaviour?

Hah, actually I did not look into consistent behavior ... I was just happy that it generally works

My flashdrives per default (using gvfs) are mounted into /media/schwinn/<Stickname> (user/group=schwinn). The <Stickname> folder is removed on umount/eject. So I cannot reproduce the behavior you describe ... for me in both problem-cases the current directory is shown.

So do you use gvfs ? If not, which steps you do to mount the drive ?

Here a slightly modified version of the second patch, which in addition uses thunar_file_exists on the folder .. possibly that helps to prevent the 'subdir below mountpoint' case for you ?

0002-Prevent-crash-when-restoring-non-existing-URI-Issue-.patch

(If nothing else fails for the patches / if the inconsistent behavior is the only quirk, I think they are fine to be pushed)

Will take some time for me to test again.

About mounting and so on:

thunar is build with the gudev config option, so it uses udisks, gvfs etc.
My network drive is (un)mounted manually with "mount ...", mountable by root only.

If it is not mounted, the mount point directory exists (deep within my home directory), and is owned my myself. So the mount point can be stat'ed and its content (empty) can be checked. The actual "last tabs left" directory is several levels below that mount point, so it does not exist when the network drive is unmounted, and thunar can check that.

My stick is user-mountable and usually (un)mounted by myself with the Xfce mount panel plugin (which - if I remember correctly - does not use gvfs and so on). No automounter of any kind.

The stick is mounted at /mnt/sda1. When mounted, /mnt/sda1 is owned by myself. When not mounted, the mount point /mnt/sda1 still exists, is owned by root:root, perms 0700. So the mount point can be stat'ed, but it's content is unacessable, and it cannot be cd'ed into (so thunar cannot determine if it is empty or contains the subdirectory thunar wants to display).

My unix tradition goes back long before the existance of linux (I personally and privately owned an AT&T SysVR3 license since 1986), and my current Gentoo linux installation has its roots almost 20 years ago (initial installation 2002). So some things are done in a rather conservative way here...

Ok, thanks for the details ! Mounting my flashdrive manually on a /mnt/thunar_test which was created with perms 700, now I can reproduce the problem. thunar_file_exists did not help ... I'll look into it !

Tried as well the Xfce mount panel plugin, though it does not even show my flashdrive :) Think it only shows the stuff which are listed by /etc/fstab

Yes, the mount plugin is restricted to /etc/fstab.

Ok, found a fix for "subdirectory of non-existing mountpoint":

0002-Prevent-crash-when-restoring-non-existing-URI-Issue-.patch

Though I did not find a good fix yet to prevent opening the 0700 folder directly.

Just checking things quickly, I found no major change in behaviour with the new patch (things working before still worked, things behaving strange before still behaved strange in the same way in most cases).

However, I noticed two interesting things when the last directory shown in thunar was a direct subdirectory of a no-longer-mounted 0700 mount point (mount point /mnt/sda1 with classical fstab entry and xfce mount plugin for mounting/unmounting):

Depending on being in the same or a new xfce session, starting thunar results in two different behaviours: In some cases, the no-longer-existing directory is shown, in other cases, some other, existing directory is shown instead.
Some very broken caching seems to work behind the scenes. Sequence of actions:

Set thunar to detailled list view
Mount the USB stick, start thunar, change to /mnt/sda1/some_subdir in thunar.
Close thunar with that dir shown, logout, login (!).
Unmount the stick
Open thunar ==> Some other dir is shown instead
Mount the stick again
In thunar, change to the mount point /mnt/sda1 ==> Content of toplevel stick dir is shown.

At the first glance, the content of /mnt/sda1 looks fine, but a closer look shows that the entry for "some_subdir" is broken: Size 0, unknown date, wrong user/group root/root (instead of my user), wrong permissions 0666 (for a directory!), but correct name and type "folder". Also, you can't change into some_subdir by clicking it.

So, obviously, in step 5, when thunar tried to open the non-existing some_subdir, it remembered the (invalid) size, owner etc. it got for that invalid dir. And in step 7, thunar still used that cached (invalid) information for some_subdir instead of reading the correct information from its now-available parent dir.

Thou shalt not store invalid information in caches. Thou shalt check that your cached information is up-to-date before using it (and invalidate it if it is not!).

Thanks again for testing !

Sorry, I am not able to reproduce this weird behavior. Since neither a crash, nor a CRTITICAL happens, I will push the patches I have .. at least they should fix the current bug.

Best report the weird behavior in a fresh bug .. ideally try to make the steps to reproduce as simple as possible (e.g. thunar -q;thunar probably should have the same effect than logout/login ... does it really only happen for detailed list view ?)

I'll test again when 4.17.7 is available in gentoo.

I don't think that it happens only in detailled list view, but detailled list view is the only view where you can clearly see that something is wrong with that entry.

I didn't test thunar -q lately, but when I first experimented with that bug, logout/login differed from thunar -q.

mentioned in issue #655 (closed)

mentioned in commit f6116416

mentioned in commit 57c4a513

Bug fixed by above commits, to be released in thunar 4.17.7

closed

mentioned in issue #691

Thunar SIGSEGV's immediately on start when last directory no longer exists

Designs

Child items ...

Activity