NullPointerException and deadlock

[gibello]

Characteristics

• Issue Type: bug
• Reproducibility: always
• Severity: block
• Tool/Service/Component: Botsing 1.0.8-SNAPSHOT
• Execution Environment: Ubuntu Linux 18.04
• Reporter: Pierre-Yves Gibello, [email protected]

Description

NullPointerException, and botsing hangs forever (command line).

Steps to reproduce

Joram project (gitlab.ow2.org/joram/joram).

Attached exception trace:
test.txt

To generate classpath, from joram/joram directory:

mvn dependency:copy-dependencies -DoutputDirectory=/tmp/deps

Then run botsing on frame 6:

java -jar botsing-reproduction-1.0.8-SNAPSHOT.jar -project_cp /tmp/deps -crash_log <path_to_exception_trace> -target_frame 6

The following error occurs, and botsing gets stuck forever:

16:11:08.339 [main] INFO  eu.stamp.botsing.StackTrace - Exception type is detected: java.net.ConnectException
16:11:08.345 [main] WARN  eu.stamp.botsing.StackTrace - Missing line in frame 1
16:11:08.350 [main] INFO  eu.stamp.botsing.StackTrace - Target frame is set to: java.net.Socket.connect(Socket:589)
16:11:08.350 [main] INFO  eu.stamp.botsing.StackTrace - Target Class is set to: java.net.Socket
16:11:08.821 [main] INFO  e.s.b.reproduction.CrashReproduction - Starting the dependency analysis. The number of detected jar files is 72.
16:11:25.142 [main] INFO  e.s.b.reproduction.CrashReproduction - Analysing dependencies done!
16:11:25.206 [main] INFO  e.s.b.t.s.BotsingIndividualStrategy - test generation strategy: Botsing individual
Exception in thread "main" java.lang.NullPointerException
	at eu.stamp.botsing.ga.strategy.operators.GuidedSearchUtility.getTargetInstruction(GuidedSearchUtility.java:173)
	at eu.stamp.botsing.ga.strategy.operators.GuidedSearchUtility.getPublicCalls(GuidedSearchUtility.java:77)
	at eu.stamp.botsing.ga.strategy.operators.GuidedSearchUtility.getPublicCalls(GuidedSearchUtility.java:98)
	at eu.stamp.botsing.ga.strategy.operators.GuidedSearchUtility.collectPublicCalls(GuidedSearchUtility.java:30)
	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:46)
	at eu.stamp.botsing.testgeneration.strategy.TestGenerationUtility.getGA(TestGenerationUtility.java:26)
	at eu.stamp.botsing.testgeneration.strategy.BotsingIndividualStrategy.generateTests(BotsingIndividualStrategy.java:61)
	at eu.stamp.botsing.reproduction.CrashReproduction.generateCrashReproductionTests(CrashReproduction.java:123)
	at eu.stamp.botsing.reproduction.CrashReproduction.execute(CrashReproduction.java:72)
	at eu.stamp.botsing.Botsing.parseCommandLine(Botsing.java:91)
	at eu.stamp.botsing.Botsing.main(Botsing.java:213)

[pderakhshanfar]

Hi @gibello,
The given stack trace to Botsing should not contain any frame without a line number. In your trace, the first frame is at java.net.PlainSocketImpl.socketConnect(Native Method). You can remove this frame manually, or you can use the pre-processor, developed by Engineering, to filter the frames without the line number.

[gibello]

Hi @pderakhshanfar,
I agree. But there should never be a NPE (and a deadlock !).
NPEs are bugs, deadlocks are bugs, whatever happens. And they must be fixed.
An error message would be a good idea: or if not possible, simply end cleanly with no test generated.

[pderakhshanfar]

@gibello, yes, you are right. In the next release, I will make sure that this exception is handled properly.