steveloughran commented on PR #4115:
URL: https://github.com/apache/hadoop/pull/4115#issuecomment-1087645575
stack of the failure
```
[ERROR]
testStatistics(org.apache.hadoop.fs.s3a.fileContext.ITestS3AFileContextStatistics)
Time elapsed: 1.591 s <<< ERROR!
java.io.EOFException: Attempted to seek or read past the end of the file 512
at
org.apache.hadoop.fs.s3a.read.S3InputStream.throwIfInvalidSeek(S3InputStream.java:440)
at
org.apache.hadoop.fs.s3a.read.S3InputStream.seek(S3InputStream.java:235)
at
org.apache.hadoop.fs.s3a.read.S3PrefetchingInputStream.seek(S3PrefetchingInputStream.java:162)
at org.apache.hadoop.fs.FSInputStream.read(FSInputStream.java:85)
at
org.apache.hadoop.fs.FSDataInputStream.read(FSDataInputStream.java:98)
at
org.apache.hadoop.fs.FCStatisticsBaseTest.testStatistics(FCStatisticsBaseTest.java:107)
```
it's happening in the seek(oldPos) code in the default implementation of
positioned read, because the previous unpositioned read read the whole file, so
pos() is at file length.
```
byte[] buf = new byte[blockSize];
int bytesRead = fstr.read(buf, 0, blockSize);
fstr.read(0, buf, 0, blockSize); *here*
```
This is quite a good little failure; I'm impressed but who ever managed to
think at this corner case. pos is at EOF, so returning to it is raising the
EOF.
It is unrelated to this PR; I will file a JIRA. We will probably want seek()
to not do the checks, and have read() do the validation, which is mostly what
s3a does , as it only rejects negative offsets.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
