GNOME Bugzilla – Bug 735669
GParted crashes resizing fat16 file system
Last modified: 2016-09-12 21:12:49 UTC
Created attachment 284817 [details] MBR Gparted 0.19.1 (Arch linux package [0]) crashes with a segmentation fault with the given MBR. To reproduce: * Write MBR to a disk with more than 150 GB * Create FAT16 on second partition * Try to move second partition -> Gparted crashes with segmentation fault https://www.archlinux.org/packages/extra/x86_64/gparted/
Hi Christian, Thank you for reporting this issue. So that we can narrow down the cause can you post output from GParted and a backtrace from the core dump. Thanks, Mike 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 * systemctl stop abrtd * sudo service apport stop 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 backtrace -ex quit > backtrace.log Please paste the terminal output when running gparted and the contents of the backtrace.log file.
Created attachment 284857 [details] backtrace Ok, here we go... No terminal output except libparted version.
Analysis -------- GParted crashed in an unidentified function in libparted-fs-resize. [New LWP 3653] [New LWP 3655] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `/usr/bin/gpartedbin'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 234021
Eek. Bugzilla has jumped in with it's back trace auto processor and swollowed my analysis text. (Click Trace 234021 above to see). Repeating again ... Analysis -------- GParted crashed in an unidentified function in libparted-fs-resize. Reasoning: 1) libparted-fs-resize implies parted >= 3.1. 2) GParted 0.19.1 uses internal copy algorithm for fat16/32 file system move with libparted >= 3.0. Therefore operation must also have included file system resize too, and called ped_file_system_resize(). Reproduction of crash --------------------- I have reproduced this crash on Fedora Rawhide (22) with libparted 3.2 and GParted 0.19.1. Steps: 1) Create 1024 MiB FAT16 partition (MBR, primary partition); 2) Resize partition to 2048 MiB. GParted displayed libparted warning about optionally converting to FAT32. After any choice GParted immedately crashes in libparted. [root@localhost ~]# ~fedora/bin/gpartedbin-0.19.1 ====================== libparted : 3.2 ====================== /dev/sdc: unrecognised disk label /dev/sdc: unrecognised disk label The file system can only be resized to this size by converting to FAT32. If you convert to FAT32, and MS Windows is installed on this partition, then you must re-install the MS Windows boot loader. If you want to do this, you should consult the Parted manual (or your distribution's manual). Also, converting to FAT32 will make the file system unreadable by MS DOS, MS Windows 95a, and MS Windows NT. Segmentation fault (core dumped) Back trace: [root@localhost ~]# gdb ~fedora/bin/gpartedbin-0.19.1 core.3693 [New LWP 3693] [New LWP 3695] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". bCore was generated by `/home/fedora/bin/gpartedbin-0.19.1'. Program terminated with signal SIGSEGV, Segmentation fault. a#0 0x00007f732e426ab0 in __memcpy_sse2_unaligned () from /lib64/libc.so.6 (gdb) backtrace
+ Trace 234022
Hi Mike, I have also reproduced this crash on kubuntu 12.04 with libparted 3.2 and GParted 0.19.1. Steps: 1) Create 512 MiB FAT16 partition (MBR, primary partition); 2) Resize partition to 640 MiB. GParted displayed libparted warning about optionally converting to FAT32. If I chose "Okay" the crash would occur. If I chose "Cancel" the crash did not occur. I built parted-3.2 with CFLAGS=" -g ", and installed into /usr/local by default. I then built gparted (from git) linking to parted-3.2 and using CXXFLAGS=" -g -O0 " and created a backtrace. One very interesting line upon crashing mentions a missing file called: ./sysdeps/x86_64/multiarch/memcpy-ssse3-back.S The exact syntax is: Program received signal SIGSEGV, Segmentation fault. __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:98 98 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory. I will try to reproduce this using parted-3.2 alone, and if successful I will post a bug on the bug-parted mailing list. Following is the backtrack from my emacs gud-gdb session: Current directory is ~/workspace/gparted.dev2/ [sudo] password for gedakc: GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /home/gedakc/workspace/gparted.dev2/src/gpartedbin...done. (gdb) set height 10000 (gdb) run Starting program: /home/gedakc/workspace/gparted.dev2/src/gpartedbin [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". ====================== libparted : 3.2 ====================== [New Thread 0x7fffee115700 (LWP 27186)] [New Thread 0x7fffed8c4700 (LWP 27192)] [New Thread 0x7fffde150700 (LWP 27193)] [Thread 0x7fffde150700 (LWP 27193) exited] The file system can only be resized to this size by converting to FAT32. If you convert to FAT32, and MS Windows is installed on this partition, then you must re-install the MS Windows boot loader. If you want to do this, you should consult the Parted manual (or your distribution's manual). Also, converting to FAT32 will make the file system unreadable by MS DOS, MS Windows 95a, and MS Windows NT. Program received signal SIGSEGV, Segmentation fault. __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:98 98 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory. (gdb) info threads Id Target Id Frame 3 Thread 0x7fffed8c4700 (LWP 27192) "gdbus" 0x00007ffff4a9a963 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 2 Thread 0x7fffee115700 (LWP 27186) "gmain" 0x00007ffff4a9a963 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 * 1 Thread 0x7ffff7fbe9c0 (LWP 27180) "gpartedbin" __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:98 (gdb) backtrace
+ Trace 234041
While trying to reproduce the error using parted-3.2 alone, I discovered that the new "resizepart" command seems to only move the endpoint of the partition. The "resizepart" command does not resize the file system. The commands I tried (as root) and that successfully resized only the partition were: MYDEV=/dev/sdb parted $MYDEV mklabel msdos parted $MYDEV unit mib mkpart primary fat16 1 513 mkdosfs -F 16 ${MYDEV}1 parted $MYDEV unit mib resizepart 1 641 It looks as if both libparted AND gparted will be needed in order to find the bug. Curtis
Because fat16 and fat32 resizing works with parted-3.1, it appears that the crash was introduced after the 3.1 release (or in patches to distro specific parted 2.3 versions). Since the backtrace indicated the last libparted code before the crash was in libparted/fs/r/fat/resize.c, I checked and there have been only a few changes since the 3.1 release. Git changes to r/fat/resize.c: http://git.savannah.gnu.org/cgit/parted.git/log/libparted/fs/r/fat/resize.c I thought the problem might be related to the following change: libparted: fix fat resize http://git.savannah.gnu.org/cgit/parted.git/commit/libparted/fs/r/fat/resize.c?id=5adae27101565a5d6fed4aadf28ddb39872e41f5 However, when I reverted this change the crash still occurred. Now I think the problem might be related to a combination of changes. Using git bisect should locate the change that introduced the problem, but this will be time consuming due to the need to bisect parted code, and then link each time with the gparted code. If anyone has other suggestions on how to more quickly track down the problem I am all ears. :-)
Unfortunately there is no quicker way that git bisect of libparted. I count 137 changes between parted 3.1 and 3.2, which should take 9 or possibly 10 test cycles using bit bisect. Mike
Hi Mike, I've tried two times at git bisecting the parted code base using two different end commits and unfortunately both fail to compile. ;-( Now I have first hand experience with why you insist that each commit should compile and why you implemented git-test-sequence. :D Ideally Phillip will have a chance to look at this problem. If not, then I might have to use trial and error to track down the offending commit. Curtis
Do you know you can use "git bisect skip" to skip commits? Depending on what commits are skipped it does not matter for the result or git will tell you the bad commit is anywhere between commit A and B, including the skipped one(s).
Mucho thank you Christian for this tip. :-) By using "git bisect skip" I was able to get past the commits that failed to compile. Following is the output after all the git bisect iterations. $ git bisect start $ git bisect bad 1677dbbbbca3cd2aa94004cd09d64cbb8a451164 $ git bisect good a0b1ec20e52394a7720f44b4b42dc185e72bb71e <...snip -- all the iterations...> $ git bisect good f70ff1fc474764c3a71318ddb4e0d26afc52ac47 is the first bad commit commit f70ff1fc474764c3a71318ddb4e0d26afc52ac47 Author: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> Date: Wed Aug 21 16:09:56 2013 -0700 libparted: add support for implicit FBA DASD partitions Fixed Block Access (FBA) DASDs are mainframe-specific disk devices which are layed out as a sequence of 512-byte sectors. In contrast to ECKD DASDs, these disks do not require formatting and resemble the LBA layout of non-mainframe disks. Despite this resemblance, the Linux kernel applies special handling during partition detection for FBA DASDs, resulting in a single, immutable partition being reported. While actual FBA DASD hardware is no longer available, the z/VM hypervisor can simulate FBA DASD disks, backed by either ECKD or SCSI devices. This patch adds support for recognizing FBA DASD partitions to parted. Signed-off-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com> :040000 040000 26cf765bbaab98ace6838c87caf01072d800666f 4bb31b5ba1ed23ebe8477a52733a3140fef11d27 M include :040000 040000 0e0920cf87543ac73c527eca4425632b617c3f72 6bf3e2a1252445916ff7b8a36d99d24712feb22e M libparted $ That's enough work for today. The next step is to figure out the lines of code that introduce the problem. Curtis
Now that I've had a chance to look at the commit that was identified as the first bad commit, I started to have some doubts as to whether I made a mistake. To check I identified the immediately prior parted commit as: Fix filesystem detection on non 512 byte sectors 80678bdd957cf49a9ccfc8b88ba3fb8b4c63fc12 Then I retested to see if this commit did indeed successfully resize a fat16 partition. MY TEST STEPS 1) Create 300 MiB fat16 partition and apply 2) Shrink partition to 285 MiB and apply Choose "No" when asked if "Would you like to use FAT32?" 3) Note if works, or crashes Using the commit listed above, GParted still crashed. This means that I must have made a mistake on at least one iteration of the various steps (parted-uninstall, parted-bisect, parted-clean, parted-compile, parted-install, gparted-clean, gparted-compile, gparted-test). 'Looks like I'll need to retry using git bisect using this bad commit and the version 3.1 commit.
Following is a log of my most recent git bisect attempt: $ git bisect start $ git bisect good a0b1ec20e52394a7720f44b4b42dc185e72bb71e $ git bisect bad 80678bdd957cf49a9ccfc8b88ba3fb8b4c63fc12 <... snip -- all the iterations...> $ git bisect good 80678bdd957cf49a9ccfc8b88ba3fb8b4c63fc12 is the first bad commit commit 80678bdd957cf49a9ccfc8b88ba3fb8b4c63fc12 Author: Phillip Susi <psusi@ubuntu.com> Date: Mon Mar 17 22:07:55 2014 -0400 Fix filesystem detection on non 512 byte sectors Enable probing for filesystems with non 512 byte sectors, and fix up each filesystem to correctly handle that. Remove unused field from the fs type structure listing acceptable sector sizes. :100644 100644 9ef8bf450e5babdc6ffd1278bc08ba76b8a05f5c ae651068d4b0231613f69ceb376cf19c72030ac9 M NEWS :040000 040000 c3a32c4d36fedae33f4b9ef5fb357d3ea1dd55df 26cf765bbaab98ace6838c87caf01072d800666f M include :040000 040000 85accd5504b2f227ee6e448a47e5f0c63e7f8d8a 0e0920cf87543ac73c527eca4425632b617c3f72 M libparted $ In an effort to ensure that this is indeed the commit that introduces the fat16 resize crash, I located the prior commit: tests: fix t2310-dos-extended-2-sector-min-offset.sh d0a4cc1b57750a92afb48b229e4791154afa322b and re-tested. This time the fat16 partition was successfully resized. This gives me confidence that the correct offending commit has been identified. A quick look at the commit that introduces the fat16 resize crash shows that it touchs lots of code, including stuff related to fat. This "bad" commit can be viewed at the following link: Fix filesystem detection on non 512 byte sectors http://git.savannah.gnu.org/cgit/parted.git/commit/?id=80678bdd957cf49a9ccfc8b88ba3fb8b4c63fc12 Note that Phillip posted a follow-up fix to address problems resizing fat32. See: libparted: fix fat resize http://git.savannah.gnu.org/cgit/parted.git/commit/?id=5adae27101565a5d6fed4aadf28ddb39872e41f5 I will begin investigating to see if I can identify the problem. Any help with this endeavour is also appreciated. :-) Curtis
Add Phillip Susi to the CC list
Hi, I've submitted a parted patchset to resolve this bug. [PATCH 0/3] Prevent crash resizing FAT16 file systems http://lists.alioth.debian.org/pipermail/parted-devel/2014-September/004580.html Thanks, Mike
Thank you Mike for posting a patch set to Parted mailing list that fixes the problem of GParted crashing when used with libparted 3.2. A patched version of Parted 3.2 (includes patch set mentioned in comment #15) was included in the GParted Live 0.20.0-2 stable release image. When GParted is linked with the patched version of libparted 3.2, fat16 resize operations no longer crash. :-) Because the patch set in comment #15 might take a while to be accepted into parted and various distros, I think it might help to keep this report open for the near term.
It's worth attaching the patchset here as well since the mailing list won't lend it for download -- I'd like to the update graphical flavour of ALT Linux Rescue. :-)
Created attachment 289405 [details] [review] Prevent crash resizing FAT16 file systems (v1) Hi Michael, Attached is the patchset I send to the parted-devel email list as reported in comment #15 above. Note that patch number 1 fixes the bug, patch numbers 2 and 3 update the unit tests to prevent future regressions. Thanks, Mike
SIGTHX :-)
Thanks Phillip for accepting Mike's patch set into the Savannah Parted git repository. [parted-devel] [PATCH 0/3] Prevent crash resizing FAT16 file systems http://lists.alioth.debian.org/pipermail/parted-devel/2014-October/004589.html lib-fs-resize: Prevent crash resizing FAT16 file systems http://git.savannah.gnu.org/cgit/parted.git/commit/?id=1e9e770f4bc7f3d80e09ecd1df58575fad064163 Hopefully soon some of the GNU/Linux distributions will begin to pick up these patches as well. I think we should keep this report open until some major distros like Debian, Ubuntu, and Fedora pick up this patch set. Curtis
http://packages.altlinux.org/en/Sisyphus/srpms/parted/changelog; looks good.
I have opened a bug report for Arch Linux: https://bugs.archlinux.org/task/42574
Raised Fedora bug 1159083 - libparted crashes resizing fat16 file systems https://bugzilla.redhat.com/show_bug.cgi?id=1133315
For ease of tracking, the link for the fat16 resize crash Fedora bug raised by Mike is: Bug 1159083 - libparted crashes resizing fat16 file systems https://bugzilla.redhat.com/show_bug.cgi?id=1159083 I'm guessing that is the link you meant to post. :-)
The patches to libparted were accepted a long time ago now. As the fix wasn't in GParted closing this bug as NOT GNOME.