robot: Combination of remove and filter causes stack overflow
The test is here (ROBOT 1.4.1)
git clone https://github.com/monarch-ebi-dev/robot_test.git
cd robot_test
make fail-remove-filter.owl
The command run is:
robot remove --input input-fail-remove-filter.owl --axioms equivalent \
filter --term-file simple_seed.txt --trim true --signature true --output fail-remove-filter.owl
The error message is:
Exception in thread "main" java.lang.StackOverflowError
at com.carrotsearch.hppcrt.maps.ObjectObjectHashMap.hashKey(ObjectObjectHashMap.java:136)
at com.carrotsearch.hppcrt.maps.ObjectObjectHashMap.get(ObjectObjectHashMap.java:779)
at uk.ac.manchester.cs.owl.owlapi.MapPointer.get(MapPointer.java:382)
at uk.ac.manchester.cs.owl.owlapi.MapPointer.getValues(MapPointer.java:191)
at uk.ac.manchester.cs.owl.owlapi.OWLImmutableOntologyImpl.getAxioms(OWLImmutableOntologyImpl.java:1325)
at uk.ac.manchester.cs.owl.owlapi.OWLAxiomIndexImpl.getSubClassAxiomsForSubClass(OWLAxiomIndexImpl.java:136)
at uk.ac.manchester.cs.owl.owlapi.concurrent.ConcurrentOWLOntologyImpl.getSubClassAxiomsForSubClass(ConcurrentOWLOntologyImpl.java:1768)
at org.semanticweb.owlapi.search.EntitySearcher.getSuperClasses(EntitySearcher.java:805)
at org.obolibrary.robot.RelatedObjectsHelper.getSuperClasses(RelatedObjectsHelper.java:1014)
at org.obolibrary.robot.RelatedObjectsHelper.spanGapsHelper(RelatedObjectsHelper.java:1407)
What is weird that only the combination of these two commands causes the problem; neither in isolation does!
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 16 (16 by maintainers)
Thanks @ignazio1977! Sorry for the delay in response, we’ve been getting ready for a conference. This patch works great at resolving the stack overflow. I’m not sure why I didn’t use sets in the first place… silly oversight. It looks like all our tests still pass as well.
Hi, @matentzn pointed me at this issue to see if I had any clues as to what’s going wrong.
I’ve played around with the code where the stack overflow issue happens, and I believe there’s an issue in
RelatedObjectsHelper- the gap spanning axioms are created from lists of relations, but when recurring to create the elements for these lists there is no test to check if the relation being added is already in the list. If it is, it means that particular path has already been explored and it’s not necessary to continue the recursion.I am guessing as to what the intent in the code is - haven’t looked into it enough to be sure I’m not missing something important. However, if I’m right, the fix is straightforward and computationally inexpensive: simply stop the recursion once the relation being examined is already in the list of known relations. Replacing the list with a set slightly increases the memory requirements, but it also removes the creation of duplicate axioms that would happen even in a DAG scenario, and it allows the code to deal with cycles as the ones found here (@matentzn example finishes running in a few seconds on my very dated laptop, with default memory allocation).
The patch implementing my fix is as follows:
I agree with Jim
On Mon, Jul 22, 2019, 04:40 Jim Balhoff notifications@github.com wrote:
This makes sense to me. I don’t see the value in it for the graph traversal use case. Of course when a named class is part of an expression (A and r some B), A would still get relaxed.