SQLite User Forum

Assertion `pCur->eCurType==CURTYPE_VTAB' failed
Login

Assertion `pCur->eCurType==CURTYPE_VTAB' failed

(1.1) By Jinsheng Ba (bajinsheng) on 2022-06-10 08:32:24 edited from 1.0 [link] [source]

There is another assertion error happens:

sqlite3.c:96249: int sqlite3VdbeExec(Vdbe *): Assertion `pCur->eCurType==CURTYPE_VTAB' failed.

We found it in JDBC driver, and also can reproduce it at CLI mode:

$ ./sqlite3 < assertion.log 1>/dev/null 2>&1
[1]    191535 abort      ./sqlite3 < assertion.log > /dev/null 2>&1

The input file is attached at: https://drive.google.com/file/d/1fMEZYfaiz7MCrdt2HF9FUhF-iN8ssLCX/view?usp=sharing

Environment:

Version: 3.39.0

Commit ID: bbaf1f2e

OS: Ubuntu 20.04

Configuration Options: ./configure --enable-all --enable-debug

Compiler: gcc-5.5.0

Client: CLI

(2) By Richard Hipp (drh) on 2022-06-10 10:17:02 in reply to 1.1 [source]

The test case on the google drive is 372MB in size. Here is a smaller test case:

CREATE VIRTUAL TABLE rt1 USING rtree(c0, c1, c2);
INSERT INTO rt1 VALUES(0,-830151936.0,0.14679022133350372314);
CREATE VIRTUAL TABLE vt1 USING fts4(c0 UNINDEXED);
CREATE VIRTUAL TABLE rt2 USING rtree_i32(c0, c1, c2, c3, c4);
CREATE VIRTUAL TABLE rt3 USING rtree(c0, c1, c2);
CREATE VIRTUAL TABLE vt0 USING fts4(c0 UNINDEXED, notindexed=c0, prefix=415);
INSERT INTO vt0 VALUES(-1836248234.0);
INSERT INTO vt0 VALUES(0.44905996941455561533);
CREATE VIRTUAL TABLE rt4 USING rtree(c0, c1, c2, +c3 REAL);
INSERT INTO rt4 VALUES(1,0.0,0.68648260831832885742,NULL);
CREATE TABLE t2(c0 TEXT);
CREATE TABLE t1(c0 INTEGER PRIMARY KEY AUTOINCREMENT, c1 INT, c2 INTEGER, c48 TEXT);
CREATE TABLE t3(c0 REAL);
CREATE TABLE t4(c0 TEXT);
SELECT SUM(count) FROM (SELECT (((NOT (json_object(rt1.c0, vt0.c0)))) IS TRUE)  as count FROM t2, rt2, rt4, vt1, t3, t4, rt1 INNER JOIN rt3 ON (((((((rt3.c2)) BETWEEN ((rt4.c1)) AND ((rt1.c1))))AND((rt2.c0 IN (t1.c1, rt1.c1)))))OR(((NULL)<=(rt3.c1)))) RIGHT OUTER JOIN vt0 ON ((((-378429629) BETWEEN (rt2.c4) AND (rt2.c1))) NOT NULL) LEFT OUTER JOIN t1 ON (((rt3.c1)) BETWEEN ((CASE t2.c0  WHEN rt2.c4 THEN t4.c0 END)) AND (((((rt2.c1))<((rt2.c4)))))));

Notes:

  • The problem is a faulty assert() statement and has no impact on production builds.
  • The problem is associated with RIGHT JOIN and so has never appeared in any release.
  • The problem is fixed by check-in 1f132bb03a22479c That check-in also adds a test case to prevent a regression.

Thanks for the bug report.

(3) By Jinsheng Ba (bajinsheng) on 2022-06-11 01:06:21 in reply to 2 [link] [source]

Thanks!

Yes, the test case is too large, and I am failed to minimize it...