GNOME Bugzilla – Bug 628863
gparted crashes applying move to right of more than one logical partition
Last modified: 2011-02-10 18:09:37 UTC
On an IBM T42 notebook gparted reproducably (tried 3 times with varying layouts) crashes when rearranging partitions leaving the system in an unusable state. Starting point is a 40 GByte image (of an Hitachi HTS548040M9AT00) copied onto a 160 GByte PATA drive (WDC WD1600BBEVE-00UYT0). Screenshots appended: gparted0_before.jpeg gparted2_aswanted.jpeg gparted3_first_op.jpeg gparted4_second_op.jpeg gparted5_state_after_crash.jpeg I'm using gparted-live-0.6.2-2.iso Does gparted write a log file with planned, pending and completed operations or is a core dump written? Can I provide more information?
Created attachment 169552 [details] aswanted
Created attachment 169553 [details] first_op
Created attachment 169554 [details] second_op
Created attachment 169555 [details] state_after_crash
Created attachment 169556 [details] before
Are you able to reproduce the crash using a single step? GParted itself does not automatically save any information on a crash. If a step fails, GParted will prompt that an error has occurred and recommend that the user save the gparted_details.htm log file. Since you mention that GParted crashed, you would not have seen this dialog box.
> Since you mention that GParted crashed, you would not have seen this dialog box. Yes, I don't see the dialog box. GParted is simply gone then. > Are you able to reproduce the crash using a single step? Sorry, I cannot test this at the moment (unfortunately I needed the notebook and rearranged partitions otherwise (removing sda2 with fdisk, then resizing sda1 with GParted, then fdisk sda2,5,6,7 and copying sda5,6,7 images "by hand")). Speculating: possible causes for the crash could be a strange previous arrangement, the T42 Bios trying to protect a restore partition (I switched that off in the BIOS, but who knows) or a problem with the graphics (laptop is a http://www.thinkwiki.org/wiki/2373-CTO ) or a 128 GByte problem?
I consider program crashes a serious bug, especially if the crash results in the loss of data. Unfortunately it is very difficult to determine the cause of a crash when I am unable to reproduce the problem. If you are able to reproduce the problem, the following link contains additional details on how to obtain a stack trace: http://live.gnome.org/GettingTraces/Details Stack traces can be very useful to determine which library or module a program was executing when it crashed.
Created attachment 170083 [details] blanked graphical bar (is redrawn when f.e. minimizing/maximizing window)
Hi Curtis, the stack trace says: root@debian:~# gparted ====================== libparted : 2.3 ====================== Unable to satisfy all constraints on the partition. Backtrace has 12 calls on stack: 12: /lib/libparted.so.0(ped_assert+0x2a) [0xb76bccda] 11: /lib/libparted.so.0(+0x44bc8) [0xb76f4bc8] 10: /lib/libparted.so.0(+0x131ee) [0xb76c31ee] 9: /lib/libparted.so.0(ped_disk_set_partition_geom+0x153) [0xb76c4553] 8: /usr/sbin/gpartedbin() [0x809dcd1] 7: /usr/sbin/gpartedbin() [0x809e62f] 6: /usr/sbin/gpartedbin() [0x80a35ba] 5: /usr/sbin/gpartedbin() [0x80a35ec] 4: /usr/sbin/gpartedbin() [0x80a3dc0] 3: /usr/sbin/gpartedbin() [0x8074e05] 2: /lib/libpthread.so.0(+0x57b0) [0xb6b747b0] 1: /lib/libc.so.6(clone+0x5e) [0xb6af681e] Assertion (metadata_length > 0) at ../../../libparted/labels/dos.c:2165 in function add_logical_part_metadata() failed. (A maybe related observation: when entering the data for resizing/moving partitions the graphical bar near the top of the window temporarily vanished (was shown as grey bar). It reappears when the window is redrawn f.e. by minimizing/maximizing the gparted window (or switching sreens). Screenshot appended) core dump is available on request. The output of fdisk on the 160 GByte disk after transferring the 40 GByte image is: root@debian:~# fdisk -l /dev/sda Disk /dev/sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xc8b9c8b9 Device Boot Start End Blocks Id System /dev/sda1 1 2419 19422585 7 HPFS/NTFS /dev/sda2 * 2419 4864 19647463+ f W95 Ext'd (LBA) /dev/sda5 2419 2611 1550209+ 82 Linux swap / Solaris /dev/sda6 2612 3512 7237251 83 Linux /dev/sda7 3513 4864 10859908+ 83 Linux Greetings, Frieder
Would you be able to compile and test the GParted 0.6.3-beta1 release? If so, the source code can be downloaded from the following link: http://gparted.sourceforge.net/curtis/gparted-0.6.3-beta1.tar.bz2 Also, would you be able to provide the output from the following command? fdisk -l -u /dev/sda Without the -u argument, I do not know the exact sector boundaries for the partitions. :-)
> fdisk -l -u /dev/sda Disk /dev/sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders, total 312581808 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 Disk identifier: 0xc8b9c8b9 Device Boot Start End Blocks Id System /dev/sda1 63 38845232 19422585 7 HPFS/NTFS /dev/sda2 * 38845233 78140159 19647463+ f W95 Ext'd (LBA) /dev/sda5 38845296 41945714 1550209+ 82 Linux swap / Solaris /dev/sda6 41945778 56420279 7237251 83 Linux /dev/sda7 56420343 78140159 10859908+ 83 Linux > Would you be able to compile and test the GParted 0.6.3-beta1 release? I was able compile it but it would not run on gparted-live-0.6.2-2.iso (complaining about missing library (probably configuring with --enable-static was not enough)). Unfortunately the notebook has to functional again Monday so I cannot test. (I'm appending the first 256k of sda1,2,5,6,7 in a tar file, just in case it helps)
Created attachment 170100 [details] the first 256k of partitions sda1,2,5,6,7
Thank you Frieder for the additional information. I have now been able to recreate the problem with GParted crashing. This problem also exists with the recently released GParted 0.6.3. My suspicion is that the problem occurs when moving more than one cylinder aligned logical partitions to the right such that these partition butt up against each other. To test this theory I will try to recreate the problem with smaller partitions. That will enable me to test possible fixes much faster.
A simple test to recreate this problem is as follows: 1) Create a new msdos partition table. 2) Create a cylinder aligned extended partition table. 3) Create an 8 MiB cylinder aligned ext2 logical partition at the start of the extended partition. 4) Create an 8 MiB cylinder aligned ext3 logical partition immediately following the ext2 logical partition. 5) Apply the above operations. 6) Queue an operation to move the ext3 partition right to the end of the extended partition using MiB alignment (default). 7) Queue an operation to move the ext2 partition right to butt up against the ext3 partition using MiB alignment (default). 8) Apply these operations. NOTE: GParted will succeed in moving the ext3 partition, but will crash when moving the ext2 partition. GParted does not crash if step 6 is applied before performing step 7. Hence performing steps one at a time appears to be a work around for this situation. Please note that the problem does not occur if steps 6 and 7 are performed using cylinder alignment.
Updating title of this bug report from: gparted reproducably crashes during operation to: gparted crashes applying move to right of more than one logical partition
Increasing the Severity of this bug to Critical since it involves a program crash. Leaving the Priority as Normal since a straight forward work around exists (queue and apply one operation at a time)
I can think of two ways to work around this problem of using MiB alignment and moving more than one logical partition to the right so that each butts up against the other: 1) When moving logical partitions to the right, always leave at least 1 MiB free space following. 2) Only move one logical partition to the right at a time, and apply the operation before proceeding to the next logical partition.
A fix for this problem has been committed to the git repository for inclusion in the next release of GParted (0.7.0). The relevant git commit can be viewed at the following link: http://git.gnome.org/browse/gparted/commit/?id=7c0e3fa7789f413e8408e89ff7470e8ff86e7e72
The enhancements to address this bug report have been included in GParted 0.7.0 which was released on October 29, 2010. Closing this bug report.
As the GParted version in Ubuntu 10.10 does still have this bug, may I ask whether it triggers any data corruption ? I indeed encountered it yesterday after moving 2 extended NTFS partitions to the right of my drive. When I came back, gparted had exited and only the first partition was moved, apparently. Cheers & thanks to everyone involved !
Mahendra, no data corruption should occur in the file system data. The problem is that the logical partition Extended Boot Record might be overwritten.