by adding the new OP_ReleaseReg opcode to tell MemAboutToChange() that a
range of registers is no longer needed so that the source register can be
freely changed. This is a change to debugging and test builds only and
does not impact release builds. Fix for ticket
[c62c5e58524b204d] and [5ad2aa6921faa1ee]. The previous fix to ticket
[5ad2aa6921faa1ee] is backed out by this change since this change is a better
fix.
FossilOrigin-Name: 36fdeb4f0a66970a35de688b617f90899c89cfdfab659f864df99aa7ebf854ea
OP_Eq and OP_Ne opcode with the same P1 and P3 arguments. This enables us
to back out check-in [ddb17d92df194337] and also fix ticket [188f912b51cd802].
FossilOrigin-Name: 9ab985a9c8160b905730678f40ed440a246cdec549c798bafefaed5abbc0437f
OP_RealAffinity, to avoid problems with a pointer accounting assert.
This change is not strictly necessary - the correct answer is obtained
without it and no UB occurs - however the pointer accounting asserts are
useful to prevent other problems so it is a simple matter to bring this
piece into compliance. Ticket [5ad2aa6921faa1ee]
FossilOrigin-Name: 89a9dad6330270a4c3b962f86a208088d2ea9883c7d291351a77f058e0ed8b0c
table that is in a LEFT JOIN, be sure to set the correct Expr.iRightJoinTable
value. This value does not appear to ever be used, except inside of a single
assert(). But it is good to set it correctly, nevertheless. This fixes
ticket [7929c1efb2d67e98], which as far as I can tell is completely harmless.
FossilOrigin-Name: ef604882a275d3d5ebd4d5a08e3fe43e148f169b7d5c3a81464fbe7f54f3582a
of expressions used in an index-on-expression directly from the index rather
than recomputing the value. If the expression has a top-level COLLATE or
unlikely() operator, be sure to clear the corresponding flags prior to
converting it into a TK_COLUMN expression. Failure to do this is most likely
harmless in production, but might cause an assertion fault in debugging builds.
Ticket [b0cb8aff561a6dcd]. Test cases in TH3.
FossilOrigin-Name: 56539e1c132632c075efc217ad5951a35e4459605ac128914aec3a7be1e25718
as ticket [1b06916e01c82b66] demonstrates a case that refutes them.
FossilOrigin-Name: ddb17d92df194337a103c561ef46ced00db5e67e4551e82de7cb5ad7f457dd5f
constraints if there are any errors, since there might otherwise be attempts
to use those CHECK constraints if PRAGMA writable_schema=ON is set.
This undoes the fix in check-in [ea721b34477ab8b4] for a more general
solution.
FossilOrigin-Name: a982e6434cd66bfbe94d455f538bcbc4360b91572062d92acae6b77e9560e65d
processes the correct entry in the sqlite_master table even if there is
a second entry with the same name and table values due to database corruption
and the use of writable_schema=ON. Dbsqlfuzz find.
FossilOrigin-Name: 4dbb6e1cb094f3428c74ea8bdd86ab63341fecce978a062968ca01423f382e90
(or other expressions in the table definition) might not be fully resolved.
Ensure that the code generator can deal with this if the table is subsequently
used in a DML statement. dbsqlfuzz find.
FossilOrigin-Name: ea721b34477ab8b49d182352c4bc198245933b850e9b6248b4f97600e80bb44b
sequence for the generated column is non-standard.
Part 2 of ticket [e0a8120553f4b082]
FossilOrigin-Name: 056bb8dcbdc45989c5c6e86d2966200062e3c01c382ec52aae37c828104b4496
account the FILTER clause of aggregate functions. Problem reported by
Manuel Rigger.
FossilOrigin-Name: 3cc2b5709e66ef605c3b85ed13ae6cc9c3090e864ebc18859db36284b8f715b6
is seen in the tree. Report the problem immediately, without continuing.
FossilOrigin-Name: 01ca865f31c0c817ede7f357401ef76cf311ae662397908464f53e1c147f5b6b
in the sqlite3WindowRewrite() routine, make sure that pParse->nErr is set,
and make sure that this shuts down any subsequent code generation that might
depend on the transformations that were implemented. This fixes a problem
discovered by the Yongheng and Rui fuzzer.
FossilOrigin-Name: e2bddcd4c55ba3cbe0130332679ff4b048630d0ced9a8899982edb5a3569ba7f
by disallowing query flattening if the outer query is DISTINCT. Without this fix,
if an index scan is run on the table within the view on the right-hand side of the
LEFT JOIN, stale result registers might be accessed yielding incorrect results,
and/or an OP_IfNullRow opcode might be invoked on the un-opened table, resulting
in a NULL-pointer dereference. This problem was found by the Yongheng and Rui fuzzer.
FossilOrigin-Name: 862974312edf00e9d1068115d1a39b7235b7db68b6d86b81d38a12f025a4748e
INSERT statement. The same assert() appears again in the VDBE and will fire
there if the problem persists in an SQL statement that does not contain
errors. Gramfuzz find.
FossilOrigin-Name: 9bdd57cb9ad8ac1f4a0f1a3942d94ca5193109eeb1975343c4f0c7abf7135946
definitions (see check-in [7e4809eadfe99ebf]) be sure to fully disable
the constant value to avoid an invalid pointer dereference if the expression
is ever duplicated. This fixes a crash report from Yongheng and Rui.
FossilOrigin-Name: 1ca0bd982ab1183bbafce0d260e4dceda5eb766ed2e7793374a88d1ae0bdd2ca
the semantics of a LEFT JOIN, make sure any generated columns on that row
evaluate to NULL. Ticket [3b84b42943644d6f]
FossilOrigin-Name: 0271491438ad2a985aeff355173a8d0f1e5813954c82147bc68cb26cca5804c8
of indexes for a table, even for weird cases where the same UNIQUE constraint
occurs twice with the ON CONFLICT REPLACE clause only on the second one. This
avoids an out-of-order contraint processing problem that can arise due
to the optimization of check-in [469a62ca33081854].
FossilOrigin-Name: 1e3918ca2f2c1cfcfa44249b1d7b847d52cbb8d302a8d4a335c090cfdf22d7a1
convert the expression to a simple NULL. This prevents additional pieces of
the expression tree that are allocated from lookaside from leaking into the
schema, where lookaside allocations are not allowed.
FossilOrigin-Name: a89b38605661e36d192df1d074383b704b34a959fcbc169837c0d4f6848f3208
contains extraneous bits, so change a testcase() into an assert() to show
as much.
FossilOrigin-Name: 5b4a88cd3b3a32b1242e0eb733cc0bc4becb830a887b8e6604a4c7452050e163
sqlite3ExprCodeGetColumn() if the opcode generated is not really an
OP_Column, which might happen if the column is virtual.
Fix for ticket [b439bfcfb7deedc6]
FossilOrigin-Name: 2401e04730a156aa48787b91af4e516406cb7635145e430be62fd16481816237
in the STD-C spec is technically UB. This is to fix a harmless UBSAN
complaint that OSSFuzz is hitting.
FossilOrigin-Name: c29fc21288e37f81a1617c5e2961c575d3bca6a1d1b013b2e0a99774afb1dcdb
This actually works out to 30 big slots and 93 small slots using the
mini-lookaside allocator. We get the same (or better) lookaside coverage
but with 72KB less memory per connection.
FossilOrigin-Name: 47b71a84d1262c4bf6ad4f4a91820fd63593f08ae9efa144199d44972225e073
per entry, from 32-bytes (on a 64-bit machine). This helps the new
mini-lookaside allocator to run better by avoiding excessive reallocs.
The current change mostly works, but still has a few loose ends to tie up.
This check-in is merely a snapshot to save my work.
FossilOrigin-Name: fdda76cfb01bf2b19522ac4558b443634d28a69b0828677c42682b645eae1f3b
