Not found local variable during method analysis

[Damtev]

Description

Symbolic analysis for method com.huawei.sof.benchmark.Solution2310139#func_1 fails with java.lang.IllegalStateException: r0 not found in the locals.

To Reproduce

1. Clone this: https://rnd-gitlab-msc.huawei.com/mammoth/veso/java-benchmark/-/tree/master/UTbot_test
2. Run tests generation (Java, no mocks, 60+ seconds timeout, not parametrized) for method com.huawei.sof.benchmark.Solution2310139#func_1

Expected behavior

Successful test generation.

Actual behavior

Symbolic analysis fails with an exception (see idea.log):

Test generation failed on stmt $r3 = staticinvoke <org.xml.sax.helpers.XMLReaderFactory: java.lang.Object findServiceProvider(java.lang.Class,java.lang.ClassLoader)>(class "Lorg/xml/sax/XMLReader;", r0), symbolic stack trace:
<org.xml.sax.helpers.XMLReaderFactory: org.xml.sax.XMLReader createXMLReader()>
<com.huawei.sof.benchmark.Solution2310139: void func_1(org.xml.sax.ContentHandler,java.lang.String)>
java.lang.IllegalStateException: r0 not found in the locals
	at org.utbot.engine.Traverser.resolve(Traverser.kt:1633) ~[Traverser.class:?]
	at org.utbot.engine.Traverser.resolveParameters(Traverser.kt:1767) ~[Traverser.class:?]
	at org.utbot.engine.Traverser.staticInvoke(Traverser.kt:2211) ~[Traverser.class:?]
	at org.utbot.engine.Traverser.invokeResult(Traverser.kt:2108) ~[Traverser.class:?]
	at org.utbot.engine.Traverser.traverseAssignStmt(Traverser.kt:684) ~[Traverser.class:?]
	at org.utbot.engine.Traverser.traverseStmt(Traverser.kt:296) ~[Traverser.class:?]
	at org.utbot.engine.Traverser.traverse(Traverser.kt:279) ~[Traverser.class:?]
	at org.utbot.engine.UtBotSymbolicEngine$traverseImpl$1.invokeSuspend(UtBotSymbolicEngine.kt:347) ~[UtBotSymbolicEngine$traverseImpl$1.class:?]
	at org.utbot.engine.UtBotSymbolicEngine$traverseImpl$1.invoke(UtBotSymbolicEngine.kt) ~[UtBotSymbolicEngine$traverseImpl$1.class:?]
	at kotlinx.coroutines.flow.SafeFlow.collectSafely(Builders.kt:61) ~[SafeFlow.class:?]
	at kotlinx.coroutines.flow.AbstractFlow.collect(Flow.kt:212) ~[AbstractFlow.class:?]
	at kotlinx.coroutines.flow.FlowKt__EmittersKt$onStart$$inlined$unsafeFlow$1.collect(SafeCollector.common.kt:120) ~[FlowKt__EmittersKt$onStart$$inlined$unsafeFlow$1.class:?]
	at kotlinx.coroutines.flow.FlowKt__EmittersKt$onCompletion$$inlined$unsafeFlow$1.collect(SafeCollector.common.kt:114) ~[FlowKt__EmittersKt$onCompletion$$inlined$unsafeFlow$1.class:?]
	at org.utbot.framework.plugin.api.TestCaseGenerator$generate$3$1$1.invokeSuspend(TestCaseGenerator.kt:332) ~[TestCaseGenerator$generate$3$1$1.class:?]
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) ~[BaseContinuationImpl.class:?]
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106) ~[DispatchedTask.class:?]
	at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:274) ~[EventLoopImplBase.class:?]
	at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:84) ~[BlockingCoroutine.class:?]
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:59) ~[BuildersKt__BuildersKt.class:?]
	at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source) ~[BuildersKt.class:?]
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:38) ~[BuildersKt__BuildersKt.class:?]
	at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source) ~[BuildersKt.class:?]
	at org.utbot.common.ConcurrencyKt.runBlockingWithCancellationPredicate(Concurrency.kt:38) ~[ConcurrencyKt.class:?]
	at org.utbot.framework.plugin.api.TestCaseGenerator$generate$3.invoke(TestCaseGenerator.kt:144) ~[TestCaseGenerator$generate$3.class:?]
	at org.utbot.framework.plugin.api.TestCaseGenerator$generate$3.invoke(TestCaseGenerator.kt:55) ~[TestCaseGenerator$generate$3.class:?]
	at org.utbot.common.ConcurrencyKt.runIgnoringCancellationException(Concurrency.kt:47) ~[ConcurrencyKt.class:?]
	at org.utbot.framework.plugin.api.TestCaseGenerator.generate(TestCaseGenerator.kt:143) ~[TestCaseGenerator.class:?]
	at org.utbot.intellij.plugin.generator.UtTestsDialogProcessor$createTests$2$1.run(UtTestsDialogProcessor.kt:198) ~[UtTestsDialogProcessor$createTests$2$1.class:?]
	at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:935) ~[?:?]
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcessWithProgressAsync$5(CoreProgressManager.java:442) ~[?:?]
	at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$3(ProgressRunner.java:235) ~[?:?]
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:170) ~[?:?]
	at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:629) ~[?:?]
	at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:581) ~[?:?]
	at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60) ~[?:?]
	at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:157) ~[?:?]
	at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:235) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668) [?:?]
	at java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665) [?:?]
	at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
	at java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]

[alisevych]

@Damtev @denis-fokin
Checked that it's reproducing on the latest UTBotJava plugin build from main. Please take into work for the release.

[CaelmBleidd]

I check it and have some thoughts. Look at the screenshots below:

You can see bijection between source code and graph nodes/edges but look at the edge from $r0 =... to $r4 := @. There is no such instruction in the source code, staticinvoke <jdk.xml.internal.SecuritySupport: java.lang.String getSystemProperty(java.lang.String)>("org.xml.sax.driver" is executed outside of the try section, it has nothing in common with the following catch block. If we remove this transition from the graph, everything works fine.

So, the reason for the error is that we have an unexcepted transition between an instruction that throws an exception and catch block, where we erase information about the exception (since the engine thinks that we processed this exception in catch section. So, we don't save a value for $r0 and should fail but because of the catch section, we continue execution and get an error from the description.

I think it is a bug inside of Soot, since jimpleBody contains correct trapChain with the only instruction, but a graph built from it contains two exceptionalPred for the catch block: $r0 = ... and r5.... For now, I'd leave this issue until the next occurrence as is because it's too complicated to do anything with graph construction inside of Soot.

@Damtev @alisevych what do you think?