mirrors/sqlite
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix a vdbe stack leak that could occur where one side of a WHERE clause inequality evaluated to SQL null. (CVS 4045)

Browse Source 
FossilOrigin-Name: 17152bf1a268e130f0c43046bb438b617a747ff5
This commit is contained in:
danielk1977 2007-06-02 07:54:37 +00:00
parent 9afe689ea4
commit 39984cdc8b
4 changed files with 43 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
manifest
View File

@ -1,5 +1,5 @@
C Extend\sout-of-memory\stesting\swith\sfuzzily\sgenerated\ssql\ssome.\sOne\sfix\sfor\sa\sproblem\sfound\sby\sthe\ssame.\s(CVS\s4044)
D 2007-05-31T08:20:44
C Fix\sa\svdbe\sstack\sleak\sthat\scould\soccur\swhere\sone\sside\sof\sa\sWHERE\sclause\sinequality\sevaluated\sto\sSQL\snull.\s(CVS\s4045)
D 2007-06-02T07:54:38
F Makefile.in a42354804b50c2708ce72cf79e4daa30f50191b5
F Makefile.linux-gcc 2d8574d1ba75f129aba2019f0b959db380a90935
F README 9c4e2d6706bdcc3efdd773ce752a8cdab4f90028
@ -142,7 +142,7 @@ F src/vdbeblob.c 96f3572fdc45eda5be06e6372b612bc30742d9f0
F src/vdbefifo.c 3ca8049c561d5d67cbcb94dc909ae9bb68c0bf8f
F src/vdbemem.c 328e4897431a277e8670159a4ecc82754f5d9d75
F src/vtab.c c5ebebf615b2f29499fbe97a584c4bb342632aa0
F src/where.c 1c27ddb2f19976175fecdcf8f5a0ca23596917fb
F src/where.c 0662fcd87987a8e131dcf8963e4a3ad696c085f3
F tclinstaller.tcl 4356d9d94d2b5ed5e68f9f0c80c4df3048dd7617
F test/aggerror.test a867e273ef9e3d7919f03ef4f0e8c0d2767944f2
F test/all.test f0ea4b968d5fe05d85e9cab6fa491ec7e3b9fcc4
@ -423,7 +423,7 @@ F test/vtab_shared.test d631d1f820c38c18939d53aab1fc35db5f0a8094
F test/where.test 5c342d6ad0d777275d4740ea5cbeaf5173b6eda4
F test/where2.test 3249d426b3fc7a106713d784e1628307fc308d2e
F test/where3.test 0a30fe9808b0fa01c46d0fcf4fac0bf6cf75bb30
F test/where4.test b68496500bff496e83e76ae4ffb493b99064eac6
F test/where4.test f80207a4ea6504f3d0962f3ecebc7db274ea50c0
F test/zeroblob.test 0e0250c8853f78e22dd0c07eccb36126d8be7aa6
F tool/diffdb.c 7524b1b5df217c20cd0431f6789851a4e0cb191b
F tool/fragck.tcl 5265a95126abcf6ab357f7efa544787e5963f439
@ -500,7 +500,7 @@ F www/tclsqlite.tcl bb0d1357328a42b1993d78573e587c6dcbc964b9
F www/vdbe.tcl 87a31ace769f20d3627a64fa1fade7fed47b90d0
F www/version3.tcl 890248cf7b70e60c383b0e84d77d5132b3ead42b
F www/whentouse.tcl fc46eae081251c3c181bd79c5faef8195d7991a5
P 7522d2fb3204d107b8b4816d7f39c88741f20230
R 6c217896681fcecc432bcce6bb26f9b0
P d2282e64f1320913797dfb4dae4db0428a15a200
R 43a9ecfcf971f988d08ee13d7bafdc9f
U danielk1977
Z 71f138b002ad8359e64307b90b5d152a
Z fcc583b54267b5d032e0ac8a8835f355

2
manifest.uuid
View File

@ -1 +1 @@
d2282e64f1320913797dfb4dae4db0428a15a200
17152bf1a268e130f0c43046bb438b617a747ff5

4
src/where.c
View File

@ -16,7 +16,7 @@
** so is applicable. Because this module is responsible for selecting
** indices, you might also think of this module as the "query optimizer".
**
** $Id: where.c,v 1.249 2007/05/29 12:11:30 danielk1977 Exp $
** $Id: where.c,v 1.250 2007/06/02 07:54:38 danielk1977 Exp $
*/
#include "sqliteInt.h"
@ -2414,7 +2414,7 @@ WhereInfo *sqlite3WhereBegin(
pX = pTerm->pExpr;
assert( (pTerm->flags & TERM_CODED)==0 );
sqlite3ExprCode(pParse, pX->pRight);
sqlite3VdbeAddOp(v, OP_IsNull, -(nEq+1), nxt);
sqlite3VdbeAddOp(v, OP_IsNull, -(nEq*2+1), nxt);
topEq = pTerm->eOperator & (WO_LE|WO_GE);
disableTerm(pLevel, pTerm);
testOp = OP_IdxGE;

34
test/where4.test
View File

@ -15,7 +15,7 @@
# that IS NULL phrases are correctly optimized. But you can never
# have too many tests, so some other tests are thrown in as well.
#
# $Id: where4.test,v 1.3 2007/03/28 14:30:09 drh Exp $
# $Id: where4.test,v 1.4 2007/06/02 07:54:38 danielk1977 Exp $
set testdir [file dirname $argv0]
source $testdir/tester.tcl
@ -230,4 +230,36 @@ do_test where4-7.1 {
integrity_check {where4-99.0}
do_test where4-7.1 {
execsql {
BEGIN;
CREATE TABLE t8(a, b, c, d);
CREATE INDEX t8_i ON t8(a, b, c);
CREATE TABLE t7(i);
INSERT INTO t7 VALUES(1);
INSERT INTO t7 SELECT i*2 FROM t7;
INSERT INTO t7 SELECT i*2 FROM t7;
INSERT INTO t7 SELECT i*2 FROM t7;
INSERT INTO t7 SELECT i*2 FROM t7;
INSERT INTO t7 SELECT i*2 FROM t7;
INSERT INTO t7 SELECT i*2 FROM t7;
COMMIT;
}
} {}
# At one point the sub-select inside the aggregate sum() function in the
# following query was leaking a couple of stack entries. This query
# runs the SELECT in a loop enough times that an assert() fails. Or rather,
# did fail before the bug was fixed.
#
do_test where4-7.2 {
execsql {
SELECT sum((
SELECT d FROM t8 WHERE a = i AND b = i AND c < NULL
)) FROM t7;
}
} {{}}
finish_test