Note that the semantics of stat and access may be subtly different, and that there are many calls to stat in the JDK sources, and they may all be broken on 32-bit systems.
I just wrote elsewhere: _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it affects interoperability between translation units. It would be good to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but that would be a big job. So traditionally the JDK has instead used the functions made available via _LARGEFILE64_SOURCE. But that is also a JDK-wide job now, because every call to plain stat in the source code is broken on 32-bit systems with 64-bit inodes, which are becoming more common. I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job for build-dev, not core-libs-dev. On Tue, Dec 15, 2015 at 7:54 AM, Kumar Srinivasan <kumar.x.sriniva...@oracle.com> wrote: > Hello, > > Please review fix for: JDK-8115868 > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ > > The background: > The launcher uses stat(2) to check for the existence of a file, > unfortunately > on 32-bit system with large file systems causes the inode storage to > overflow > causing the syscall to return EOVERFLOW. > > Solution: > * stat(2) replaced with access(3), in most cases. > * jbs is marked noreg-hard hard to replicate the problem > > Thanks > Kumar > > > > >
