Created attachment 7815 coredumpctl info by PID for said core When user logs out while a Thunar window is open, Thunar dumps core. Logout itself is successful. Corefile may be viewed on next login. Reproduction Steps: 1) Login to user session 2) open file manager window 3) logout 4) login to user session 5) execute - coredumpctl list - for listing of core files This is consistently reproducible. Thunar: 1.8.1 XFCE DE: 4.12 (latest updated version from arch linux repo)
Thanks for reporting! However I am not able to reproduce the crash/coredump ( Debian Stretch here ) I use lightdm as display manager ... maybe you are using gdm, or something else ? Possibly I can debug the coredump if you compress it and attach it to the issue, together with your thunar binary ( usually located in /usr/bin/thunar ) .. at least worth a try.
I can't reproduce, also using Arch Linux. As mentioned by alexxcons, that coredump could be very helpful for us. You can get the coredump with: coredumpctl dump 24763 -o ~/thunar.core Just remember to compress.
Created attachment 8001 manjaro live thunar systemd coredump Reproduced consistently on Arch, Manjaro. Attached coredump is from Manjaro XFCE Edition (17.1.12) live media running in a vm. Total size 19MB. Compressed using "tar -cvzf".
Thanks for the coredump, however I can't get nothing from it, on gdb bt yields: #0 0x00007f51f275ea99 in ?? () #1 0x0000000000000001 in ?? () #2 0x00007f51f25f01a9 in ?? () #3 0x0000000000000001 in ?? () #4 0x00007f51f2d7eb20 in ?? () #5 0x00005578de4f6030 in ?? () #6 0x0000000000000000 in ?? () I have Thunar 1.8.1 built with the same configure settings used by the Arch package[1] and of course --enable-debug=yes. Maybe I'm missing something... can you please confirm which thunar version you have installed? 1 - https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/thunar
Thunar 1.8.1git-f5147445 (Xfce 4.12) on Arch. Don't know the current version on tested Manjaro. Tested Debian Stretch, and it does not occur. To clarify because it wasn't stated in this specific bug report anywhere, this is related to session saving. It has been an ongoing problem for months, if not longer, there are reports on similar issues with sessions. Apologies for the lack of information, and it looks like Manjaro doesn't have debug symbols by default, it was simply used as a control group. Related: https://bugzilla.xfce.org/show_bug.cgi?id=14347 Manjaro XFCE Live instructions: 1. Boot media, defaults 1. Open Thunar 3. Log out of desktop > Check box for "save session" on bottom > Log Out Results in Thunar causing a hang on logout and the resulting core dump. If that is still unable to be reproduced, then it must be something specific to hardware. However, on 3 different machines that have been tested locally, it happens on all of them.
Created attachment 8002 manjaro thunar systemd coredump Here is another coredump, this was on the same version, Thunar 1.8.1git-f5147445 (Xfce 4.12), and should have been built with debug. This is all new stuff, trying to help/learn here.
Thanks for the coredump, however for us the dump only is useful together with the binary which produced it. So two options: 1. Use gdb to get the backtrace with debug symbols from the coredump, using the binary: gdb <programm> <coredump> Than enter "backtrace" to get the backtrace with debug symbols and copy it here. or 2. As well attach the thunar binary which produced the dump to the issue ( I would prefer 1., since 2. does not always work ... but we can take a try for 2. first, if you prefer )
Here is backtrace: #0 0x00007fc71c4d8a99 in () at /usr/lib/libgtk-3.so.0 #1 0x00007fc71c36a1a9 in () at /usr/lib/libgtk-3.so.0 #2 0x00007fc71c3803b5 in () at /usr/lib/libgtk-3.so.0 #3 0x00007fc71c36b55d in () at /usr/lib/libgtk-3.so.0 #4 0x00007fc71c3802f0 in () at /usr/lib/libgtk-3.so.0 #5 0x00007fc71c380346 in () at /usr/lib/libgtk-3.so.0 #6 0x00007fc71c36bef4 in () at /usr/lib/libgtk-3.so.0 #7 0x00007fc71ab63b60 in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0 #8 0x00007fc71ab44259 in () at /usr/lib/libgobject-2.0.so.0 #9 0x00007fc71ab45a7d in g_object_new_with_properties () at /usr/lib/libgobject-2.0.so.0 #10 0x00007fc71ab46532 in g_object_new () at /usr/lib/libgobject-2.0.so.0 #11 0x00007fc71c388a7b in () at /usr/lib/libgtk-3.so.0 #12 0x00007fc71c56f34a in () at /usr/lib/libgtk-3.so.0 #13 0x00007fc71ab63b60 in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0 #14 0x00007fc71ab44259 in () at /usr/lib/libgobject-2.0.so.0 #15 0x00007fc71ab46180 in g_object_new_valist () at /usr/lib/libgobject-2.0.so.0 #16 0x00007fc71ab4650a in g_object_new () at /usr/lib/libgobject-2.0.so.0 #17 0x000055d9cd3588e6 in thunar_session_client_restore (session_client=0x7fc704008130) at thunar-session-client.c:317 #18 0x000055d9cd3588e6 in thunar_session_client_new (session_id=<optimized out>) at thunar-session-client.c:480 #19 0x000055d9cd321081 in thunar_application_startup (gapp=0x55d9cdcf7110) at thunar-application.c:363 #20 0x00007fc71ab3ea4d in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0 #21 0x00007fc71ab51f18 in () at /usr/lib/libgobject-2.0.so.0 #22 0x00007fc71ab5a6f6 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0 #23 0x00007fc71ab5b130 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0 #24 0x00007fc71ae24cf3 in g_application_register () at /usr/lib/libgio-2.0.so.0 #25 0x00007fc71ae25540 in () at /usr/lib/libgio-2.0.so.0 #26 0x00007fc71ae258e2 in g_application_run () at /usr/lib/libgio-2.0.so.0 #27 0x000055d9cd3170db in main (argc=4, argv=0x7fff25fa1bc8) at main.c:161 Tried attaching binary, larger than 1000 KB. Compressed lowest was 1021K.
Thank's ! That backtrace sheds some light on the problem. It looks like thunar does not crash on logout, but on the following login, since the method which crashes is "thunar_session_client_restore" (which is called at startup of thunar ) There is a "ifdef" taking care to only trigger the restore mechanism if "libsm" is available. If libsm is not present, thunar should just start without the attempt to restore anything. I have libsm6 installed on my system (version 2:1.2.2 ) .. can you please check if you have it installed, and if so, check which version you have ?
From Manjaro: extra/libsm 1.2.2-3 [installed] However, locate for libsm6 shows nothing.
Seems to be the same thing .. we both run v1.2.2 of it. Will try to further investigate when I have time.
Regarding "locate", the library is called: libSM.so.6 locate libSM.so.6 gives me the following (debian stretch) /usr/lib/x86_64-linux-gnu/libSM.so.6 /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1
From Arch/Manjaro: # locate libSM.so.6 /usr/lib/libSM.so.6 /usr/lib/libSM.6.0.1 /usr/lib32/libSM.so.6 /usr/lib32/libSM.so.6.0.1 multilib doesn't seem to be related because it is not on arch machine.
Sorry that was typed in manually, second entry is the same, /usr/lib/libSM.so.6.0.1
Finally I can reproduce the bug .. but I need to do some hacks for that, and I dont know yet if it tells me something at all. - It is possible to pass "--sm-client-id=<something>" to thunar to restore a session - When nothing is passed, a new session is created in $HOME/.cache/sessions, named Thunar-<SomeHExNumber>. This file will be removed when thunar is closed. So here what I did: - copy the session file to "Thunar-debug.session" so that it will not be removed on close - pass some random session id into the argument "--sm-client-id" (no idea how to find a sane value) - hard-code path of "Thunar-debug.session" into "thunar_session_client_restore" , so that it will be used instead of whatever --> This will result in the same backtrace I first should get a better understanding of session-id management ... will further debug when I find time.
Possibly related, since it causes session-manager to dont a safe a Thunar session: Bug #15008 Could you take a try for the patch attached there ? Does it make a difference if you remove all thunar session data ? rm $HOME/.cache/sessions/Thunar-*
Hello. On Arch, I tried thunar-git from AUR before realizing version number was older, but these were my findings: thunar-git 1.8.1.r383.gb4d412ab-1: + does not dump core + restores thunar on login, with tabs and all - hangs on logout for several seconds thunar 1.8.2.2: - dumps core on next login - does not restore thunar on login - hangs on logout for several seconds thunar 1.8.2.2 with patch: - dumps core on next login - does not restore thunar on login + exits immediately Removing session cache doesn't seem to do anything different, but some of my testing is limited or could be wrong. It could prevent a coredump, but it would not restore the state of thunar so purpose of saving it is gone.
Backtrace of 1.8.2-2 with patch is same as prior: https://bugzilla.xfce.org/show_bug.cgi?id=14509#c8 Backtrace of 1.8.2-2 without patch: #0 0x00007fe8387cc010 in () at /usr/lib/libgtk-3.so.0 #1 0x00007fe8386710a6 in () at /usr/lib/libgtk-3.so.0 #2 0x00007fe838691796 in () at /usr/lib/libgtk-3.so.0 #3 0x00007fe83867c90b in () at /usr/lib/libgtk-3.so.0 #4 0x00007fe8386916d0 in () at /usr/lib/libgtk-3.so.0 #5 0x00007fe838691726 in () at /usr/lib/libgtk-3.so.0 #6 0x00007fe83867d2e4 in () at /usr/lib/libgtk-3.so.0 #7 0x00007fe837c3a7c7 in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0 #8 0x00007fe837c57259 in () at /usr/lib/libgobject-2.0.so.0 #9 0x00007fe837c5875d in g_object_new_with_properties () at /usr/lib/libgobject-2.0.so.0 #10 0x00007fe837c5886a in g_object_new () at /usr/lib/libgobject-2.0.so.0 #11 0x00007fe838699f3b in () at /usr/lib/libgtk-3.so.0 #12 0x00007fe83887cbf3 in () at /usr/lib/libgtk-3.so.0 #13 0x00007fe837c3a7c7 in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0 #14 0x00007fe837c57259 in () at /usr/lib/libgobject-2.0.so.0 #15 0x00007fe837c57ea4 in g_object_new_valist () at /usr/lib/libgobject-2.0.so.0 #16 0x00007fe837c5883a in g_object_new () at /usr/lib/libgobject-2.0.so.0 #17 0x000055f882ac2b86 in () #18 0x000055f882a8a351 in () #19 0x00007fe837c533c5 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0 #20 0x00007fe837c40348 in () at /usr/lib/libgobject-2.0.so.0 #21 0x00007fe837c4401e in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0 #22 0x00007fe837c44a80 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0 #23 0x00007fe837d11b8f in g_application_register () at /usr/lib/libgio-2.0.so.0 #24 0x00007fe837d12e27 in () at /usr/lib/libgio-2.0.so.0 #25 0x00007fe837d1289b in g_application_run () at /usr/lib/libgio-2.0.so.0 #26 0x000055f882a800db in () #27 0x00007fe83793d223 in __libc_start_main () at /usr/lib/libc.so.6 #28 0x000055f882a801fe in ()
Thanks for testing ! So it looks like the bug got fixed together with thunar-git 1.8.1.r383.gb4d412ab-1. From the name I would assume that it points to current master, which is good. Since it restores thunar windows, I assume it includes the patch of Bug #14969 So my guess would be that the patch of #14969 makes the difference ... please as well add this patch to thunar 1.8.2.2, and let me know if it fixes the problem for you. - hangs on logout for several seconds > The Hang on logout patch is not pushed to master yet .. so this makes sense
Hello. I can confirm that with both patches applied, Thunar 1.8.2-2 on Arch is behaving properly. + does not dump core + restores thunar on login, with tabs and all + exits immediately Thank you!
Yay, good news ! So I will close this report as a duplicate of #14969 Both fixes will be released in 1.8.3 soon. *** This bug has been marked as a duplicate of bug 14969 ***