ArrayIndexOutOfBoundsException for listStatements() in Inferred Model

[GANys]

Morning Galigator,

I'm using openllet 2.6.3 snapshot in my new Jena application and InfModel.listStatements(); seems to work oddly.

After creating and reading my ontology and inferring it, I'm a not able to list the statements. A simple request on a special unique statement works.

InfModel model = ModelFactory.createInfModel(PelletReasonerFactory.theInstance().create(), afferedOntology);
model.listStatements();

The error happens directly in Openllet so I ask you if you ever met such an issue.

Thx in advance,

GA

Here is the log of the Exception :

> 2018-03-23 16:54:52 SEVERE OntoSPC main null
> java.lang.ArrayIndexOutOfBoundsException
> 	at java.lang.System.arraycopy(Native Method)
> 	at openllet.core.rules.rete.BetaMemoryIndex$Unindexed.restore(BetaMemoryIndex.java:100)
> 	at openllet.core.rules.rete.BetaMemoryNode.restore(BetaMemoryNode.java:101)
> 	at openllet.core.rules.rete.ReteNode.restore(ReteNode.java:58)
> 	at openllet.core.rules.rete.BetaMemoryNode.restore(BetaMemoryNode.java:100)
> 	at openllet.core.rules.rete.ReteNode.restore(ReteNode.java:58)
> 	at openllet.core.rules.rete.ReteNode.restore(ReteNode.java:58)
> 	at openllet.core.rules.rete.BetaMemoryNode.restore(BetaMemoryNode.java:100)
> 	at openllet.core.rules.rete.ReteNode.restore(ReteNode.java:58)
> 	at openllet.core.rules.rete.ReteNode.restore(ReteNode.java:58)
> 	at openllet.core.rules.rete.BetaMemoryNode.restore(BetaMemoryNode.java:100)
> 	at openllet.core.rules.rete.ReteNode.restore(ReteNode.java:58)
> 	at openllet.core.rules.rete.ReteNode.restore(ReteNode.java:58)
> 	at openllet.core.rules.rete.Interpreter.restore(Interpreter.java:55)
> 	at openllet.core.rules.ContinuousRulesStrategy.restoreRules(ContinuousRulesStrategy.java:419)
> 	at openllet.core.rules.ContinuousRulesStrategy.restore(ContinuousRulesStrategy.java:387)
> 	at openllet.core.tableau.completion.SROIQStrategy.backtrack(SROIQStrategy.java:99)
> 	at openllet.core.rules.ContinuousRulesStrategy.complete(ContinuousRulesStrategy.java:275)
> 	at openllet.core.boxes.abox.ABoxImpl.lambda$isConsistent$12(ABoxImpl.java:1417)
> 	at openllet.core.utils.Timers.execute(Timers.java:118)
> 	at openllet.core.boxes.abox.ABoxImpl.isConsistent(ABoxImpl.java:1417)
> 	at openllet.core.boxes.abox.ABoxImpl.isConsistent(ABoxImpl.java:1269)
> 	at openllet.core.KnowledgeBaseImpl.consistency(KnowledgeBaseImpl.java:2178)
> 	at openllet.core.KnowledgeBaseImpl.isConsistent(KnowledgeBaseImpl.java:2253)
> 	at openllet.jena.PelletInfGraph.prepare(PelletInfGraph.java:260)
> 	at openllet.jena.PelletInfGraph.prepare(PelletInfGraph.java:245)
> 	at openllet.jena.PelletInfGraph.findWithContinuation(PelletInfGraph.java:163)
> 	at org.apache.jena.reasoner.BaseInfGraph.graphBaseFind(BaseInfGraph.java:371)
> 	at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:255)
> 	at org.apache.jena.graph.Graph.find(Graph.java:111)
> 	at org.apache.jena.graph.GraphUtil.findAll(GraphUtil.java:102)
> 	at org.apache.jena.rdf.model.impl.ModelCom.listStatements(ModelCom.java:1130)
> 	at OntoSPC.main(OntoSPC.java:48)

[Galigator]

There is no currently open issue for this kind of bug.

[OrangieLou]

Hello,
I can second this bug. I get the same exception when using the OntModel like this:

OntModel ontModel = ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC); ontModel.read(file); StmtIterator sit = ontModel.listStatements();

It doesn't happen with every ontology, so it may have something to do with the vocabulary used.
Are you still working on this project? Then I'll put some effort into finding out which vocabulary is responsible for that.

Thanks in advance.

[Galigator]

So to show the bug we may use another strategy, we have small program that take an ontology that cause a crash/exception and search for a minimal set of axioms that produce the crash/exception; and it rename every entities in it.

This program can be use the following way :

git clone https://github.com/Galigator/openllet.git
cd openllet/tools-pellint/
./searchMinimalBug.sh /path/to/the/problematic/ontology/file.owl

(it use maven compile then run)

The program use a random strategy and all yours cpu to search a sub-ontology that create the crash.
The found sub-ontology is put into the file "minimalOntologyFile.owl".

The program is 'any-time' (aka it can be stop any time with an ontology that is smaller that your original ontology, once it have check consistency at least one time); because it is random based, you can run it on many computer as you have.

Even if you find a small ontology, right now I don't have time to spend on debuging, sorry.

[DramaticallyDecayed]

Hello!
I've got the same error. At some cases the problem is not reproduced, e.g. sometimes in a debugging regime. Also, if one ignores the problem (catch the exception) then it is possible to get a partial answer.

A hypothesis is that the problem is not in the ontology, but in the code. Look at the class openllet.core.rules.rete.BetaMemoryIndex.Unindexed , method restore. I have added one line of code to repair the problem and highlighted it with comments:

@Override
public void restore(final int branch)
{
	int i = 0;
	int removed = 0;
	for (; i < size; i++)
	{
		final Token token = index[i];
		if (token.dependsOn(branch))
			removed++;
		else
			if (removed > 0)
			{
				System.arraycopy(index, i, index, i - removed, size - i);
				size -= removed;
                                //###################start repair#######################
                                removed = 0
                                //###################end repair#######################
			}
	}

	if (removed > 0)
	{
		System.arraycopy(index, i, index, i - removed, size - i);
		size -= removed;
	}
}

Explanation. Possibly I do not properly understand the algorithm so I give some explanations.
The goal of the method is to remove some undesired elements from the array. To do so, you fix a number of successive elements to be removed and then copy the tail of the array over the sequence of removed elements. To consider the case when such elements are at the end of the array you check removed variable after the for-cycle.
Bu the problem arises when it is necessary to remove two or more sequences of elements, especially when the last sequence is at the very tail of the array. As you do not reset removed variable, you are removing "additively", i.e. each time you remove not the number of elements corresponding to the last seen sequence but the number of all removed elements you have seen before. So that you may finish up with a situation when you want to remove more elements than you have.

Thank you!

[Galigator]

Nice catch !
I have just add your correction and all tests are still good. With this correction in mind maybe we can design a test to this specific bug.

347d802
(oups my code style corrector have add some more changes.)

Thank you @DramaticallyDecayed