virtuoso-opensource icon indicating copy to clipboard operation
virtuoso-opensource copied to clipboard

SPARQL query causes Virtuoso to crash without log

Open l-ellenbeck opened this issue 1 year ago • 7 comments

We are running virtuoso in a container. In a default container, without any modification and the basic settings, running the following query crashes the container in the version virtuoso-opensource-7:7.2.12 and virtuoso-opensource-7:7.2.13

SELECT ?g ?m WHERE {                
  GRAPH <https://purl.org/xxxx/resources/a5c139eb-d3fe-4ca6-8685-f81947063677> {
      <https://purl.org/xxxx/resources/a5c139eb-d3fe-4ca6-8685-f81947063677> <http://www.w3.org/ns/dcat#catalog> ?g .
  }
  
  GRAPH ?g{
      ?g a <http://purl.org/fdp/fdp-o#MetadataService> .
      ?g <http://purl.org/fdp/fdp-o#hasMetadata> ?m .
  }
  
  GRAPH ?m {
      ?m <http://purl.org/fdp/fdp-o#hasMetadata> ?version .
  }
}

The query is a minimal example, as the original is more complex (and also fails).

This query worked and still works in the container version virtuoso-opensource-7:7.2.11. This seems to be a regression in capabilities.

Most concerning is, that we don't get any log entry from Virtuoso. The written logs and logs of the container itself just end with the immediate termination of the container. The crash appears to be instant and was reproduced on a separate machine.

We use Rocky 9 Linux and podman and podman-compose in the newest version

Here is the relevant compose entry:

  virtuoso:
    image: docker.io/openlink/virtuoso-opensource-7:7.2.12
    userns_mode: host
    environment:
      DBA_PASSWORD: dba
    volumes:
      - ./.data/virtuoso/:/database
      - ./.config/virtuoso/virtuoso.ini:/database/virtuoso.ini

The virtuoso.ini was in default settings and with extended bytes and had no effect.

l-ellenbeck avatar Jun 18 '24 10:06 l-ellenbeck

Development is looking into this issue

pkleef avatar Jun 18 '24 10:06 pkleef

The issue seems to be related to the datasets loaded into your database.

Did you load publicly available datasets into your database, so we can recreate your database in-house?

pkleef avatar Jun 18 '24 13:06 pkleef

Actually, I did not create a custom database for this.

I use the mount to persist the created database. However, for the tests, I started in a clean state without a database.

I just started the container without giving out any database values or files. Virtuoso then created the default database.

I had the problem happen with a freshly created (by the Virtuoso container) database and in our development state database.

l-ellenbeck avatar Jun 18 '24 13:06 l-ellenbeck

I just checked again to be sure, but the error now did not appear. I "deleted" the existing database and recreated it in 12. Now the query works.

I suspect, that having the database in the version of 11 and switching to another version (12 or 13) caused this error.

And I just tested it. I did the following:

  • Removed any existing database or folder from virtuoso
  • Set the container tag to virtuoso-opensource-7:7.2.11
  • Compose up
  • Test the query and it works
  • Kill container
  • Edit compose file to use tag virtuoso-opensource-7:7.2.12
  • Compose up (Reusing the existing folder)
  • Test query and the container crashes instantly

Would sharing any of the following files help you? image

l-ellenbeck avatar Jun 18 '24 14:06 l-ellenbeck

Can you tar + compress your ./.data/virtuoso/ directory and make it available for me to download?

pkleef avatar Jun 18 '24 15:06 pkleef

I have emailed you the tar file to [email protected]

l-ellenbeck avatar Jun 18 '24 16:06 l-ellenbeck

I attempted to recreate the issue, but using docker 24.0.7 on Ubuntu 24.04, instead of podman on Rocky 9. My test did not show the problem you reported.

We also tested the database you provided to check if it was damaged in some way, but i am happy to report that your database is completely fine.

So next i will be setting up a Rocky 9 VM and see what podman does.

pkleef avatar Jun 21 '24 10:06 pkleef