United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6470086 (fc) FileChannel.transferTo(2147483647, 1, channel) cause "Value too large" exception
JDK-6470086 : (fc) FileChannel.transferTo(2147483647, 1, channel) cause "Value too large" exception

Details
Type:
Bug
Submit Date:
2006-09-13
Status:
Closed
Updated Date:
2011-05-17
Project Name:
JDK
Resolved Date:
2011-05-17
Component:
core-libs
OS:
linux
Sub-Component:
java.nio
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:

Related Reports
Backport:

Sub Tasks

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.
                                     
2006-09-13



Hardware and Software, Engineered to Work Together