Created attachment 9035 gdb backtrace (with gef formatting) When un-mounting a USB hard drive while Tree view is active, Thunar segfaults. Doesn't seem to happen with bookmark view. Also, as a similar device is connected, after it appears in tree view, Thunar segfaults once I have clicked on the device in Tree view in order to mount it. Backtrace shows the same line of source code as when unmounting. See attached file. Thanks for your time~
Thanks for reprting ! The backtrace is a beginning, though it does not help too much in this case.. Looks like for some unknown reason there is rubbish in "node". There is even a NULL check, which seems not to help. Another possibility would be, that between the NULL check and line 604 "node" got invalid. I am sorry, I cannot reproduce the bug in order to properly debug it. My USB hard drive is unmounting just fine in tree-view Does this bug trigger for you on each unmount ? Do you unmount it by pressing "unmount" in thunar for the context menu ?
Created attachment 9041 gdb/gef backtrace pointing at line 821 I have hit a similar crash while mounting, pointing at line 821 thunar_tree_model_unref_node() this time. Seems closely related. Here is my process to emulate having an USB mass storage device being plugged in (instead of using a real drive) and the result is the same: # dd bs=1M count=64 if=/dev/zero of=/path/to/fake_storage_file // create a partition # cfdisk fake_storage_file # fdisk -lu backing file // grab the starting offset, multiply by sector size (usually 512) # sudo losetup -o 1048576 /dev/loop1 fake_storage_file # sudo mkfs.ext4 /dev/loop1 // remove the loopdevice (because it's probably not needed actually) # sudo losetup -d /dev/loopX // load the fake usb root hub module # sudo modprobe dummy_hcd // add the fake usb device while tree view active # sudo modprobe g_mass_storage file=/path/to/fake_storage_file // thunar will crash somewhere after clicking the new item and mounting it. Still trying to determine when/where exactly. // remove the fake usb device # sudo modprobe -r g_mass_storage Apparently it's de-referencing a null pointer? mov rax, QWORD PTR [rax] while rax is apparently "0x0". Sorry, I still don't know much about debugging, but I'll try throwing some wrenches in there and see if it sparkles some more.
Addendum, it's crashing consistently when un-mounting, and it hits either line 604 or 821.
Thunar doesn't crash when compiled with make CFLAGS="-g -O0"... interesting. Apparently the "node" is being optimized by the compiler. When it's not optimized, it doesn't crash. By the way, the crash doesn't happen because of the un-mounting, rather it happens when the tree view has to be updated. If you don't click anywhere, it won't need to update the view, and won't crash until then.
I'm making small progress on this. The issue most likely comes from the iterators. iter->user_data ends up being 0x0 (null pointer) which is then assigned to the node. I don't understand why it's getting past the null checks though. The compiler optimization is really troubling me too. I need to study the logic some more in order to figure out how all of this works (https://developer.gnome.org/gtk3/stable/GtkTreeModel.html).
Thanks for all the details .. currently trying to as well emulate the storage device ... though I am stuck: (In reply to fuank from comment #2) > Created attachment 9041 > gdb/gef backtrace pointing at line 821 > > I have hit a similar crash while mounting, pointing at line 821 > thunar_tree_model_unref_node() this time. Seems closely related. > > Here is my process to emulate having an USB mass storage device being > plugged in (instead of using a real drive) and the result is the same: > > # dd bs=1M count=64 if=/dev/zero of=/path/to/fake_storage_file > // create a partition > # cfdisk fake_storage_file > > # fdisk -lu backing file > // grab the starting offset, multiply by sector size (usually 512) > # sudo losetup -o 1048576 /dev/loop1 fake_storage_file > # sudo mkfs.ext4 /dev/loop1 "fdisk -lu backing file" What is the "backing file" ? You ment : "fake_storage_file" ? "fdisk -lu fake_storage_file" gives me: > Disk fake_storage_file: 64 MiB, 67108864 bytes, 131072 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes ... not sure where to get a starting offset from that output
Yes, sorry "backing file" was meant to be "fake_storage_file". > Disk /fake_storage_file: 64 MiB, 67108864 bytes, 131072 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0xdbe8c6ec > > Device Boot Start End Sectors Size Id Type > /fake_storage_filep1 2048 131071 129024 63M 83 Linux The sector size is 512, but fdisk should also report the starting sector of the "partition/file" in the "Start" column, in most cases it should be 2048, so 512*2048=1048516 which is the starting byte we give to losetup. More info there: https://linux-sunxi.org/USB_Gadget/Mass_storage https://unix.stackexchange.com/questions/373569/emulating-usb-device-with-a-file-using-g-mass-storage-udc-core-couldnt-find Be wary that you need to remove the kernel module before suspending your computer, or you may end up having the fake usb device blocking the entire system, requiring a hard reboot! Sorry for the confusion. I haven't had time to look more into it yet but I sure love learning more about gdb. ;)
*** This bug has been marked as a duplicate of bug 15172 ***