GNU bug report logs - #12656
cp since 8.11 corrupts files

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: m.gerth <at> avm.de
Cc: Alan Curry <pacman-cu <at> kosh.dhis.org>, 12656 <at> debbugs.gnu.org
Subject: bug#12656: cp since 8.11 corrupts files
Date: Tue, 16 Oct 2012 20:41:47 +0200

m.gerth <at> avm.de wrote:
> Hi Jim,
>
> Congratulation - the patch works for me. Result looks good - no errors.
> Tomorror I will test more extensive (copy all files and compare all files).
> The debug output from the first patch is now identical when using the bulk copy
> and the single copy.

Great.  Thanks for the confirmation.
I've reproduced the problem on an ext4 file system.
This shows the free-memory read, though the two files compare equal.

    $ perl -e 'for (1..3333) { sysseek (*STDOUT, 4096, 1)' \
      -e '&& syswrite (*STDOUT, "a" x 1024) or die "$!"}' > j
    $ valgrind cp j j2
    Memcheck, a memory error detector
    Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
    Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
    Command: cp j j2

    Invalid read of size 4
       at 0x4093D7: extent_scan_read (extent-scan.c:139)
       by 0x407D46: copy_internal (copy.c:301)
       by 0x40904B: copy (copy.c:2691)
       by 0x404B93: do_copy (cp.c:762)
       by 0x4037F7: main (cp.c:1170)
     Address 0x4c4c170 is 1,696 bytes inside a block of size 1,728 free'd
       at 0x4A0892E: realloc (vg_replace_malloc.c:632)
       by 0x410700: xrealloc (xmalloc.c:63)
       by 0x409392: extent_scan_read (xalloc.h:126)
       by 0x407D46: copy_internal (copy.c:301)
       by 0x40904B: copy (copy.c:2691)
       by 0x404B93: do_copy (cp.c:762)
       by 0x4037F7: main (cp.c:1170)

    Invalid read of size 8
       at 0x4094E8: extent_scan_read (extent-scan.c:141)
       by 0x407D46: copy_internal (copy.c:301)
       by 0x40904B: copy (copy.c:2691)
       by 0x404B93: do_copy (cp.c:762)
       by 0x4037F7: main (cp.c:1170)
     Address 0x4c4c168 is 1,688 bytes inside a block of size 1,728 free'd
       at 0x4A0892E: realloc (vg_replace_malloc.c:632)
       by 0x410700: xrealloc (xmalloc.c:63)
       by 0x409392: extent_scan_read (xalloc.h:126)
       by 0x407D46: copy_internal (copy.c:301)
       by 0x40904B: copy (copy.c:2691)
       by 0x404B93: do_copy (cp.c:762)
       by 0x4037F7: main (cp.c:1170)

    Invalid read of size 8
       at 0x4094EF: extent_scan_read (extent-scan.c:141)
       by 0x407D46: copy_internal (copy.c:301)
       by 0x40904B: copy (copy.c:2691)
       by 0x404B93: do_copy (cp.c:762)
       by 0x4037F7: main (cp.c:1170)
     Address 0x4c4c160 is 1,680 bytes inside a block of size 1,728 free'd
       at 0x4A0892E: realloc (vg_replace_malloc.c:632)
       by 0x410700: xrealloc (xmalloc.c:63)
       by 0x409392: extent_scan_read (xalloc.h:126)
       by 0x407D46: copy_internal (copy.c:301)
       by 0x40904B: copy (copy.c:2691)
       by 0x404B93: do_copy (cp.c:762)
       by 0x4037F7: main (cp.c:1170)

Now, let's see if I can reproduce the actual data corruption part.

This obviously reinforces my desire to switch from FIEMAP to
using SEEK_HOLE/SEEK_DATA as soon as possible.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.