Crash by NullPointerException, version 5.6.3

[mapio]

Running the CLI version 5.5.7 and also version 5.6.3 on GNU/Linux with a moderately large file (but small masses, less than 850) I encounter the following error

java.lang.NullPointerException: Cannot invoke "de.unijena.bioinf.ChemistryBase.ms.ft.FTree.getTreeWeight()" because "solve.tree" is null
    at de.unijena.bioinf.FragmentationTreeConstruction.computation.FasterTreeComputationInstance.recalibrate(FasterTreeComputationInstance.java:577)
    at de.unijena.bioinf.FragmentationTreeConstruction.computation.FasterTreeComputationInstance$RecalibrationJob.compute(FasterTreeComputationInstance.java:545)
    at de.unijena.bioinf.FragmentationTreeConstruction.computation.FasterTreeComputationInstance$RecalibrationJob.compute(FasterTreeComputationInstance.java:531)
    at de.unijena.bioinf.jjobs.BasicJJob.call(BasicJJob.java:117)
    at de.unijena.bioinf.jjobs.BasicMasterJJob$1.compute(BasicMasterJJob.java:101)
    at java.base/java.util.concurrent.RecursiveTask.exec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinTask.awaitDone(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinTask.join(Unknown Source)
    at de.unijena.bioinf.jjobs.BasicJJob.awaitResult(BasicJJob.java:205)
    at de.unijena.bioinf.jjobs.JJob.takeResult(JJob.java:248)
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
    at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
    at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)
    at java.base/java.util.stream.ReferencePipeline.collect(Unknown Source)
    at de.unijena.bioinf.FragmentationTreeConstruction.computation.FasterTreeComputationInstance.estimateTreeSizeAndRecalibration(FasterTreeComputationInstance.java:304)
    at de.unijena.bioinf.FragmentationTreeConstruction.computation.FasterTreeComputationInstance.compute(FasterTreeComputationInstance.java:173)
    at de.unijena.bioinf.FragmentationTreeConstruction.computation.FasterTreeComputationInstance.compute(FasterTreeComputationInstance.java:55)
    at de.unijena.bioinf.jjobs.BasicJJob.call(BasicJJob.java:117)
    at de.unijena.bioinf.jjobs.BasicMasterJJob$1.compute(BasicMasterJJob.java:101)
    at java.base/java.util.concurrent.RecursiveTask.exec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinTask.awaitDone(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinTask.join(Unknown Source)
    at de.unijena.bioinf.jjobs.BasicJJob.awaitResult(BasicJJob.java:205)
    at de.unijena.bioinf.sirius.Sirius$SiriusIdentificationJob.compute(Sirius.java:631)
    at de.unijena.bioinf.sirius.Sirius$SiriusIdentificationJob.compute(Sirius.java:614)
    at de.unijena.bioinf.jjobs.BasicJJob.call(BasicJJob.java:117)
    at java.base/java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)

that seems related to #48.

Any clues on why this happens?

[mfleisch]

Hey, ist this issue reproducible. So does it happen every time when are analyzing this file? If yes could you share the file?

Best Markus

[mapio]

Sure it is reproducible, it happens at every run.

I've put the input file causing the above stack trace (both in version 5.5.7 and 5.6.3) in https://github.com/mapio-lp/sirius-bug-data/ repo and added you with read permission.

Sorry for the inconvenience, but the data comes from a company that asked me to sign an NDA on all their data (but allowed me to share the input file privately with you).

The command line arguments used for the run are -i ./p301.mgf -o ./sirius_output/ --maxmz 850 --log ALL --naming-convention %compoundname config --IsotopeSettings.filter=true --FormulaSearchDB="" --Timeout.secondsPerTree=0 --FormulaSettings.enforced=HCNOPS --Timeout.secondsPerInstance=0 --AdductSettings.detectable="[[M - H4O2 + H]+, [M + Na]+, [M + H]+, [M - H2O + H]+, [M + H3N + H]+]" --UseHeuristic.mzToUseHeuristicOnly=650 --AlgorithmProfile=orbitrap --IsotopeMs2Settings=SCORE --MS2MassDeviation.allowedMassDeviation=5.0ppm --NumberOfCandidatesPerIon=1 --UseHeuristic.mzToUseHeuristic=300 --FormulaSettings.detectable=B,Cl,Br,S --NumberOfCandidates=3 --AdductSettings.fallback="[[M - H4O2 + H]+, [M + Na]+, [M + H]+, [M - H2O + H]+, [M + H3N + H]+]" --RecomputeResults=true formula write-summaries.

I've attempted a run using CPLEX and one without, but the error reported is the same.

[mapio]

Dear @mfleisch are there any news? I'm linking @Mattesimone who is also interested in the issue.

[mfleisch]

Hey, I will be able to look into this at the end of this week.

[marcus-ludwig]

Hi, I believe we fixed this. The real issues in the background occurred when scoring isotopes in MS2 for M+Na compounds. The NullPointer is just a result of this, but is also fixed now.

[mapio]

I've downloaded the latest release (5.6.3) and I still can reproduce the error under the same conditions of the original report :(

You plan to include the fix you mention in the closing message in a future release, or you expected it to be already in 5.6.3?

In this case, can you please confirm that the bug persists (with the same input file) and reopen the bug?

[marcus-ludwig]

Sorry, I didn't specify: I fixed this yesterday and it is now in our pre-release version 5.6.4-SNAPSHOT. https://github.com/boecker-lab/sirius/releases/tag/v5.6.4-SNAPSHOT

[mapio]

I confirm that, at least on the data cited in this bug-report, the issue seems to be solved. Thanks a lot!