Assertion Failure when using RAISE(IGNORE)

(1) By Yu Liang (LY1598773890) on 2023-03-07 22:30:20 [source]

The latest version of SQLite3 (version a0e54fe205, running on arm64 Ubuntu 20.04 LTS) encounters Assertion Failure when executing the following query:

CREATE TABLE v0(c1 INT, c2 AS (RAISE(IGNORE)));
SELECT * FROM v0;

Assertion Failure information:

sqlite3: sqlite3.c:110831: sqlite3ExprCodeTarget: Assertion `pExpr->affExpr==OE_Rollback || pExpr->affExpr==OE_Abort || pExpr->affExpr==OE_Fail || pExpr->affExpr==OE_Ignore' failed.
Aborted (core dumped)

Stack Trace:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000fffff7cedaac in __GI_abort () at abort.c:79
#2  0x0000fffff7cfa490 in __assert_fail_base (fmt=0xfffff7df5738 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    assertion=assertion@entry=0xaaaaaacf1648 "pExpr->affExpr==OE_Rollback || pExpr->affExpr==OE_Abort || pExpr->affExpr==OE_Fail || pExpr->affExpr==OE_Ignore",
    file=file@entry=0xaaaaaacdb3f8 "sqlite3.c", line=line@entry=110831, function=function@entry=0xaaaaaad18fb8 <__PRETTY_FUNCTION__.31952> "sqlite3ExprCodeTarget")
    at assert.c:92
#3  0x0000fffff7cfa4f4 in __GI___assert_fail (
    assertion=0xaaaaaacf1648 "pExpr->affExpr==OE_Rollback || pExpr->affExpr==OE_Abort || pExpr->affExpr==OE_Fail || pExpr->affExpr==OE_Ignore",
    file=0xaaaaaacdb3f8 "sqlite3.c", line=110831, function=0xaaaaaad18fb8 <__PRETTY_FUNCTION__.31952> "sqlite3ExprCodeTarget") at assert.c:101
#4  0x0000aaaaaabab83c in sqlite3ExprCodeTarget (pParse=0xffffffffd0b0, pExpr=0xaaaaaad78400, target=2) at sqlite3.c:110831
#5  0x0000aaaaaababe80 in sqlite3ExprCode (pParse=0xffffffffd0b0, pExpr=0xaaaaaad78400, target=2) at sqlite3.c:110975
#6  0x0000aaaaaababf68 in sqlite3ExprCodeCopy (pParse=0xffffffffd0b0, pExpr=0xaaaaaad78400, target=2) at sqlite3.c:110995
#7  0x0000aaaaaaba7e24 in sqlite3ExprCodeGeneratedColumn (pParse=0xffffffffd0b0, pTab=0xaaaaaad7ddd0, pCol=0xaaaaaad7e4b0, regOut=2) at sqlite3.c:109728
#8  0x0000aaaaaaba802c in sqlite3ExprCodeGetColumnOfTable (v=0xaaaaaad76e20, pTab=0xaaaaaad7ddd0, iTabCur=0, iCol=1, regOut=2) at sqlite3.c:109768
#9  0x0000aaaaaaba81d8 in sqlite3ExprCodeGetColumn (pParse=0xffffffffd0b0, pTab=0xaaaaaad7ddd0, iColumn=1, iTable=0, iReg=2, p5=0 '\000') at sqlite3.c:109804
#10 0x0000aaaaaaba9590 in sqlite3ExprCodeTarget (pParse=0xffffffffd0b0, pExpr=0xaaaaaad78100, target=2) at sqlite3.c:110207
#11 0x0000aaaaaabac1f0 in sqlite3ExprCodeExprList (pParse=0xffffffffd0b0, pList=0xaaaaaad78a80, target=1, srcReg=0, flags=1 '\001') at sqlite3.c:111069
#12 0x0000aaaaaabe9c94 in innerLoopLoadRow (pParse=0xffffffffd0b0, pSelect=0xaaaaaad77e80, pInfo=0xffffffffc168) at sqlite3.c:139093
#13 0x0000aaaaaabeaec4 in selectInnerLoop (pParse=0xffffffffd0b0, p=0xaaaaaad77e80, srcTab=-1, pSort=0x0, pDistinct=0xffffffffc3a0, pDest=0xffffffffc5c0, iContinue=-4,
    iBreak=-2) at sqlite3.c:139685
#14 0x0000aaaaaabfc098 in sqlite3Select (pParse=0xffffffffd0b0, p=0xaaaaaad77e80, pDest=0xffffffffc5c0) at sqlite3.c:146127
#15 0x0000aaaaaac32a38 in yy_reduce (yypParser=0xffffffffc6c0, yyruleno=84, yyLookahead=1, yyLookaheadToken=..., pParse=0xffffffffd0b0) at sqlite3.c:170920
#16 0x0000aaaaaac382b0 in sqlite3Parser (yyp=0xffffffffc6c0, yymajor=1, yyminor=...) at sqlite3.c:172342
#17 0x0000aaaaaac3bd18 in sqlite3RunParser (pParse=0xffffffffd0b0, zSql=0xaaaaaad690f0 ";") at sqlite3.c:173641
#18 0x0000aaaaaabe78d8 in sqlite3Prepare (db=0xaaaaaad69190, zSql=0xaaaaaad690e0 "SELECT * FROM v0;", nBytes=-1, prepFlags=128, pReprepare=0x0, ppStmt=0xffffffffd348,
    pzTail=0xffffffffd350) at sqlite3.c:138144
#19 0x0000aaaaaabe7bac in sqlite3LockAndPrepare (db=0xaaaaaad69190, zSql=0xaaaaaad690e0 "SELECT * FROM v0;", nBytes=-1, prepFlags=128, pOld=0x0, ppStmt=0xffffffffd348,
    pzTail=0xffffffffd350) at sqlite3.c:138219
#20 0x0000aaaaaabe7f9c in sqlite3_prepare_v2 (db=0xaaaaaad69190, zSql=0xaaaaaad690e0 "SELECT * FROM v0;", nBytes=-1, ppStmt=0xffffffffd348, pzTail=0xffffffffd350)
    at sqlite3.c:138305
#21 0x0000aaaaaaae9324 in shell_exec (pArg=0xffffffffdcf8, zSql=0xaaaaaad690e0 "SELECT * FROM v0;", pzErrMsg=0xffffffffd3d0) at shell.c:19235
#22 0x0000aaaaaaafd13c in runOneSqlLine (p=0xffffffffdcf8, zSql=0xaaaaaad690e0 "SELECT * FROM v0;", in=0xfffff7e3b8d0 <_IO_2_1_stdin_>, startline=2) at shell.c:26471
#23 0x0000aaaaaaafd850 in process_input (p=0xffffffffdcf8) at shell.c:26637
#24 0x0000aaaaaaaff898 in main (argc=1, argv=0xfffffffff368) at shell.c:27544

Bisecting:

bisect complete
  1 BAD     2023-03-07 19:23:36 2f712b836a0dafd0
  6 BAD     2023-03-03 19:43:39 2535bc8c256a7642
  8 BAD     2023-03-03 15:12:46 e95439119ac200cb
  9 GOOD    2023-03-03 10:42:23 c4d083a3aeeee693 CURRENT
  7 GOOD    2023-03-02 06:58:55 75fdd5b83b4c527d
  5 GOOD    2023-02-28 20:04:01 a63e4a150b505fc3
  4 GOOD    2023-02-22 20:50:51 65910216393ed287
  3 GOOD    2023-02-05 20:29:10 e6ab96bd0b9efc51
  2 GOOD    2022-12-31 05:26:35 2ffbf0c73c5a0f08

The bug cannot be trigger with Release build (without the assertion). It is possible to be just an incorrect placed Assertion condition.

(2) By Richard Hipp (drh) on 2023-03-07 23:54:21 in reply to 1 [link] [source]

This problem was introduced four days ago and has never appeared in a release. The problem is now fixed on trunk.

The original problem was that the two queries at the end of the following script were getting different answers:

CREATE TABLE t1(
  x,
  a TEXT AS (x) VIRTUAL,
  b BLOB AS (x) VIRTUAL
);
CREATE INDEX x2 ON t1(a);
INSERT INTO t1(x) VALUES(1);
SELECT typeof(b) FROM t1;
SELECT typeof(b) FROM t1 INDEXED BY x2;

The first was returning "integer" and the second was returning "text". Both should be returning "integer". This original problem was introduced by one of the optimizations added in 3.41.0, was detected internally using the dbsqlfuzz fuzzer, and fixed by check-in e95439119ac200cb. But that fix added this new assertion fault issue, which was subsequently fixed by check-in 1096b5a7cc8104db.

(3) By Yu Liang (LY1598773890) on 2023-03-08 03:05:16 in reply to 2 [link] [source]

Thank you Richard for the very quick fix! Appreciate the quick reply.

(4) By Tim Streater (Clothears) on 2023-03-08 08:30:37 in reply to 3 [link] [source]

In future, when you say:

> The latest version of SQLite3 (version a0e54fe205, running on arm64 Ubuntu 20.04 LTS) encounters
> Assertion Failure when executing the following query:

> CREATE TABLE v0(c1 INT, c2 AS (RAISE(IGNORE)));
> SELECT * FROM v0;

or something similar, plase specify whether you are referring to a released version or an unreleased version.