[
https://issues.apache.org/jira/browse/SUREFIRE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1522.
----------------------------------
Resolution: Fixed
https://github.com/apache/maven-surefire/commit/a8dfec2fcf3f1ca14658883d8ba72524f48b35a8
> IndexOutOfBoundsException for System.out.write
> ----------------------------------------------
>
> Key: SUREFIRE-1522
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1522
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
> Affects Versions: 2.21.0
> Reporter: Rob Platt
> Assignee: Tibor Digana
> Priority: Major
> Fix For: 2.22.0
>
>
> There is a regression, I believe caused by -SUREFIRE-1454-. Git blame seems
> to confirm this; and there was a related regression for empty arrays
> SUREFIRE-1515.
> It can be easily reproduced with the following test:
>
> {code:java}
> import org.junit.jupiter.api.Test;
> import java.nio.charset.StandardCharsets;
> public class SurefireLoggingTest {
> private final byte[] aNiceString = "what fun times, standard out is
> broken\n".getBytes(StandardCharsets.US_ASCII);
> @Test
> public void fun() {
> System.out.write(aNiceString, 5, 3);
> }
> @Test
> public void fun_times() {
> System.out.write(aNiceString, 5, 9);
> }
> }
> {code}
>
> Both tests will pass under Intellij, writing "fun" and "fun times" to
> System.out. Whereas, with Surefire capturing standard out when running from
> maven, only fun_times() passes. fun() will fail with:
>
> {noformat}
> java.lang.IndexOutOfBoundsException: off < 0 || len < 0 || off >=
> input.length || len > input.length || off > len{noformat}
>
> If you look at the Javadoc contract for PrintStream.write(byte buf[], int
> off, int len), you can see that len is "Number of bytes to write", so you can
> see that it should be fine to print the substring "fun", of length 3, at
> offset 5. And indeed that is what happens in Intellij.
>
> I suspect that the failing test isolates the problem to when the offset
> "exceeds" the length of the substring. The wrong length is being checked in
> StringUtils.escapeBytesToPrintable(). I think that the check intended to
> ensure the offset didn't exceed the end of the byte array, not the length of
> the slice. But that is already covered by "off >= input.length". So there is
> no benefit to also checking "off > len".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
