exception handling bug in parted 1.7.0

[Julien Plissonneau Duquène]

Hello,

I have 320 mb disks configured with parted 1.6.25 and kernel 
2.6.16-1.2133_FC5. After a reboot trying 2.6.18-rc1-git6 I got some 
kernel messages saying that my GPT tables were wrong:
SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
(...)
 sdc:<4>GPT:Primary header thinks Alt. header is not at the end of the 
disk.
GPT:625142271 != 625142447
GPT:Alternate GPT header not at the end of the disk.
GPT:625142271 != 625142447
GPT: Use GNU Parted to correct GPT errors.
 sdc1
(...)

I ran parted 1.6.25 (FC5), it crashed. I downloaded parted 1.7.0, tried 
it and got an assertion failure, but apparently it managed to fix the 
partition table anyway.

I have the same disk (RAID1), same setup on /dev/sda, so here is the 
problem reproduced with gdb and a --enable-read-only version:
(gdb) r /dev/sda print unit s print unit chs print
Starting program: /home_local/jpd/src/parted/usr/sbin/parted /dev/sda 
print unit s print unit chs print
Failed to read a valid object file image from memory.
Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Cancel? fix
You found a bug in GNU Parted! Here's what you have to do:
(...)
Your report should contain the version of this release (1.7.0)
(...)
Assertion (n > 0) at exception.c:112 in function ped_log2() failed.

Ignore/Cancel? ^C
(gdb) bt
(...)
#13 0x08051c22 in exception_handler (ex=0x806cb20) at ui.c:448
#14 0xb7f777cf in do_throw () at exception.c:198
#15 0xb7f7788d in ped_exception_throw (ex_type=PED_EXCEPTION_BUG, 
ex_opts=96,
    message=0xb7fd02b8 "Assertion (%s) at %s:%d in function %s() failed.")
    at exception.c:242
#16 0xb7f76626 in ped_assert (cond=0, cond_text=0xb7fd04c9 "n > 0",
    file=0xb7fd04bd "exception.c", line=112, function=0xb7fd04b4 
"ped_log2")
    at debug.c:90
#17 0xb7f775c3 in ped_log2 (n=0) at exception.c:112
#18 0xb7f7761b in ped_exception_get_option_string (
    ex_opt=PED_EXCEPTION_UNHANDLED) at exception.c:125
#19 0x08052f3b in command_line_get_ex_opt (prompt=0x8055e9f "", options=65)
    at ui.c:1031
#20 0x08051c22 in exception_handler (ex=0x806cb20) at ui.c:448
#21 0xb7f777cf in do_throw () at exception.c:198
#22 0xb7f7788d in ped_exception_throw (ex_type=PED_EXCEPTION_ERROR,
    ex_opts=65,
    message=0xb7fd8db8 "The backup GPT table is not at the end of the 
disk, as it should be.  This might mean that another operating system 
believes the disk is smaller.  Fix, by moving the backup to the end (and 
removing th"...)
    at exception.c:242
#23 0xb7fc48fc in gpt_read (disk=0x806bab8) at gpt.c:744
#24 0xb7f7b5e1 in ped_disk_new (dev=0x806caa0) at disk.c:190
#25 0x0804d6f2 in do_print (dev=0xbfed058c) at parted.c:1203
#26 0x0804adcb in command_run (cmd=0x80694a0, dev=0xbfed058c) at 
command.c:138
#27 0x080537de in non_interactive_mode (dev=0xbfed058c, cmd_list=0x8057660,
    argc=7, argv=0xbfed063c) at ui.c:1319
#28 0x080507a3 in main (argc=7, argv=0xbfed063c) at parted.c:2252

I found this in the ChangeLog:
* (command_line_get_ex_opt): return PED_EXCEPTION_UNHANDLED on error, 
not 0.  (They are the same number... just a philosophical change)


--
Julien Plissonneau Duquène, Consultant Savoir-faire Linux, Inc.
address@hidden - (514) 276-5468 / 128