bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12656: cp since 8.11 corrupts files


From: Jim Meyering
Subject: bug#12656: cp since 8.11 corrupts files
Date: Tue, 16 Oct 2012 20:41:47 +0200

address@hidden 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]