First discovered while resizing an ext3 filesystem on an LVM logical volume, but then confirmed on a real partition on another system. One odd thing is that the resize appears to work despite the error, or at least I haven't found anything wrong yet. Reproducible: Always Steps to Reproduce: Steps when resizing a filesystem on a real partition (hda7 in this example was _not_ on the system disk nor was it in use. Also, the resize was a shrink from 1GB to 512MB, though I get the same error if I grow the fs as well) 1. umount /dev/hda7 2. resize2fs -p /dev/hda7 512M Actual Results: resize2fs 1.35 (28-Feb-2004) Resizing the filesystem on /dev/hda7 to 131072 (4k) blocks. Begin pass 2 (max = 15849) Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 3 (max = 6) Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 4 (max = 676) Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*** glibc detected *** double free or corruption (!prev): 0x080536d8 *** Aborted Expected Results: I cannot answer this as I have not resized an ext2/3 filesystem before. Based on the output I think it should have just exited normally at the point where the error occurs. I found a reference to an almost identical bug in RedHat: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132707 However, in my case e2fsck reports _no_ errors at all when run before or after the resize. Confirmed on 2 systems: Kernel versions: 2.6.9 and 2.6.10 Gentoo 2004.2 e2fsprogs-1.35-r1
*** Bug 87028 has been marked as a duplicate of this bug. ***
The same error happens to me on my amd64 system. My kernel version: 2.6.9-r14 e2fsprogs-1.35-r1 Throws exactly the same error and e2fsck does not report any errors afterwards for myself either.
hmm, does 1.37 help at all ?
I unmasked the e2fsprogs-1.37 for amd64, emerged it, and did some preliminary testing. It definitely seems to resolve the issue and the double free error is no longer thrown. I ran it through a variety of tests, such as shrinking and enlarging the filesystems. The 1.37 version seems to be more stable than the 1.35 version and might I suggest that it is unmasked for amd64 by default?
we're waiting on a bug to be fixed in 1.37 before moving it to stable thanks for testing :)
The same bug is in RedHat Bugzilla here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132707 They seem to have fixed the bug in their 1.35-10 I had it too btw.
*** Bug 93712 has been marked as a duplicate of this bug. ***
*** Bug 96211 has been marked as a duplicate of this bug. ***
