Fedora 29 Thunar 1.8.4 $ rpm -qa \*mtp\* gvfs-mtp-1.38.1-2.fc29.x86_64 libesmtp-1.0.6-16.fc29.x86_64 libmtp-examples-1.1.16-1.fc29.x86_64 libmtp-1.1.16-1.fc29.x86_64 esmtp-1.2-12.fc29.x86_64 Kyocera DuraXV LTE with Camera Model: E4610 (Media Device MTP) When I click on my cell phone, Thunar crashes. When I reopen Thunar and click, it does not crash the second time, but it also does not see anything (there are pictures)
Figure out why the second time I see nothing. It is my phone's doing. I have to set mtp device EVERY time I plug the usb cable in. So now I can see things with Thunar, the second time.
A backtrace would be helpful to figure out what's going wrong. Fedora seems to provide packages with debug symbols: https://fedoraproject.org/wiki/StackTraces#What_are_debugging_symbols.2C_and_why_are_they_important.3F Once you have Thunar with debug info, you can follow the instructions provided here: https://wiki.xfce.org/howto/debug
> Figure out why the second time I see nothing Possible related: Bug #15071
Was this addressed in Xfce 4.14pre2? I have been using Nautilus, but I have to reboot afterwards as it slows my file system down to a crawl after using Nautilus on MTP devices. (dump goes from 48 minutes to 11 hours.)
Nope, was not addressed. When it gets addressed, you will see it here. As Andre Miranda told, a backtrace with debug symbols probably would help alot. Did you get the crashes as well with older thunar versions ? When did it start ? (Possibly you can use "git bisect" to identify the commit which introduced the regression)
As well possibly related: Bug #14719 ... does it change something for you to revert this commit ?
(In reply to Andre Miranda from comment #2) > A backtrace would be helpful to figure out what's going wrong. > Fedora seems to provide packages with debug symbols: > https://fedoraproject.org/wiki/StackTraces#What_are_debugging_symbols. > 2C_and_why_are_they_important.3F > Once you have Thunar with debug info, you can follow the instructions > provided here: https://wiki.xfce.org/howto/debug Sorry, I have no idea how to get the dubugging symbols installed on Fedora. If you could tell me how to do this, I love to run a trace for you. This issue is really easy to reproduce yourself. 1) plug an MTP device, like yo cell phone into your computer 2) open thunar and click on the MTP device. It will come down around your ears. 3) If you open Thunar a second tie and click on the MTP device it will work. -T
Created attachment 8726 core backtrace Another user reported a similar bug in Fedora. Attached is the core_backtrace generated.
(In reply to Todd from comment #7) > Sorry, I have no idea how to get the dubugging symbols installed on Fedora. > If you could tell me how to do this, I love to run a trace for you. The links I have mentioned before explain all of this in details. > This issue is really easy to reproduce yourself. > > 1) plug an MTP device, like yo cell phone into your computer > > 2) open thunar and click on the MTP device. It will come down around your > ears. > > 3) If you open Thunar a second tie and click on the MTP device it will > work. I'm using Arch Linux, gvfs-mtp 1.40.1 and Thunar from git master, following your steps it doesn't crash here. (In reply to Mukundan Ragavan from comment #8) > Created attachment 8726 > core backtrace Unfortunately this backtrace is not useful, it doesn't tell where Thunar crashed. If I'm not mistaken gdb can load backtraces and get more info from binaries with debug symbols, I tried this once but it didn't work.
> This issue is really easy to reproduce yourself. Sorry, I as well cannot reproduce. Using Thunar master and a linage OS 15.1 (Android 8.1.0)
(In reply to Andre Miranda from comment #2) > A backtrace would be helpful to figure out what's going wrong. > Fedora seems to provide packages with debug symbols: > https://fedoraproject.org/wiki/StackTraces#What_are_debugging_symbols. > 2C_and_why_are_they_important.3F > Once you have Thunar with debug info, you can follow the instructions > provided here: https://wiki.xfce.org/howto/debug Well now... $ rpm -qa Thunar Thunar-1.8.6-1.fc30.x86_64 # dnf --enablerepo=fedora-debuginfo --enablerepo=updates-debuginfo install Thunar-debuginfo Thunar-debugsource ... Running transaction Preparing : 1/1 Installing : Thunar-debugsource-1.8.6-1.fc30.x86_64 1/2 Installing : Thunar-debuginfo-1.8.6-1.fc30.x86_64 2/2 Running scriptlet: Thunar-debuginfo-1.8.6-1.fc30.x86_64 2/2 Verifying : Thunar-debuginfo-1.8.6-1.fc30.x86_64 1/2 Verifying : Thunar-debugsource-1.8.6-1.fc30.x86_64 2/2 Installed: Thunar-debuginfo-1.8.6-1.fc30.x86_64 Thunar-debugsource-1.8.6-1.fc30.x86_64 And now it will not crash, whether in gdb or native. And # dnf remove Thunar-debugsource Thunar-debuginfo And it still won't crash. What the heck????
I am getting this on Fedora 30. See Fedora bugzilla 1723996 for details. It is much worst than the occasional crashing I was getting previously on Fedora 28.
Today's testing. I have removable device to auto mount on hot plug, but the phone is not mounting. In a workspace with no apps running, I can see the phone icon and I right click to mount it. All copies of thunar crash. I start two instances of thunar and get one to show the content of the phone directory and the other the directory for the files to move. At this point thunar stops responding. I looked at top and once I saw something that looked like an mtp process, but I was not fast enough with the q to stop the screen update. After some period of time, (perhaps 2 min?) thunar started responding, and I was able to drag the files onto the phone. Pretty much back to the situation on F28 for the past 6 months: Thunar crashing, but able, with patience, to copy files.
(In reply to Todd from comment #11) > # dnf remove Thunar-debugsource Thunar-debuginfo > > And it still won't crash. > > What the heck???? Possibly still the old binary was running as daemon ? Try "thunar -q;thunar" to make sure the daemon is quit. Bug not showing with debug symbols is bad :/ .. possibly related to timing. (In reply to Robert Moskowitz from comment #13) > See Fedora bugzilla 1723996 for details. Cannot access the bug: "You are not authorized to access bug #1723996. To see this bug, you must first log in to an account with the appropriate permissions." Is there a backtrace with debug symbols inside ? > All copies of thunar crash. Could you please as well take a try to get a backtrace with debug symbols? Andre MIranda already linked a "howto" in comment #2
(In reply to Todd from comment #11) > What the heck???? The answer its that Thunar now likes my cell phone but has decided to hates my wife's Android tablet: Lenovo TAB 2 A10-70F, Android 6.0, Kernel 3.18.19 And after reinstalling the debuggers again, it no long will crash. Uninstalling the debugger and it still won't crash Ah Ha, if you unplug the tablet and plug it back in again, the problem comes back. Reinstalling he dubuggers and it still will not come back, even after rebooting the Android. But what I have noticed is that I get a new entry when running it under the debugger that I do not get without it: ".one MediaTek_Lenovo_01234...". It appears after I click on "Lenovo". Prior to installing the debugger, clicking on "Lenovo" that is when this thing comes down around my ears. I will upload a screen shot.
Created attachment 8736 New entry running the debugger New entry after installing the debugger
Afaik MTP is part of gvfs/gvfs-backends, which is used by thunar. Can you reproduce the bug as well with nautilus ? (Since it as well uses gvfs/gvfs-backends)
The debugger code is slowing the process down a bit, meaning this is a timing issue.
Hi, $ rpm -qa \*Thunar\* Thunar-1.8.9-2.fc30.x86_64 Thunar-debugsource-1.8.9-2.fc30.x86_64 Thunar-debuginfo-1.8.9-2.fc30.x86_64 This turkey will not reproduce when run from gdb. Or afterwards either. Before running gdb, every other time it is run, it crashes. But I have since learned how to do core dumps with systemd (not so hard once you get over the learning curve). And I do have one all saved and pretty for you guys: PID: 3031 (Thunar) UID: 500 (todd) GID: 100 (users) Signal: 11 (SEGV) Timestamp: Tue 2019-09-03 16:31:05 PDT (9min ago) Command Line: /usr/bin/Thunar --daemon Executable: /usr/bin/thunar Control Group: /user.slice/user-500.slice/user@500.service/thunar.service Unit: user@500.service User Unit: thunar.service Slice: user-500.slice Owner UID: 500 (tony) Boot ID: 35e5bac8844741e58cb07cabe47ffd7f Machine ID: 25f870556c344b599c639eb386296fa2 Hostname: foo.local Storage: /var/lib/systemd/coredump/core.Thunar.500.35e5bac8844741e58cb07cabe47ffd7f.3031.1567553465000000.lz4 Message: Process 3031 (Thunar) of user 500 dumped core. # ls -al Thunar.coredump -rw-r--r--. 1 root root 91877376 Sep 3 16:40 Thunar.coredump It is 92 MB long. If a core dump will help, let me know where I can upload it. If too big for this bug system, privately send me an eMail address and I will upload it to my drop box account and link it to that eMail address. -T
Nice ! Dont upload the coredump .. I cannot make use of it. Instead debug it with gdb: gdb <programm> <coredump> and than type "bt" to get the backtrace
$ gdb /usr/bin/Thunar Thunar.coredump (gdb) bt #0 0x000055adcdf3910c in thunar_tree_model_get_value (tree_model=0x55adcf6a4ad0, iter=0x7fd82016fd00, column=1, value=0x7ffe7d812520) at thunar-tree-model.c:604 #1 0x00007fd82f046ff8 in () at /lib64/libgtk-3.so.0 #2 0x00007fd82e8f1a2e in g_hash_table_foreach () at /lib64/libglib-2.0.so.0 #3 0x00007fd82f046ecf in () at /lib64/libgtk-3.so.0 #4 0x00007fd82f04c8af in () at /lib64/libgtk-3.so.0 #5 0x00007fd82f2ed015 in () at /lib64/libgtk-3.so.0 #6 0x00007fd82e9ea996 in () at /lib64/libgobject-2.0.so.0 #7 0x00007fd82ea071c8 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #8 0x00007fd82ea07973 in g_signal_emit () at /lib64/libgobject-2.0.so.0 #9 0x00007fd82f048a63 in gtk_cell_area_apply_attributes () at /lib64/libgtk-3.so.0 #10 0x00007fd82f272038 in () at /lib64/libgtk-3.so.0 #11 0x00007fd82f279dec in () at /lib64/libgtk-3.so.0 #12 0x00007fd82f27a2e3 in () at /lib64/libgtk-3.so.0 #13 0x00007fd82ee2cf1d in () at /lib64/libgdk-3.so.0 #14 0x00007fd82e8ff7db in () at /lib64/libglib-2.0.so.0 #15 0x00007fd82e902edd in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #16 0x00007fd82e903270 in () at /lib64/libglib-2.0.so.0 #17 0x00007fd82e903313 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #18 0x00007fd82eb0e495 in g_application_run () at /lib64/libgio-2.0.so.0 #19 0x000055adcded14bd in main (argc=2, argv=0x7ffe7d812e58) at main.c:161
Nice, thanks for the backtrace ! Hmm, that's a hard one. thunar-tree-model.c:604 does not look suspicious. There is a != NULL check for "iter->user_data" on top. And "node = iter->user_data;" So it looks like "iter->user_data" contains an invalid value. Possibly it is required to initialize iter->user_data with NULL , to ensure that the check triggers. Or it needs to be set to NULL when the related GNode is removed. ... to be further investigated. Here the realted code: https://git.xfce.org/xfce/thunar/tree/thunar/thunar-tree-model.c?h=xfce-4.14#n590
The same crash was reported in Bug #15972.
(In reply to Theo Linkspfeifer from comment #23) > The same crash was reported in Bug #15972. Yes, I overlooked that duplication. Added "tree-view" into title, since it seems to happen only there
While I still cannot reproduce the crash, I can reproduce some GLib-GIO-CRITICAL messages by doing the following: (It would not be the first time that on my system I only see critical messages, where other systems crash) 1. run thunar, open tree-view 2. plugin some flashdrive, wait till it is mounted in thunar 3. Open the root folder of the flashdrive 4. Right click on the flashdrive in the tree-view and select "eject" Here the critical message: (thunar:25808): GLib-GIO-CRITICAL **: 01:56:38.143: g_file_get_uri: assertion 'G_IS_FILE (file)' failed thunar_standard_view_new_files path: (null) (thunar:25808): thunar-CRITICAL **: 01:56:38.143: thunar_file_cache_lookup: assertion '(((__extension__ ({ GTypeInstance *__inst = (GTypeInstance*) ((file)); GType __t = ((g_file_get_type ())); gboolean __r; if (!__inst) __r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t) __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r; }))))' failed (thunar:25808): GLib-GIO-CRITICAL **: 01:56:38.143: g_file_has_parent: assertion 'G_IS_FILE (file)' failed
*** Bug 15723 has been marked as a duplicate of this bug. ***
*** Bug 15972 has been marked as a duplicate of this bug. ***
Created attachment 9592 backtrace of crash I can reproduce the crash using Thunar 1.8.12 from the debian repos, see attached backtrace. I took some screenshots of the process, see https://imgur.com/a/6uI743I I did the following (these steps reliably reproduce the crash in Thunar 1.8.12 on my system) (1) With the side pane in tree view, I expanded the "File System" row in the side pane so that my screen looked like screenshot 1. Expanding the "File System" like this seems to be necessary for reproducing this crash - if "File System" is collapsed, then I can do all of the following steps with no crash and no errors except the thunar-volman warnings. (2) Insert a USB flash drive (the one I used has label "Debian 10.2.0", as in the screenshots). When this appears in Thunar, it appears on top of (that is, obscuring) the "File System" text in the side pane, as shown in screenshot 2. If you mouseover the side pane, this gets corrected and the drive appears above the "File System" text as expected, and you get what is shown in screenshot 3. Also, the following messages happen when you insert the stick thunar-volman: Unsupported USB device type "usb". thunar-volman: Unsupported USB device type "usb-storage". (thunar:27746): Gtk-CRITICAL **: 16:44:38.836: ../../../../gtk/gtktreeview.c:6711 (validate_visible_area): assertion `has_next' failed. There is a disparity between the internal view of the GtkTreeView, and the GtkTreeModel. This generally means that the model has changed without letting the view know. Any display from now on is likely to be incorrect. and the GtK-CRITICAL then keeps being repeated as you move the mouse around or click in the sidepane. (3) Click on the USB stick in the side pane - this immediately triggers the crash. Doing the above with the current Thunar master does not cause a segfault, but does trigger all sorts of warnings - I am currently investigating these and I'll report back when I know more.
Created attachment 9595 possible fix So this patch seems to fix this in both master and 1.8.12 on my system. All it does is move one line of code a few lines lower, but when I apply it to master or 1.8.12, I can do the steps in my previous comment with no segfaults or error messages (apart from the thunar-volman messages which still happen - so maybe theses messages are unrelated to this bug?). Does it work for anyone else?
I can reproduce the wall of GtK-CRITICALs, and I can confirm that the patch fixes them. Excellent research Reuben! Well done, thanks alot for that fix ! I guess thunar_tree_model_node_insert_dummy calls "gtk_tree_model_row_inserted" on a path/iter which was not inserted to the tree-model yet. It would be great if somebody who experienced a crash could as well test the patch, in order to check if the crash got fixed with it ! ... after that I guess it is time for me to release thunar 1.8.13 ;)
The proposed fix reverts this commit: https://git.xfce.org/xfce/thunar/commit/?id=33a155c1bded0487396b609aad19730a9f201bbb
Ah, thanks for that Theo, I had not seen that commit (my git skills are still basically limited to checkouts and commits, I'm afraid). Alex, can you remember the details of the bug (bug #14960) you were trying to fix with that commit? It's probably not a good idea to bring back that bug by fixing this one, so maybe we should look into it before we try to do anything more?
Thanks Reuben Green. I've tested the patch and it seems to fix the problem as I reported in https://bugzilla.xfce.org/show_bug.cgi?id=15972
(In reply to Theo Linkspfeifer from comment #31) > The proposed fix reverts this commit: > https://git.xfce.org/xfce/thunar/commit/ > ?id=33a155c1bded0487396b609aad19730a9f201bbb Gna ... actually the code looked familar, so I tried the following: git blame thunar-tree-model.c -L :thunar_tree_model_device_added ... looks like I failed to use git blame :F .. how did you find the commit ? (In reply to Reuben Green from comment #32) > Alex, can you remember the details of the bug (bug #14960) you were trying > to fix with that commit? It's probably not a good idea to bring back that > bug by fixing this one, so maybe we should look into it before we try to do > anything more? Sorry, I dont remeber ... I should have added more details when I worked on it. The bug mentioned that the freeze happened only rarely. I would suggest to push your patch and we all test the fixed thunar master for a few days. If nobody investigates a freeze, I would do a release. You think that sounds reasonable ? (In reply to fuank from comment #33) > Thanks Reuben Green. I've tested the patch and it seems to fix the problem > as I reported in https://bugzilla.xfce.org/show_bug.cgi?id=15972 Thanks alot for testing! (And sorry for causing you all the trouble with my old fix)
(In reply to alexxcons from comment #34) > The bug mentioned that the freeze happened only rarely. I would suggest to > push your patch and we all test the fixed thunar master for a few days. If > nobody investigates a freeze, I would do a release. You think that sounds > reasonable ? Yes, that sounds fine to me!
Unfortunately, I cannot test this until it hits Fedora30 which I am on 1.8.11. I just checked, and there are no pending updates via dnf. It is so bad here, that I have set up my phone to put everything on the uSD card and I keep pulling that out and inserting that in my notebook. Of course THAT crashes thunar on the auto mount, but it restarts 'easily' (no fun when I have 6 copies open to different directories). Oh and I always use Tree view.
Reuben Green referenced this bugreport in commit 977ee3cf51f81dd61f50fedf331a64caa520d27a Fix for crash when inserting USB device in tree mode. (Bug #15172) https://git.xfce.org/xfce/thunar/commit?id=977ee3cf51f81dd61f50fedf331a64caa520d27a
Reuben Green referenced this bugreport in commit 35055c227e46d68e9f46fb4eb9c2854e5ab1c4b3 Fix for crash when inserting USB device in tree mode. (Bug #15172) https://git.xfce.org/xfce/thunar/commit?id=35055c227e46d68e9f46fb4eb9c2854e5ab1c4b3
ok, pushed to master and 4.14 and installed 4.14 on my system. I'll use tree-view for a week. If none of you reports freezes, I would do a release next weekend. (More testers would be great!) (In reply to Robert Moskowitz from comment #36) > It is so bad here, that I have set up my phone to put everything on the uSD > card and I keep pulling that out and inserting that in my notebook. Of > course THAT crashes thunar on the auto mount, but it restarts 'easily' (no > fun when I have 6 copies open to different directories). > > Oh and I always use Tree view. If you dont want to use shortcuts view, there is as well the option to build thunar from source. Here a manual: https://wiki.xfce.org/thunar/dev/build_and_run
No freezes so far, so I guess it should be fine to close this case. (Sorry again for causing all that trouble with my malicious commit in the first place :F) I'll see if I can release thunar 1.8.13 tomorrow
*** Bug 15212 has been marked as a duplicate of this bug. ***