Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPARQL query causes Virtuoso to crash without log #1301

Open
l-ellenbeck opened this issue Jun 18, 2024 · 7 comments
Open

SPARQL query causes Virtuoso to crash without log #1301

l-ellenbeck opened this issue Jun 18, 2024 · 7 comments

Comments

@l-ellenbeck
Copy link

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.

@pkleef
Copy link
Collaborator

pkleef commented Jun 18, 2024

Development is looking into this issue

@pkleef
Copy link
Collaborator

pkleef commented Jun 18, 2024

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?

@l-ellenbeck
Copy link
Author

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
Copy link
Author

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

@pkleef
Copy link
Collaborator

pkleef commented Jun 18, 2024

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

@l-ellenbeck
Copy link
Author

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

@pkleef
Copy link
Collaborator

pkleef commented Jun 21, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants