Assertion `0' failed (when --enable-debug) at sqlite3ColumnExpr by geopoly and nature join

(1) By Jingzhou Fu (fuboat) on 2023-12-02 03:18:25 [source]

PoC:

CREATE VIRTUAL TABLE v0 USING geopoly ( v1 DEFAULT ( NULL ) ) ;
SELECT 1 FROM v0 NATURAL JOIN v0;

Output:

sqlite3: sqlite3.c:120863: Expr *sqlite3ColumnExpr(Table *, Column *): Assertion `0' failed.

Compilation Arguments:

CC=clang-12 CXX=clang++-12 /root/sqlite_3.44.2/configure --enable-debug --enable-geopoly

Version: SQLite 3.44.2 2023-11-24 11:41:44 ebead0e7230cd33bcec9f95d2183069565b9e709bf745c9b5db65cc0cbf92c0f

It can also be reproduced on the latest commit: 2023-11-30 20:34:24 883990e7938c1f63906300a6113f0fadce143913b7c384e8aeb5f886f0be7c62

Maybe it is a misusing of geopoly extension. I am not sure about whether it is a bug.

(2) By Richard Hipp (drh) on 2023-12-02 12:25:31 in reply to 1 [link] [source]

The fault is the NEVER() macro here: https://sqlite.org/src/info/189e4517d67?ln=723

NEVER(X) means that the boolean expression X is always false, as far as we know. The developers could not come up with a test case for which X is true, but nor could they come up with a proof that X is always false.

During production builds, NEVER(X) resolves to just X. The NEVER() part is a no-op. But to help us find cases where our reasoning is faulty, during debugging builds (with --enable-debug) NEVER() raises an assertion fault when X is true. In this way, we are more easily able to find test cases for obscure corner cases that we could not discover analytically.

Your fuzzer managed to find a case where X was true. So now the NEVER has been removed and a test case has been added to TH3. Thanks.