Menu
▾
▴
#2 ERROR: (rs_file_copy_cb) seek failed
4 of 8 'make check' tests fail on solaris (2.6 or 8),
always with
more-or-less the following complaint:
mutate.test: .librsync: ERROR: (rs_file_copy_cb) seek
failed: Invalid argument
librsync: ERROR: (rs_job_complete) patch job failed: IO
error
librsync: ERROR: IO error
mutate.test: returned 100: ../rdiff patch
/d/ark-builds/librsync--0.9.6/sparc-solaris8/testsuite/mutate.tmp/old
/d/ark-builds/librsync--0.9.6/sparc-solaris8/testsuite/mutate.tmp/delta
/d/ark-builds/librsync--0.9.6/sparc-solaris8/testsuite/mutate.tmp/out
FAIL: mutate.test
Feel free to shout back for more info, or whatever.
Building for two RH Linux platforms in an identical way
worked fine. Keep up the good work,
Will
Logged In: YES
user_id=10273
I suspect this is related to large file support. If your
system is detected as supporting it, fseek gets #defined to
fseeko.
There are various checks done by configure for large file
support. I think your system is passing some, but not
others, resulting in fseeko being used with an incorrect
parameter type.
Can you give me the output of your configure run, and/or the
resulting config.h?
requested info (2 files in a tarball)
Logged In: YES
user_id=10007
Requested info in the attached tar file. Thanks.
Logged In: YES
user_id=10007
I can further confirm that if configured with
--disable-largefile, it passes its checks on solaris8, no
problem.
Logged In: YES
user_id=10273
I had a look at your config.h and config output and I'm
stumped. could you also send me your librsync-config.h.
If you can, it would be good if you could give me the trace
output you get when you get a failed "rdiff -v delta"
operation. You will need to recompile rdiff after doing
"configure --enable-trace". I suspect any "rdiff delta"
operation will fail, but if not you migh need to fiddle with
testsuite/mutate.test to get it to use the -v option.
Logged In: YES
user_id=10273
Whups... I meant "rdiff -v patch" not "rdiff -v delta"...
Logged In: YES
user_id=10007
Hi, thanks; I'm attaching another log file (gzipped) which
shows a
full configure... all the way to a tracing/failing rdiff.
At the end, are
cats of the two config.h files.
I've left in the compiling bits that including warning, one
about largefile
support -- you might want to double-check those. Regards,
Will
Logged In: YES
user_id=10273
This bug is probably the same as the following problem
detected by the debian build system on HP PA-RISC platform;
http://buildd.debian.org/fetch.php?&pkg=librsync&ver=0.9.6-2&arch=hppa&stamp=1061941992&file=log&as=raw
It looks like the offset for the seek is corrupted at the
rs_file_copy_cb. In this case the seek was within the file,
but the read was going beyond the end of the file.
in case this report disapears, here is the important bits;
[...]
mutate.test: .lt-rdiff: ERROR: (rs_file_copy_cb) unexpected
eof on fd3
lt-rdiff: ERROR: (rs_job_complete) patch job failed:
unexpected end of input
lt-rdiff: ERROR: unexpected end of input
mutate.test: returned 103: ../rdiff patch
/build/buildd/librsync-0.9.6/testsuite/mutate.tmp/old
/build/buildd/librsync-0.9.6/testsuite/mutate.tmp/delta
/build/buildd/librsync-0.9.6/testsuite/mutate.tmp/out
FAIL: mutate.test
sources.test: lt-rdiff: ERROR: (rs_file_copy_cb) unexpected
eof on fd3
lt-rdiff: ERROR: (rs_job_complete) patch job failed:
unexpected end of input
lt-rdiff: ERROR: unexpected end of input
[...]
triple.test: lt-rdiff: ERROR: (rs_file_copy_cb) unexpected
eof on fd3
lt-rdiff: ERROR: (rs_job_complete) patch job failed:
unexpected end of input
lt-rdiff: ERROR: unexpected end of input
triple.test: returned 103: ../rdiff -I4096 -O4096 patch
/build/buildd/librsync-0.9.6/testsuite/triple.input/copying.in
/build/buildd/librsync-0.9.6/testsuite/triple.tmp/delta
/build/buildd/librsync-0.9.6/testsuite/triple.tmp/new
FAIL: triple.test
changes.test: lt-rdiff: ERROR: (rs_file_copy_cb) unexpected
eof on fd3
lt-rdiff: ERROR: (rs_job_complete) patch job failed:
unexpected end of input
lt-rdiff: ERROR: unexpected end of input
changes.test: returned 103: ../rdiff -I4096 -O4096 patch
/build/buildd/librsync-0.9.6/testsuite/changes.input/01.in
/build/buildd/librsync-0.9.6/testsuite/changes.tmp/delta
/build/buildd/librsync-0.9.6/testsuite/changes.tmp/new
FAIL: changes.test
===================
4 of 8 tests failed
===================
The configure shows;
[...]
checking for size_t... yes
checking for off_t... yes
checking for special C compiler options needed for large
files... no
checking for _FILE_OFFSET_BITS value needed for large
files... 64
checking for _LARGE_FILES value needed for large files... no
[...]
checking for _LARGEFILE_SOURCE value needed for large
files... no
checking for fseeko... yes
[...]
Logged In: YES
user_id=10273
BTW partain, I didn't get that gzip'ed extra info you mentioned.
This may also be the same as the bug reported here;
http://sourceforge.net/tracker/index.php?func=detail&aid=791629&group_id=56125&atid=479439
However, this was reported on an i686 build, so I'm not sure
if it was the same thing.
Logged In: YES
user_id=10273
I think I know what is happening. I found a thread
discussing exactly this at;
http://www.mail-archive.com/autoconf@gnu.org/msg09225.html
So it seems large file support in autoconf/gcc is not quite
right yet. I'm not sure what the best solution is yet, but
it seems that people should disable large file support for now.
Logged In: YES
user_id=10273
This bug affects all platforms, just in slightly different
ways. On i386 it only shows up when manipulating large
files, but on HP and Solaris it affects files of any size.
It is due to autoconf/glibc large file issues. A workaround
that should work is;
./configure "CFLAGS=-D_LARGEFILE_SOURCE"
This should force fseeko declaration in glibc, hence
avoiding the callframe mismatch that corrupts the seek offset.
I'm not sure what the best long-term solution is. I suspect
autoconf and/or glibc will sort this out so that
AC_SYS_LARGEFILE and/or AC_FUNC_FSEEKO will handle this
correctly. In the mean time we could put some workaround in
configure.ac.
Any suggestions are welcome....
--> ERROR: (rs_file_copy_cb) seek failed
Logged In: YES
user_id=10273
It is highly likely that bug 855477 "buf.c incorrect header
order" was the real reason for this bug.
That bug has been fixed in CVS. Can people test and report?
Logged In: NO
I keep getting "end of file from server" errors from
Sourceforce's CVS server, so I can't do a CVS checkout, but
I made the bug 855477 change manually, and that indeed fixes
the problem, at least for me (on a Solaris 8 box).
-Barry K. Nathan <barryn@pobox.com>
Logged In: YES
user_id=10273
This bug has been fixed in the developer's CVS. There may be
some delay before the fix appears in anonymous CVS.
The fix will be included in the next release of librsync after
0.9.6. This bug will be closed when the fix is included in a release.
Logged In: YES
user_id=10273
The bug fix in CVS has been included in release 0.9.7. This bug
is now closed.