An oddity:
The only way I can see to set with a null binding (and not get a
warning) is on the path where the dataset is not a TDB one, but with a
graph in a general dataset.
Is that the setup here?
(that said, tracing down and eliminating all other possible routes back
isn't simple so I might have missed another route)
Andy
On 06/02/18 14:24, Andy Seaborne wrote:
Can you dump the database?
On 06/02/18 10:32, Jean-Marc Vanel wrote:
Hi
I consistently get a NullPointerException from this query on my test TDB
on laptop.
SELECT DISTINCT ?thing
WHERE {
graph ?thing {
[] ?p ?O .
}
} LIMIT 200
Looking into code : BindingBase.java line 203 , it appears that a
binding's
node is null for one SELECT result.
In which case there is a binding and the value (Node) is null.
We can put in null checks to catch it earlier (that would be a good idea
anyway) but still not at the point where the problem starts because
there isn't one such point - it depends on cache flush order.
This binding stands for a named graph.
Just a though - do your named graph have URI names? or are any blank nodes?
So the database is probably broken. Of course, this is a work and test
database whose content has no value, but I try to understand and prevent
this to happen on production database.
Is a there a bug somewhere ?
Yes :-) Where? now that is the question!
What is the likely cause ? During tests and debugs, transactions may have
not been rolled back , application was killed, etc .
How could the database be repaired in such cases ? By doing a tdbdump and
recreate the TDB ?
Non-transactional TDB needs to explicitly flush modification to disk
(TDB.sync). Now due to caching something are being written all the time
but not competently and consistently.
If an index gets to disk, with new Nodes (not already used) nodes, then
the NodeTable also needs to be written. If it is not, a later lookup of
the NodeId can't find the node -> null.
If it is transactional, and is always used transactionally, the problem
does not arise.
You might try TDB2 - it does not allow non-transactional use.
In the future, it might get an "autocommit" feature ... but then users@
will get questions about why it is so slow. Full SQL compatibility!
Andy
Running on Jena 3.6.0 and Ubuntu 2017.10 and java version "1.8.0_121" .
java.lang.NullPointerException
at
org.apache.jena.sparql.engine.binding.BindingBase.hashCode(BindingBase.java:203)
at
org.apache.jena.sparql.engine.binding.BindingBase.hashCode(BindingBase.java:183)
at java.util.HashMap.hash(HashMap.java:338)
at java.util.HashMap.containsKey(HashMap.java:595)
at java.util.HashSet.contains(HashSet.java:203)
at
org.apache.jena.sparql.engine.iterator.QueryIterDistinct.getInputNextUnseen(QueryIterDistinct.java:106)
at
org.apache.jena.sparql.engine.iterator.QueryIterDistinct.hasNextBinding(QueryIterDistinct.java:70)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIterSlice.hasNextBinding(QueryIterSlice.java:76)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
* at
org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:55)*
at
scala.collection.convert.Wrappers$JIteratorWrapper.hasNext(Wrappers.scala:42)
at scala.collection.Iterator$class.toStream(Iterator.scala:1320)
at scala.collection.AbstractIterator.toStream(Iterator.scala:1334)
at
scala.collection.Iterator$$anonfun$toStream$1.apply(Iterator.scala:1320)
at
scala.collection.Iterator$$anonfun$toStream$1.apply(Iterator.scala:1320)
at scala.collection.immutable.Stream$Cons.tail(Stream.scala:1233)
at scala.collection.immutable.Stream$Cons.tail(Stream.scala:1223)
at
scala.collection.immutable.Stream$$anonfun$map$1.apply(Stream.scala:418)
at
scala.collection.immutable.Stream$$anonfun$map$1.apply(Stream.scala:418)
at scala.collection.immutable.Stream$Cons.tail(Stream.scala:1233)
at scala.collection.immutable.Stream$Cons.tail(Stream.scala:1223)
at scala.collection.generic.Growable$class.loop$1(Growable.scala:54)
at
scala.collection.generic.Growable$class.$plus$plus$eq(Growable.scala:57)
at
scala.collection.mutable.ListBuffer.$plus$plus$eq(ListBuffer.scala:183)
at
scala.collection.mutable.ListBuffer.$plus$plus$eq(ListBuffer.scala:45)
at
scala.collection.TraversableLike$class.to(TraversableLike.scala:590)
at scala.collection.AbstractTraversable.to(Traversable.scala:104)
at
deductions.runtime.sparql_cache.SPARQLHelpers$$anonfun$sparqlSelectQueryVariablesNT$1.apply(SPARQLHelpers.scala:426)
