"John T. Rose" <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>, > Jim Meyering writes: > > "John T. Rose" <[EMAIL PROTECTED]> wrote: > > ... > > > _llseek(4, 4096, [131072], SEEK_CUR) = 0 > > > read(3, "\0", 4096) = 1 > > > _llseek(4, 1, [131073], SEEK_CUR) = 0 > > > read(3, "", 4096) = 0 > > > ftruncate64(4, 13834516064769277953) = -1 EINVAL (Invalid argument) > > > write(2, "../src/cp: ", 11) = 11 > > > write(2, "writing `copy\'", 14) = 14 > > > write(2, ": Invalid argument", 18) = 18 > > > write(2, "\n", 1) = 1 > > > > > > hrm, crazy offset to ftruncate64?! > > > > Yep. If you look at the hexadecimal representations of > > the two values, 13834516064769277953 and 131073: > > > > bffe131000020001 > > 20001 > > > > you see that the bigger off_t value actually used in the > > ftruncate64 call actually contains the desired value > > in its low-order bits. The question is what corrupted > > (or failed to initialize) the upper half. > > > > You might want to use a debugger to see if the > > variable, n_read_total, actually has the bogus value, > > or if the problem is in the ftruncate64 syscall. > > I don't have access to a working debugger on this system but I > can report that changing n_read from ssize_t to off_t seems to > fix the problem. Simply casting n_read to off_t when it is added > to n_read_total fails. Maybe that will be a useful clue to you?!
Thanks. That makes me suspicious of your compiler. What compiler/version/options are you using? Have you tried with and without optimization? Can you compile with a different compiler? _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
