GNOME Bugzilla – Bug 780354
GParted crashes when filenames are invalid UTF8 strings
Last modified: 2017-03-22 13:23:25 UTC
Created attachment 348415 [details] [review] Patch "fixing" described bug I have a USB stick that has FAT16 filesystem and a lot of bad files which filenames' are not valid UTF-8 strings. I have noticed GParted crashing, when the USB stick is plugged in but unmounted (but not ejected). When the USB stick is mounted I can operate GParted normally (but I have no idea if I can format the USB stick - I have preserved it for testing purposes). GParted crashes as soon as I unmount the USB stick through GParted. GParted crashes when scanning dics, to be exact in line 63 in file PipeCapture.cc [1], when advancing the iterator. As written in the Glib::ustring documentation [2] "The Glib::ustring iterated over must contain only valid UTF-8 data. If it does not, operator++(), operator--() and operator*() may make accesses outside the bounds of the string." I have patched the Glib::ustring recently adding ustring::make_valid() method [3], but I don't suppose it will be aired soon. As ustring::make_valid() is just a wrapper around g_utf8_make_valid() in Glib I tried to implement it in Utils.cc, but GParted uses old Glib. g_utf8_make_valid() was introduced in glib 2.52 [4]. I attach a patch that seems to resolve the problem, although I have no idea what is an overall impact of the rest of the program, as I have no understanding of the purpose of the function I have altered. You may apply this patch, but please be careful and see if it doesn't break anything else. [1]: https://git.gnome.org/browse/gparted/tree/src/PipeCapture.cc?h=GPARTED_0_28_1#n63 [2]: https://developer.gnome.org/glibmm/stable/classGlib_1_1ustring__Iterator.html#details [3]: https://bugzilla.gnome.org/show_bug.cgi?id=780075 [4]: https://developer.gnome.org/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-make-valid
Thank you for reporting the bug and writing a patch. The symptoms seem very similar to bug 777973 - Segmentation fault on bad disk. Please attach a backtrace so that I can confirm. Also note that I am working on making PipeCapture::OnReadable() method robust and faster as part of bug 777973. Thanks, Mike I am sure you don't need these, but here are our standard instructions for ... How to capture a backtrace from a core dump ------------------------------------------- 1) Turn off any OS core dump capturing, ensuring: cat /proc/sys/kernel/core_pattern reports just "core" Some methods to do this, depending on distro version, are: * service abrt-ccpp stop (RedHat/Fedora pre systemd) * systemctl stop abrtd (RedHat/Fedora with systemd) * sudo service apport stop (Ubuntu) 2) Increase core dump limit and run GParted as root Either: ulimit -c unlimited sudo gparted or: su - root ulimit -c unlimited gparted 3) Perform crashing action 4) Capture backtrace ls -lrt core* which gpartedbin gdb `which gpartedbin` {COREFILE} --batch --quiet \ -ex 'info threads' -ex 'thread apply all backtrace' \ -ex quit > backtrace.log Please paste the terminal output when running gparted and the contents of the backtrace.log file.
Created attachment 348464 [details] Backtrace from crashed gparetd commit b4349f851 backtrace from commit b4349f851ef129a1b1b450c16a5ab6fd7fbc1958
Created attachment 348465 [details] Backtrace from crashed gparted (v 0.28.1-1, packaged version for ArchLinux) This is a backtrace from ArchLinux packaged version of gparted v 0.28.1-1.
Thank you for your detailed answer. Indeed, it seems to be a duplicate of #777973. I have attached two different backtraces. 1) attachment #348465 [details] - this is a backtrace which was generated by gparted from ArchLinux's repository, that is v 0.28.1-1. It's backtrace seemed to be lacking a lot of information, that is why I have provided you with the other backtrace. 2) attachment #348464 [details] - this is a backtrace which I have generated from the 'master' version of gparted, i.e. commit b4349f851. It has more detailed information. Sadly, I could not get the desired core dumps with your instructions, so I have used my system's automatic core dumping mechanism. The console output was: Master version: $ sudo ./gparted [sudo] password for root: Too few arguments. ====================== libparted : 3.2 ====================== Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. ./gparted: line 193: 7544 Segmentation fault (core dumped) $BASE_CMD Too few arguments. Packaged version: # gparted Too few arguments. ====================== libparted : 3.2 ====================== Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. Unable to open /dev/sdb read-write (Read-only file system). /dev/sdb has been opened read-only. /usr/bin/gparted: line 193: 15887 Segmentation fault (core dumped) $BASE_CMD Too few arguments. For your information, /dev/sdb is the file responsible for the faulty USB stick.
Thanks for the backtrace. It contains these key function calls: Thread 1: Program terminated with signal SIGSEGV, Segmentation fault #0 Glib::ustring_Iterator<...>::operator++() #1 Glib::ustring_Iterator<...>::operator++() #2 GParted::PipeCapture::OnReadable() #3 GParted::PipeCapture::_OnReadable() Thread 3: #2 GParted::Utils::execute_command() #3 GParted::fat16::set_used_sectors() #4 GParted_Core::set_used_sectors() So GParted is running "fsck.fat -v -v /dev/PTN" and choking on non-valid UTF-8 characters. This is identical to both these existing bug reports: Bug 777973 - Segmentation fault on bad disk Bug 780104 - Gparted crashes when trying to read partitions from disk with unformatted + NTFS partition Marking this as a duplicate of bug 777973. *** This bug has been marked as a duplicate of bug 777973 ***