Bug 132707 - resize2fs crashes with double-free error detected by glibc
resize2fs crashes with double-free error detected by glibc
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Woerner
:
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-09-16 00:07 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-16 12:01:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-09-16 00:07:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
Taking a 98176-blocks long ext3 filesystem formatted to hold the /boot
device of an FC3-re0915.1 install, after a clean fsck, and attempting
to resize it to 50M, causes glibc to print a double-free error message
and abort the resize.  The filesystem may be corrupted after this, but
fsck can easily fix it.  No file corruption was detected.  Growing the
filesystem to the original size produces the same problem.

I've experienced this with the old /boot filesystem of an FC2 install
as well, so I don't think it's extremely sensitive to filesystem
contents.  I haven't had the guts to try it on bigger filesystems.

Version-Release number of selected component (if applicable):
e2fsprogs-1.35-9.5 glibc-2.3.3-53

How reproducible:
Always

Steps to Reproduce:
1.umount /boot
2.dd if=/dev/holding/boot of=/tmp/boot.img
3.mount /boot
4.e2fsck -f /tmp/boot.img
5.resize2fs /tmp/boot.img 50M

Actual Results:  resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /tmp/boot.img to 51200 (1k) blocks.
*** glibc detected *** double free or corruption: 0x08218d68 ***
Aborted


Expected Results:  It used to work

Additional info:

After resize2fs crashes, here's what I get:

# e2fsck -f /tmp/boot.img
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(6294--6549) -(6744--6999)
Fix<y>? yes

Free blocks count wrong for group #0 (431, counted=943).
Fix<y>? yes

Free blocks count wrong (40637, counted=41149).
Fix<y>? yes


/tmp/boot.img: ***** FILE SYSTEM WAS MODIFIED *****
/tmp/boot.img: 36/14336 files (5.6% non-contiguous), 10051/51200 blocks
[root@fri ~]# resize2fs /tmp/boot.img
resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /tmp/boot.img to 98176 (1k) blocks.
*** glibc detected *** double free or corruption: 0x094c3d68 ***
Aborted
[root@fri ~]# e2fsck -f /tmp/boot.img
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Group 7's inode table at 57349 conflicts with some other fs block.
Relocate<y>? yes

Group 7's inode table at 57350 conflicts with some other fs block.
Relocate<y>? yes

Group 7's inode table at 57351 conflicts with some other fs block.
Relocate<y>? 
[...]
Comment 1 Thomas Woerner 2004-09-16 12:01:41 EDT
Fixed in rawhide in rpm e2fsprogs-1.35-10 or newer.
Comment 2 Alexandre Oliva 2004-10-02 16:09:39 EDT
Confirmed fixed, thanks.

Note You need to log in before you can comment on or make changes to this bug.