There is a reported failure in our Java launcher, with the launcher
being unable to locate libjvm.so. The failure was seen after
moving to a new network filesystem (Isilon).

Our analysis revealed that the problem was caused by a failure in a stat()
syscall, with the errno set to EOVERFLOW. EOVERFLOW means that the kernel
failed to populate the field of a structure in the user space because the
value was too large for the defined data type. In our specific case, it meant
that stat() failed to set a field in the struct stat whose address it
received. Further investigation revealed the root cause to be very large
inode numbers - libjvm.so had an inode number of 9465726852, which is too
large to fit in the struct stat, which stores the inode in a 32-bit value.

There is a solution in the form of struct stat64, which is part of the 64-bit
file system interface. This struct has a 64-bit inode number field, so we can
replace the struct stat with stat64 to avoid the launcher failure. However,
the problem has a MUCH larger scope.

The 64-bit file system interface comes as a part of the large files support
for 32-bit systems. A few structures change shape when the 64-bit interface
is used - stat being one of them. There are two important C pre-processor
macros related to large files:

1. _LARGEFILE64_SOURCE
With this macro defined, the 64-bit interface is made available as an
alternative to the default 32-bit interface. For example, struct stat64 is
made available alongside stat. If applications wish to use the 64-bit
interface, they need to explicitly use the *64 structures and functions.

2. _FILE_OFFSET_BITS
With this macro set to 64, the 64-bit file system interface completely
replaces the 32-bit interface. For example, struct stat & stat64 will have
the same shape if this macro is set to a value of 64.

We searched the JDK 6 and 7 native class library code and made the following
observations:

a) We have _LARGEFILE64_SOURCE as a common compilation option, enabling both
32-bit & 64-bit interfaces.
b) We use both struct stat and stat64, seemingly at random.

So the native class library code currently uses both of the file system
interfaces (32 and 64-bit). With a 64-bit file system like our customers,
all of the points where the 32-bit interface is used become potential points
of failure.