About a month ago Thunar started crashing when I tried to open the trash or browse the network. Occasionally the trash will open if it's not empty, but it always crashes when it is empty. I reinstalled Manjaro and was surprised when the problem persisted, and then noticed it was happening on my Manjaro server as well. I also recently installed the latest Manjaro on a friends laptop and desktop, and the same problem occurs on those systems also. I've temporarily worked around the problem by installing Nautilus and setting it as the default file manager. Nautilus works perfectly both opening the trash and browsing the network, so the problem definitely resides within Thunar. The Thunar version is displayed as "1.8.1git-480dfc." To assist in your debugging I created two backtrace files with "coredumpctl dump <PID>" and have attached them to this bug report in a single file named "thunar.crash.core.7z" that contains the two coredumpctl output files. "thunar.network_browse_crash.core" is relatively short and was taken after opening Thunar and clicking on "Network", which causes an immediate segfault crash. "thunar.network_browse_crash.core" is fairly long and was taken after trying to open the trash, which again cause a segfault. Occasionally a pop up will also display after the trash crash that says "Failed to execute default File Manager. Input/output error." I'm an embedded systems designer, though not a Linux developer. So if you need any further information or tests please let me know. I love Thunar, and having to use Nautilus is cumbersome. Thank you for your help and hard work.
Oh wow, unfortunately I can't attach the core dump files because they're over 1MB. One is 1.3MB and the other is 1.5MB, with 7zip compression. Please give me a link where I can upload the files and I'll do it ASAP. I don't see any way to get around the tiny 1MB limit.
Thanks alot for reporting ! Usually I am fine with the backtrace, if it was generated with debug symbols. Afaik I only can make use of the core dump via gdb if you as well upload the thunar binary which created it. ( My own thunar binary may not match ) For uploading the core dump and the binary, pick whatever service you like. https://uploadfiles.io ? or possibly https://wetransfer.com/ ... I have no idea which one whould be picked. ( Reminder to myself: Ask our IT if we can get bigger attachments supported )
(In reply to alexxcons from comment #2) > Thanks alot for reporting ! > > Usually I am fine with the backtrace, if it was generated with debug symbols. > > Afaik I only can make use of the core dump via gdb if you as well upload the > thunar binary which created it. ( My own thunar binary may not match ) > For uploading the core dump and the binary, pick whatever service you like. > https://uploadfiles.io ? or possibly https://wetransfer.com/ ... I have no > idea which one whould be picked. ( Reminder to myself: Ask our IT if we can > get bigger attachments supported ) Oh, I see. Yes, it would be nice if there were a developer secured site for uploading core dumps and other possibly sensitive data, but for now I used the first public upload service you mentioned. Here are the URLs for the files: https://ufile.io/y2ktr thunar.network_browse_crash.core.7z https://ufile.io/f6x88 thunar.trash_open_crash.core.7z https://ufile.io/q5jks thunar binary
Thanks! Hmm .. wonder if I miss something for debugging a coredump in general "gdb /path/to/downloaded/thunar core" gives me: .... warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not at the expected address (wrong library or version mismatch?) warning: Could not load shared library symbols for 103 libraries, e.g. /usr/lib/libthunarx-3.so.0. ... .. and a useless backtrace: >(gdb) bt >#0 0x00005601dc9ea050 in ?? () >#1 0x00005601dca28378 in ?? () >#2 0x00007fa7f90038d1 in ?? () >#3 0x00005601dd244430 in ?? () >#4 0x00007fa700000000 in ?? () >#5 0x0000000000000000 in ?? () Could you please take a try on your system, and just put the backtrace here ? ( Dont forget to install debug symbols for thunar) Here is a distribution specific manual on how to get backtraces: https://docs.xfce.org/contribute/bugs/start#backtraces
(In reply to alexxcons from comment #4) > Thanks! Hmm .. wonder if I miss something for debugging a coredump in general > "gdb /path/to/downloaded/thunar core" gives me: > .... I apologize, but this appears to be a Manjaro specific issue arising from their use of an old git release, specifically 1.8.1git-480dfc. The current release is 1.8.3 I discovered it when I went to try and compile their "thunar-gtk" from their version of ABS, which I accessed with "buildtree -a." This created a git directory with their package build files under "/var/cache/manjaro-tools/pkgtree/packages-archlinux/packages". Though oddly as you can see they actually appear to be Arch packages. In any case, I never actually found a "thunar-gtk" so I'm assuming there's some other ABS like repository for it, but since thunar was there, and appeared to be a much later version. I compiled it both with and without the debug options and after some testing found it works perfectly. I also tested to make sure it's using GTK3 with "ldd /usr/bin/thunar | grep gtk" and it is indeed using "libgtk-3.so.0 => /usr/lib/libgtk-3.so.0" So I'm not sure what's going on, but Manjaro has a fairly convoluted set of XFCE packages right now. They have multiple different versions with and without the "-gtk3" suffix, and the default desktop package is xfdesktop-gtk3, which pulls in all these alternate packages like thunar-gtk3, xfce4-panel-gtk3 etc. After a bit of review I expect they've just lost track of what's going on as most all the packages actually appear to be GTK3, but as I said there are multiple versions of most things. So if you want you can close this bug, and I'll try to figure out how to communicate the problem to the Manjaro devs. I'm not quite sure how to go about though as it's more of a packaging issue related to using old unreleased git versions than an actual bug. Do you know the best way for me to do it? There seem to be myriads of bug reporting platforms, but that's probably just because I'm getting old and confused :) Where would I got to report this kind of thing directly to Manjaro? Thank you for your help by the way, and I apologize for my error. I should have tried a later version as soon as I saw that thunar was off an old git pull.
I meant "thunar-gtk3" above. I told you I was getting old and confused :)
Just to end this more cleanly I found and downloaded the current Manjaro thunar-gtk3 PKGBUILD and discovered that even though it claims to be building version 1.8.2-9.1 it's actually building 1.8.1git-480dfc. So I modified it to build 1.8.3-2 with the -gtk3 suffix and dependencies. This is important if you're using Manjaro because if you try to directly use the Arch package it conflicts with the Manjaro's GTK3 naming convention. So to save others time here is the PKGBUILD to create a working drop-in replacement for thunar-gtk3: PKGBUILD for Manjaro thunar-gtk3 ----------------------------------------------------------------------------------- # Maintainer: Evangelos Foutras <evangelos@foutrelis.com> # Contributor: Andrew Simmons <andrew.simmons@gmail.com> _pkgname=thunar pkgname=$_pkgname-gtk3 pkgver=1.8.3 pkgrel=2 pkgdesc="Modern file manager for Xfce" arch=('x86_64') url="http://thunar.xfce.org" license=('GPL2' 'LGPL2.1') groups=('xfce4') depends=('desktop-file-utils' 'libexif' 'hicolor-icon-theme' 'libnotify' 'libgudev' 'gtk3' 'exo-gtk3' 'libxfce4util-gtk3' 'libxfce4ui-gtk3' 'libpng') makedepends=('intltool' 'xfce4-dev-tools' 'xfce4-panel-gtk3') optdepends=('gvfs: for trash support, mounting with udisk and remote filesystems' 'xfce4-panel-gtk3: for trash applet' 'tumbler: for thumbnail previews' 'thunar-volman: manages removable devices' 'thunar-archive-plugin: create and deflate archives' 'thunar-media-tags-plugin: view/edit id3/ogg tags') source=(https://archive.xfce.org/src/xfce/$_pkgname/${pkgver%.*}/Thunar-$pkgver.tar.bz2 thunar-bz14946.patch::https://github.com/xfce-mirror/thunar/commit/4c0e17d7fc.patch) sha256sums=('c8fa2d55948c4137af6196419372250742790807d12293a804f543491298d32f' '23497c2472807b5268b5df3e707940326565f15c480fde755d4fd2f9a86bed8d') prepare() { cd "$srcdir/Thunar-$pkgver" # https://bugzilla.xfce.org/show_bug.cgi?id=14946 patch -Np1 -i ../thunar-bz14946.patch } build() { cd "$srcdir/Thunar-$pkgver" ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --enable-gio-unix \ --enable-gudev \ --enable-notifications \ --enable-exif \ --enable-pcre \ --disable-debug make } package() { cd "$srcdir/Thunar-$pkgver" make DESTDIR="$pkgdir" install # Remove file conflicting with nautilus # https://bugs.archlinux.org/task/61531 rm "$pkgdir/usr/share/dbus-1/services/org.freedesktop.FileManager1.service" } # vim:set ts=2 sw=2 et: -----------------------------------------------------------------------------------
Glad it works fine now for you. Possibly one of the bugfixes between thunar 1.8.1 and thunar 1.8.3 fixed your bug. Since it either is not a thunar issue at all, or it got fixed meanwhile, I will close this bug. If a should be wrong, please feel free to reopen !