Search code examples
scalasupercsv

Seemingly random StringIndexOutOfBoundsException in supercsv


I am using a supercsv library in my scala code

for (row <- readyData) { // tried foreach and map too
  listWriter.write(row)  
}

where readyData is Seq[java.util.List[String]] and listWriter is a CsvListWriter. I am sometimes getting

java.lang.StringIndexOutOfBoundsException: String index out of range: -2
  at java.lang.String.<init>(String.java:197)
  at java.lang.StringBuilder.toString(StringBuilder.java:405)
  at org.supercsv.encoder.DefaultCsvEncoder.encode(DefaultCsvEncoder.java:93)
  at org.supercsv.io.AbstractCsvWriter.escapeString(AbstractCsvWriter.java:102)
  at org.supercsv.io.AbstractCsvWriter.writeRow(AbstractCsvWriter.java:196)
  at org.supercsv.io.AbstractCsvWriter.writeRow(AbstractCsvWriter.java:146)
  at org.supercsv.io.CsvListWriter.write(CsvListWriter.java:71)
  at com.optrak.data.writing.CsvWriting$CsvFileWriter$$anonfun$write$1.apply(CsvWriting.scala:42)

and sometimes

java.lang.ArrayIndexOutOfBoundsException: -28
  at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:588)
  at java.lang.StringBuilder.append(StringBuilder.java:214)
  at org.supercsv.encoder.DefaultCsvEncoder.encode(DefaultCsvEncoder.java:81)
  at org.supercsv.io.AbstractCsvWriter.escapeString(AbstractCsvWriter.java:102)
  at org.supercsv.io.AbstractCsvWriter.writeRow(AbstractCsvWriter.java:196)
  at org.supercsv.io.AbstractCsvWriter.writeRow(AbstractCsvWriter.java:146)
  at org.supercsv.io.CsvListWriter.write(CsvListWriter.java:71)
  at com.optrak.data.writing.CsvWriting$CsvFileWriter$$anonfun$write$1.apply(CsvWriting.scala:42)

with different out-of-bounds indices, usually negative. The last stack frame shown (full output is omitted) points to line 2 of the above code. I am actually using the code in 2 different specs2 test cases. Sometimes both fail, sometimes one. If I get an exception in both test cases, the index which is out of bounds is the same or differs by one. What might be causing this seemingly random behavior, how can I find the cause and make this predictable?


Solution

  • It looks like an instance of this bug which has been fixed in the latest release (2.2.1).