Rdf_loader in parallel, uneven length cols after insert

Dear Virtuoso team,

I ran into this unfortunate crash. Is there something that I am doing wrong? there are 32 rdf bulk loaders loading in parallel.

09:19:17 ./virtuoso-t() [0xad844c]
09:19:17 ./virtuoso-t() [0xad84d6]
09:19:17 ./virtuoso-t() [0x46b919]
09:19:17 ./virtuoso-t() [0x46d565]
09:19:17 ./virtuoso-t() [0x47168c]
09:19:17 ./virtuoso-t() [0x71fd53]
09:19:17 ./virtuoso-t() [0x68e845]
09:19:17 ./virtuoso-t() [0x68ebc5]
09:19:17 ./virtuoso-t() [0x6892c5]
09:19:17 ./virtuoso-t() [0x69580f]
09:19:17 ./virtuoso-t() [0x7592eb]
09:19:17 ./virtuoso-t() [0x75932d]
09:19:17 ./virtuoso-t() [0x41251a]
09:19:17 ./virtuoso-t() [0xae6ef5]
09:19:17 /lib64/libpthread.so.0(+0x814a) [0x7f056295314a]
09:19:17 /lib64/libc.so.6(clone+0x43) [0x7f05620fef23]
09:19:17 GPF: colins.c:3416 uneven length cols after insert
GPF: colins.c:3416 uneven length cols after insert

Regards,
Jerven

Is this occurring during and new Uniport data load and if so a what point in the load is it occurring and is it consistently occurring ?

I presume your running the Version 7.2.6-rc1.3231-pthreads as of Jan 21 2021 (928feb5) build last indicated to being used or later build ?

Can you run the backup '/dev/null'; database integrity check for any database corruption.

Is a core file created (with ulimit -c unlimited set) from which a gdb stack trace could be obtain to get more information as to the location of the failure ?

This happened with a running 07.20.3232-pthreads for Linux as of Apr 22 2021.

I had to delete the database files and restarted the process from scratch. Let’s see if it happens again then I can do the integrity check. It is not the first time I have seen it but it is not a deterministic error.