Segfault when attempting to attach sqlite database while ui is running

[jfmontanaro]

Hi, thanks for releasing this extension! DuckDB was already super awesome and now it's even more so.

I'm running into a problem with the sqlite extension: attempting to attach to an sqlite database is triggering a segfault every time.

To reproduce:

sqlite3 test.sqlite 'create table test (a, b)'
duckdb -ui

then from either the web UI or the CLI (it doesn't seem to matter which):

install sqlite;
load sqlite;
attach 'test.sqlite' (type sqlite);

For me, this consistently results in a segfault.

I'm running on Ubuntu 22.04.5, kernel 6.1.0-1026-oem on a Framework 13.

FWIW I do see this message printed when I start up the ui:

Gtk-Message: 10:34:20.601: Not loading module "atk-bridge": The functionality is provided by GTK natively. Please try to not load it.

Unsure if that's related.

[Y--]

Hi @jfmontanaro

Thanks for the report. I will look into the crash shortly.

Regarding the message:
Not loading module "atk-bridge": The functionality is provided by GTK natively. Please try to not load it

You should be able to fix it easily with the unset GTK_MODULES command.
More context here: https://stackoverflow.com/a/76920927/667433

[jfmontanaro]

Just realized I wasn't completely clear above: the crash only occurs when I try to attach to a sqlite database while running the ui. If the ui isn't running then I have no problems.

EDIT: Also crashes when attempting to attach to a sqlite database as read-only (which I think doesn't even use the extension), via ATTACH 'sqlite:test.sqlite'

[artemisart]

I have the same issue, segfault when loading a sqlite database with the UI launched, both with duck -ui then ATTACH and ATTACH then CALL start_ui(). (I don't have any gtk warning).

[Y--]

@artemisart are you also running on Linux? Are you using ARM or Intel/AMD CPU?
@jfmontanaro - same question: which CPU type are you using?

FWIW, I'm unable to reproduce so far on a Mac, I will try on Linux right now.

Edit: still can't reproduce on a Linux (x86) box:

$ uname -a
Linux ip-172-31-1-155.eu-west-3.compute.internal 6.1.127-135.201.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Jan 28 23:19:58 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

[Y--]

I've tried to reproduce in Docker, but still no luck. Could you try this on your end?

Dockerfile:

FROM ubuntu:22.04

# Install DuckDB
RUN apt-get update \
  && apt-get install -y sqlite wget unzip \
  && if [ $(uname -m) = "x86_64" ]; then CPU_TYPE="amd64"; else CPU_TYPE="aarch64"; fi \
  && wget https://github.com/duckdb/duckdb/releases/download/v1.2.1/duckdb_cli-linux-${CPU_TYPE}.zip \
  && unzip duckdb_cli-linux-${CPU_TYPE}.zip \
  && sqlite3 test.sqlite 'create table test (a, b)' \
  && printf "install sqlite;\nload sqlite;\nattach 'test.sqlite' (type sqlite);\nshow databases;\n" > test_duckdb1.sql \
  && printf "show databases;\ninstall sqlite;\nload sqlite;\nattach 'test.sqlite' (type sqlite);\ncall start_ui();\nshow databases;\n" > test_duckdb2.sql

This works as expected when starting the UI first:

$ docker run --rm duckdb_ui_43_test /duckdb -ui -f /test_duckdb1.sql
sh: 1: xdg-open: not found
┌────────────────────────────────────────────┐
│                   result                   │
│                  varchar                   │
├────────────────────────────────────────────┤
│ Navigate browser to http://localhost:4213/ │
└────────────────────────────────────────────┘
┌───────────────┐
│ database_name │
│    varchar    │
├───────────────┤
│ memory        │
│ test          │
└───────────────┘

And when starting after attaching the database:

$ docker run --rm duckdb_ui_43_test /duckdb -f /test_duckdb2.sql
┌───────────────┐
│ database_name │
│    varchar    │
├───────────────┤
│ memory        │
└───────────────┘
sh: 1: xdg-open: not found
┌────────────────────────────────────────────┐
│                   result                   │
│                  varchar                   │
├────────────────────────────────────────────┤
│ Navigate browser to http://localhost:4213/ │
└────────────────────────────────────────────┘
┌───────────────┐
│ database_name │
│    varchar    │
├───────────────┤
│ memory        │
│ test          │
└───────────────┘

[artemisart]

I'm on linux debian 12, Linux common 6.1.0-32-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) x86_64 GNU/Linux

[jfmontanaro]

My CPU is amd64, not arm. Specifically it's an AMD Ryzen 7840U.

The docker setup doesn't error for me either. Interestingly, when I try doing the same thing locally (no Docker), it also works fine until I start trying to inspect the test database via the sidebar. Here's a short video demonstrating:

duckdb_crash_test1.webm

This seems to be a change from when I initially reported the problem, by the way. I'm 99% sure it was just crashing instantly as soon as I attached the database when I was testing. But that could be due to a change in the web frontend: as I understand it that is pulled from a remote URL every time the UI is started, so it could change in between runs.

I also intermittently received a different error when I was trying to recreate this. Unfortunately I haven't nailed down exactly what causes it, but every once in a while when I went to introspect the sqlite database I would see the following error in the console:

Error in watcher: {"exception_type":"FATAL","exception_message":"Failed: database has been invalidated because of a previous fatal error. The database must be restarted prior to being used again.\nOriginal error: \"Information loss on integer cast: value -2286079204729324585 outside of target range [-9223372036854775808, 9223372036854775807]\""}
Will now terminate.

Again, not clear why this happens instead of the segfault sometimes.

I will work on trying to come up with a reproducible Dockerfile, at the moment I'm wondering if one of the queries run during the introspection process is causing the segfault somehow? Seems far-fetched, but stranger things have happened.

[Y--]

Thanks a lot @jfmontanaro, this is very helpful. I'll try to give it a shot ASAP!

[ededovic]

The same issue is observed here: duckdb/ducklake#342
suggest fix by gpt:

The UI does run a fast background poll that “watches for changes to the list of attached databases.” That’s exactly what collides with an in-flight ATTACH … (TYPE SQLITE) or ATTACH 'ducklake:sqlite:…' and has been shown to segfault when done while the UI is live. Pausing/serializing removes the race; catching failures prevents a crash even if something else goes sideways.

// pseudo code 
// Somewhere near server startup
std::atomic<bool> ui_poll_paused{false};

// In poller loop
while (running) {
  if (!ui_poll_paused.load()) {
    run_on_connection_queue([&]{
      try { Query("SELECT * FROM duckdb_databases()"); /* … enumerate … */ }
      catch (...) { /* log + skip this tick */ }
    });
  }
  sleep_for(poll_interval);
}

// Around SQL execution
handle_sql(sql) {
  const bool is_attach = starts_with_ci(sql, "attach") || starts_with_ci(sql, "detach");
  if (is_attach) ui_poll_paused.store(true);
  auto guard = finally([&]{ if (is_attach) ui_poll_paused.store(false); });
  run_on_connection_queue([&]{ Query(sql); });
}