> > No, in fact with this patch exactly the same behavior is shown, > > dereferencing NULL in the same library function. I did verify that the > > library and the parted binary were rebuilt from scratch with the updated > > codes. > > This is weird, I can't reproduce the bug with the patch...
Just to check, I threw away the whole build tree and started from scratch (with patch). Same thing happened. Then rebuilding static worked. > > This time I built with CFLAGS=-g, --enable-debug and --enable-all-static > > in the hopes that Valgrind would give me the line number of the error in > > the shared library. [Un]fortunately, this time it worked, but with many > > (!!) memory errors noted. > > Are you sure they really are memory errors ? Valgrind uses to report lots > of ioctl errors that indeed are not really errors when I use it to debug > Parted :p In this case, not heap errors, but references into uninitialized memory. I know the spurious errors you refer to though. > > Unfortunately the scan does not find my ext3 partition. It was simply > > deleted with fdisk, not overwritten or anything, I don't see what the > > matter is. I have used parted rescue before with success. > > I reproduced your partition scheme, with a supplementary partition 10 > from 41 to 49g, formatted everybody with ext3, deleted it and rescued it > without any problem, but well this test doesn't mean anything because > it could be different from the exact position of your partition 10 Very strange. What exactly could I do to manually scan for an ext3 partition? I don't care much about the false positives, I just wonder if the FS header has disappeared or been scribbled somehow. That would be a terrible loss if so. Thanks, Ryan _______________________________________________ Bug-parted mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-parted
