SQLite

View Ticket
Login
Ticket Hash: 9d708e474201c00146e410637b391b227a4f781d
Title: Debug assertion sqlite3VdbeExec: Assertion `flags3==pIn3->flags' failed (2)
Status: Fixed Type: Code_Defect
Severity: Minor Priority: Immediate
Subsystem: Unknown Resolution: Fixed
Last Modified: 2019-12-23 02:50:50
Version Found In: 3.30.0
User Comments:
mrigger added on 2019-12-23 00:08:41:

Consider the following test case:

CREATE TABLE t0(c0 INT, CHECK(CASE c0 WHEN c0 THEN 0 END));
INSERT INTO t0 VALUES('0'); -- sqlite3.c:86300: sqlite3VdbeExec: Assertion `flags3==pIn3->flags' failed.

When compiling with -DSQLITE_DEBUG, the INSERT triggers an assertion error. This bug seems to be a variant of [1b06916e01].


drh added on 2019-12-23 02:50:50:

We keep ping-ponging between two bits of code:

  1. assert( flags3==pIn3->flags );
  2. testcase( flags3!=pIn3->flags );

The first line says that the conditional is always true. The second line says that the conditional is usually true but that we have a test case for which it is sometimes false.

The test-coverage design rules for SQLite are such that if we do not have a test case for a conditional, it needs to be inside of an assert() (or a NEVER() or ALWAYS() depending on circumstances). On the other hand, if we believe that a conditional can be either true or false, but no branch operations depend on that conditional, we need to have a testcase() macro to prove that we have test cases for both conditions.

When the fuzzer finds new test cases we have to change from (1) to (2). Then as we modify the code generator to deal more gracefully with the strange corner-cases that the fuzzer finds, we have to change from (2) back to (1). And back and forth we go.