`IndexOutOfBoundsExcepion` in `GuidedSearchUtility.collectPublicCalls`

[CoolTomatos]

Characteristics

• Issue Type: bug
• Reproducibility: always
• Severity: major, crash
• Tool/Service/Component: botsing-reproduction-1.0.8
• Execution Environment: macOS 10.15.1, jdk 1.8.0_231
• Reporter: @CoolTomatos , [email protected]

Description

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 10, Size: 10
	at java.util.ArrayList.rangeCheck(ArrayList.java:657)
	at java.util.ArrayList.get(ArrayList.java:433)
	at eu.stamp.botsing.ga.strategy.operators.GuidedSearchUtility.collectPublicCalls(GuidedSearchUtility.java:35)
	at eu.stamp.botsing.fitnessfunction.testcase.factories.StackTraceChromosomeFactory.fillPublicCalls(StackTraceChromosomeFactory.java:206)
	at eu.stamp.botsing.fitnessfunction.testcase.factories.StackTraceChromosomeFactory.<init>(StackTraceChromosomeFactory.java:70)
	at eu.stamp.botsing.testgeneration.strategy.TestGenerationUtility.getChromosomeFactory(TestGenerationUtility.java:47)
	at eu.stamp.botsing.testgeneration.strategy.TestGenerationUtility.getGA(TestGenerationUtility.java:27)
	at eu.stamp.botsing.testgeneration.strategy.BotsingIndividualStrategy.generateTests(BotsingIndividualStrategy.java:61)
	at eu.stamp.botsing.reproduction.CrashReproduction.generateCrashReproductionTests(CrashReproduction.java:113)
	at eu.stamp.botsing.reproduction.CrashReproduction.execute(CrashReproduction.java:60)
	at eu.stamp.botsing.Botsing.parseCommandLine(Botsing.java:96)
	at eu.stamp.botsing.Botsing.main(Botsing.java:163)

Steps to reproduce

Run botsing against LANG-9b with target frame 8.

[CoolTomatos]

The original crash log of LANG-9b is:

java.lang.ArrayIndexOutOfBoundsException: 4
 1 |	at org.apache.commons.lang3.time.FastDateParser.toArray(FastDateParser.java:413)
 2 |	at org.apache.commons.lang3.time.FastDateParser.getDisplayNames(FastDateParser.java:381)
 3 |	at org.apache.commons.lang3.time.FastDateParser$TextStrategy.addRegex(FastDateParser.java:664)
 4 |	at org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:138)
 5 |	at org.apache.commons.lang3.time.FastDateParser.<init>(FastDateParser.java:108)
 6 |	at org.apache.commons.lang3.time.FastDateFormat.<init>(FastDateFormat.java:370)
 7 |	at org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:91)
 8 |	at org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:88)
 9 |	at org.apache.commons.lang3.time.FormatCache.getInstance(FormatCache.java:82)
10 |	at org.apache.commons.lang3.time.FastDateFormat.getInstance(FastDateFormat.java:165)

The problem is that at line 88 an anonymous inner class (FastDateFormat$1) is defined, inside which the method createInstance is overridden, and an object of that class is signed to a field.

88 | private static final FormatCache<FastDateFormat> cache= new FormatCache<FastDateFormat>() {
89 |     @Override
90 |     protected FastDateFormat createInstance(String pattern, TimeZone timeZone, Locale locale) {
91 |         return new FastDateFormat(pattern, timeZone, locale);
92 |     }
93 | };

In the bytecode of the inner class:

• there are 3 methods:
  1. the constructor <init>, points to line 88;
  2. the overridden createInstance method, points to line 91.
  3. the original createInstance method, points to line 88, marked as synthetic bridge; (The method we are interested in according to the stack trace)
• EvoSuite ignores syntheic bridge methods, see https://github.com/STAMP-project/evosuite-ramp/blob/6f61633f7699eb5d2c12ff5b9a39f5cda933a36c/client/src/main/java/org/evosuite/graphs/cfg/CFGClassAdapter.java#L96-L99 So when we call BytecodeInstructionPool.getInstructionsIn, we won't be able to get the one we want.

Under these circumstances, Botsing thinks the target method is <init> which will never match the name from the stack trace. And eventually an IndexOutOfBoundsException will be thrown as botsing checks higher frames when the name doesn't match.