Hi,
We were running a simple update SPARQL query for a large set of data.
The update query for replacing one predicate with another, itself is this:
SPARQL DELETE { GRAPH ?graph { ?st
<http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> ?subject . }}
INSERT { GRAPH ?graph { ?st
<http://purl.org/vocab/changeset/schema#subject> ?subject . }} WHERE {
GRAPH ?graph { ?st <http://www.w3.org/1999/02/22-rdf-syntax-ns#subject>
?subject . }} LIMIT 10000000;
The initial count of triples that needed to be updated was ~1 700 000
000. The .sql script used for update set the log_enable(2) at the
beginning, before executing the actual update. And a checkpoint was
called out in the same .sql script after the update query finished. We
were able to run that script for quite a while without any problems.
Suddenly running the script made virtuoso crash, the remaining triples
count that needed updating was around 500 000 000. The error in
virtuoso.log file shows the following:
09:13:37 In delete or rb of insert on RDF_QUAD dp 38144031 seg 6, col 3
is 10909 values and next 8276
09:13:37 /usr/bin/virtuoso-t() [0x8d4afd]
...
09:13:37 /usr/bin/virtuoso-t() [0x53f19b]
09:13:37 /usr/bin/virtuoso-t(delete_node_input+0x13b) [0x5cbb3b]
09:13:37 /usr/bin/virtuoso-t() [0x5c7fed]
09:13:37 /usr/bin/virtuoso-t() [0x5c8416]
09:13:37 /usr/bin/virtuoso-t(table_source_input_unique+0x2a9) [0x5cfe69]
09:13:37 /usr/bin/virtuoso-t() [0x5c7fed]
...
09:13:37 /usr/bin/virtuoso-t() [0x5c826e]
09:13:37 /usr/bin/virtuoso-t(skip_node_input+0x466) [0x5cc9e6]
09:13:37 /usr/bin/virtuoso-t() [0x5c7fed]
...
09:13:37 /usr/bin/virtuoso-t() [0x5db26a]
09:13:37 /usr/bin/virtuoso-t(sf_sql_execute_w+0x74) [0x5db884]
09:13:37 /usr/bin/virtuoso-t() [0x8d8f38]
09:13:37 /usr/bin/virtuoso-t() [0x8df6fc]
09:13:37 /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7f69a6f65182]
09:13:37 /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f69a656f47d]
09:13:37 GPF: collock.c:1410 uneven length cols after delete, update or
rollback of insert
Do get the core dump of the crash set 'ulimit -c unlimited' and started
the script again. The crash is reproducable with every run. The core
dump shows the following:
# gdb virtuoso-t core
...
[New LWP 15882]
[New LWP 15879]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/virtuoso-t +wait +configfile
/etc/virtuoso-opensource-7/virtuoso.ini'.
Program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00000000008d4bde in ?? ()
...
#6 0x000000000053f19b in ?? ()
#7 0x00000000005cbb3b in delete_node_input ()
#8 0x00000000005c7fed in ?? ()
#9 0x00000000005c8416 in ?? ()
#10 0x00000000005cfe69 in table_source_input_unique ()
#11 0x00000000005c7fed in ?? ()
...
#30 0x00000000005c826e in ?? ()
#31 0x00000000005cc9e6 in skip_node_input ()
#32 0x00000000005c7fed in ?? ()
...
#43 0x00000000005db26a in ?? ()
#44 0x00000000005db884 in sf_sql_execute_w ()
#45 0x00000000008d8f38 in ?? ()
#46 0x00000000008df6fc in ?? ()
#47 0x00007f69a6f65182 in start_thread (arg=0x7f691a3bd700) at
pthread_create.c:312
#48 0x00007f69a656f47d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
We run the integrity check of virtuoso with "backup '/dev/null'" and
that passed successfully, so this indicated for us that the database
itself is intact.
The version of virtuoso we are using is:
Virtuoso Open Source Edition (Column Store) (multi threaded)
Version 7.2.0.3212-pthreads as of Apr 8 2015
Compiled for Linux (x86_64-pc-linux-gnu)
Copyright (C) 1998-2015 OpenLink Software
Do you have any suggestions why this happened and how can it be fixed?
Best regards,
Piret Lattikas
------------------------------------------------------------------------------
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
