fix/duckdb/floating-point-exception
DuckDB error

Floating point exception

Updated Aug 27, 20264-min read
TL;DR

In almost every case, the literal message "Floating point exception (core dumped)" is not DuckDB text. It is the Linux shell reporting that the DuckDB process was killed by a SIGFPE signal, usually from a divide-by-zero instruction inside DuckDB itself or an extension. If your DuckDB process crashed, the cause is a bug in the version you are running.

  • ·You are on an older DuckDB release with a known crash in the query path you hit
  • ·A community or locally-built extension (azure, spatial, h3) triggered the crash
  • ·The query has a specific shape that crashes only in some versions (MAP literals with subqueries, empty-table aggregations, etc.)
  • ·You are running under UBSan or another sanitizer that turns latent integer divides into fatal errors
  • ·You are conflating the friendly SQL behavior of 1/0 (which returns NULL or inf) with an actual crash
CHECK FIRSTCheck the DuckDB version with SELECT version(). If it is older than the current stable, upgrade before doing anything else. Most "floating point exception" reports were already fixed upstream.

What you're seeing

The DuckDB process dies mid-query and the shell prints a one-line SIGFPE notice. This is not a SQL error message with a stack trace, it is the operating system reporting that the process was killed by signal 8.

text
Floating point exception (core dumped)

# In dmesg / kernel log the same crash shows up as:
trap divide error ip:7f... sp:7f... error:0 in duckdb[...]
trap divide error ip:... in azure.duckdb_extension[...]

# Under an UBSan build, the same class of bug surfaces as:
runtime error: division by zero
    at src/parallel/executor.cpp:596:60
Also seen as: duckdb floating point exception, duckdb core dumped, duckdb sigfpe, duckdb divide by zero crash, duckdb division by zero

What's causing this

Ranked most-likely first.

  1. 1

    You are on a DuckDB version with a known SIGFPE bug

    Several crashes were fixed upstream in the last two years. Notable examples: MAP literals combined with subqueries crashed v0.9.2, aggregations over Overture Parquet with h3/spatial extensions crashed v1.0.0. If your version is behind, the fix is upgrading, not rewriting your query.

  2. 2

    A third-party or locally-built extension is crashing

    The trap divide error line in kernel logs often points at the offending shared object. Locally-built azure, spatial, and h3 extensions have historically raised SIGFPE on inputs the official release handles. If the trap line names an extension, that extension is the culprit.

  3. 3

    The query shape hits an empty-input arithmetic path

    Older executors divided by total_cardinality without guarding against zero. Running an aggregation or DISTINCT over a table that turned out to be empty was enough to trip it. Modern DuckDB guards these paths, but pinned older versions do not.

  4. 4

    You are running a sanitizer build

    UBSan and similar sanitizer builds turn any integer divide-by-zero, even ones the release build tolerates, into a hard runtime error. This is expected on sanitizer builds and means the release binary is fine to use.

  5. 5

    You saw NULL or inf and called it a floating point exception

    SELECT 1/0 does not crash DuckDB. It returns NULL on pre-1.1.0 and inf on 1.1.0 and later (IEEE-754 semantics). No process died, no signal was raised. If you did not see the shell print "Floating point exception," this is not the error you are looking for.

How to fix it

Step 1: check the DuckDB version

The single most common fix is upgrading. Confirm what you are actually running, then compare against the current stable at duckdb.org.

sql
SELECT version();
-- Also useful when reporting the crash upstream:
SELECT * FROM duckdb_extensions() WHERE installed;

Step 2: upgrade DuckDB

Install the current stable release from duckdb.org or your package manager. If the crash goes away, that is the answer.

bash
# Python:
pip install --upgrade duckdb

# Node:
npm install duckdb@latest

# CLI (macOS Homebrew):
brew upgrade duckdb

# CLI (direct download):
curl -L https://install.duckdb.org | sh

Step 3: identify which binary crashed

Look at the kernel log for the trap divide error line. It names the shared object where the crash happened. If it points at an extension (azure.duckdb_extension, spatial.duckdb_extension, etc.), the extension is the crashing code, not DuckDB core.

bash
# Linux:
dmesg | tail -20 | grep -i 'trap divide'

# macOS:
log show --predicate 'eventMessage contains "duckdb"' --last 5m

Step 4: switch a locally-built extension for the official release

Community and locally-built extensions have historically raised SIGFPE where the official released binaries do not. Uninstall the local build and pull the official one.

sql
-- Uninstall then reinstall from the official repository:
FORCE INSTALL azure;
LOAD azure;

-- Same pattern for spatial, h3, etc.:
FORCE INSTALL spatial;
LOAD spatial;

Step 5: narrow down which query triggers the crash

A SIGFPE reproduces deterministically for a given input. Run the pipeline step by step until you find the exact query that dies. That is what you file upstream.

sql
-- Split a big pipeline into isolated steps:
CREATE TABLE staging AS SELECT ... FROM source;    -- runs?
CREATE TABLE joined  AS SELECT ... FROM staging;   -- runs?
SELECT COUNT(*) FROM joined WHERE ...;             -- crashes here

Step 6: if you actually want SQL divide-by-zero to be an error, do it in the query

DuckDB 1.1.0+ returns inf for float divide-by-zero and NULL for integer divide-by-zero. Neither raises an error. If your code depends on getting NULL specifically, or on getting a clear error, do it explicitly with NULLIF.

sql
-- Force NULL on divide-by-zero regardless of DuckDB version:
SELECT numerator / NULLIF(denominator, 0) AS ratio FROM t;

-- Revert to pre-1.1.0 semantics globally (NULL instead of inf/nan):
SET ieee_floating_point_ops = false;

Prevention

Pin DuckDB to a recent stable release in your project, and upgrade on a regular cadence. Most SIGFPE crashes reported by users were fixed in a later version. Staying two or three minor releases behind is the single largest source of preventable crashes.

Prefer official released extensions over locally-built ones for anything on a hot path. FORCE INSTALL from the official repository, and pin the extension version alongside DuckDB itself so the pair stays consistent across environments.

When you file a SIGFPE upstream, include the output of SELECT version(), the list of loaded extensions, the exact query that crashed, and the dmesg trap divide error line if you can capture it. The kernel line names the offending binary and usually gets triaged same-day.

Debug DuckDB faster

1bench is a native GUI for DuckDB. Inspect queries, connections, and settings without leaving the app. See what's happening before you have to Google it.

Open DuckDB in 1bench