JDK-6470086 : (fc) FileChannel.transferTo(2147483647, 1, channel) cause "Value too large" exception
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2006-09-13
  • Updated: 2011-05-17
  • Resolved: 2011-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u18Fixed 7 b05Fixed
Description
FULL PRODUCT VERSION :
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.13-gentoo-r3 i686 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux

A DESCRIPTION OF THE PROBLEM :
Using trannsferTo() for large files on many servers, we found that these specific parameters cause the exception.
Position: 2,147,483,647
Data length: 1
Exception: java.io.IOException: Value too large for defined data type

When using any other position and/or length does not cause that exception. Seems like it's a boundry-check bug in the underlying code.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Simply use the parameters mentioned here, with any open output channel.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Successfull transfer of the byte.
ACTUAL -
The IOException mentioned here was thrown.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception: java.io.IOException: Value too large for defined data type

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
try
{
    long reqOffset = 2147483647L;
    int reqLength = 1;
    long sentBytes = channel.transferTo(reqOffset, reqLength, channel);
}
catch (IOException e)
{
    e.printStackTrace();
}
---------- END SOURCE ----------
Comments
EVALUATION The transferTo uses sendfile(2) where possible. The issue on Linux is that this only works with 32-bit offsets and we expect sendfile(2) to fail with -1/EINVAL when the offset isn't supported. It seems this changed in the 2.6 kernel so that -1/EOVERFLOW is returned when the offset is Integer.MAX_VALUE. Here's the output from strace when sendfile is exercised with offsets around Integer.MAX_VALUE: : [pid 29541] sendfile(6, 4, [2147483645], 1) = 1 [pid 29541] sendfile(6, 4, [2147483646], 1) = 1 [pid 29541] sendfile(6, 4, [2147483647], 1) = -1 EOVERFLOW (Value too large for defined data type) [pid 29541] sendfile(6, 4, [2147483648], 1) = -1 EINVAL (Invalid argument) [pid 29541] sendfile(6, 4, [2147483649], 1) = -1 EINVAL (Invalid argument) [pid 29541] sendfile(6, 4, [2147483650], 1) = -1 EINVAL (Invalid argument) : The sendfile(2) man page does not document that EOVERFLOW is a possible error but in any case it looks like we now need to handle this error too.
13-09-2006