malloc3.test

sqlite-3.4.1,嵌入式数据库.是一个功能强大的开源数据库,给学习和研发以及小型公司的发展带来了全所未有的好处.

# 2005 November 30
#
# The author disclaims copyright to this source code.  In place of
# a legal notice, here is a blessing:
#
#    May you do good and not evil.
#    May you find forgiveness for yourself and forgive others.
#    May you share freely, never taking more than you give.
#
#***********************************************************************
#
# This file contains tests to ensure that the library handles malloc() failures
# correctly. The emphasis of these tests are the _prepare(), _step() and
# _finalize() calls.
#
# $Id: malloc3.test,v 1.10 2007/03/28 01:59:34 drh Exp $

set testdir [file dirname $argv0]
source $testdir/tester.tcl

# Only run these tests if memory debugging is turned on.
if {[info command sqlite_malloc_stat]==""} {
   puts "Skipping malloc tests: not compiled with -DSQLITE_MEMDEBUG..."
   finish_test
   return
}

#--------------------------------------------------------------------------
# NOTES ON RECOVERING FROM A MALLOC FAILURE
# 
# The tests in this file test the behaviours described in the following
# paragraphs. These tests test the behaviour of the system when malloc() fails
# inside of a call to _prepare(), _step(), _finalize() or _reset(). The
# handling of malloc() failures within ancillary procedures is tested
# elsewhere.
#
# Overview:
#
# Executing a statement is done in three stages (prepare, step and finalize). A
# malloc() failure may occur within any stage. If a memory allocation fails
# during statement preparation, no statement handle is returned. From the users
# point of view the system state is as if _prepare() had never been called.
#
# If the memory allocation fails during the _step() or _finalize() calls, then
# the database may be left in one of two states (after finalize() has been
# called):
#
#     * As if the neither _step() nor _finalize() had ever been called on
#       the statement handle (i.e. any changes made by the statement are
#       rolled back).
#     * The current transaction may be rolled back. In this case a hot-journal
#       may or may not actually be present in the filesystem.
#
# The caller can tell the difference between these two scenarios by invoking
# _get_autocommit().
#
#
# Handling of sqlite3_reset():
#
# If a malloc() fails while executing an sqlite3_reset() call, this is handled
# in the same way as a failure within _finalize(). The statement handle
# is not deleted and must be passed to _finalize() for resource deallocation.
# Attempting to _step() or _reset() the statement after a failed _reset() will
# always return SQLITE_NOMEM.
#
#
# Other active SQL statements:
#
# The effect of a malloc failure on concurrently executing SQL statements,
# particularly when the statement is executing with READ_UNCOMMITTED set and
# the malloc() failure mandates statement rollback only. Currently, if
# transaction rollback is required, all other vdbe's are aborted.
#
#     Non-transient mallocs in btree.c:
#         * The Btree structure itself
#         * Each BtCursor structure
#
#     Mallocs in pager.c:
#         readMasterJournal()  - Space to read the master journal name
#         pager_delmaster()    - Space for the entire master journal file
#
#         sqlite3pager_open()  - The pager structure itself
#         sqlite3_pagerget()   - Space for a new page
#         pager_open_journal() - Pager.aInJournal[] bitmap
#         sqlite3pager_write() - For in-memory databases only: history page and
#                                statement history page.
#         pager_stmt_begin()   - Pager.aInStmt[] bitmap
#
# None of the above are a huge problem. The most troublesome failures are the
# transient malloc() calls in btree.c, which can occur during the tree-balance
# operation. This means the tree being balanced will be internally inconsistent
# after the malloc() fails. To avoid the corrupt tree being read by a
# READ_UNCOMMITTED query, we have to make sure the transaction or statement
# rollback occurs before sqlite3_step() returns, not during a subsequent
# sqlite3_finalize().
#--------------------------------------------------------------------------

#--------------------------------------------------------------------------
# NOTES ON TEST IMPLEMENTATION
#
# The tests in this file are implemented differently from those in other
# files. Instead, tests are specified using three primitives: SQL, PREP and
# TEST. Each primitive has a single argument. Primitives are processed in
# the order they are specified in the file.
#
# A TEST primitive specifies a TCL script as it's argument. When a TEST
# directive is encountered the Tcl script is evaluated. Usually, this Tcl
# script contains one or more calls to [do_test].
#
# A PREP primitive specifies an SQL script as it's argument. When a PREP
# directive is encountered the SQL is evaluated using database connection
# [db].
#
# The SQL primitives are where the action happens. An SQL primitive must
# contain a single, valid SQL statement as it's argument. When an SQL
# primitive is encountered, it is evaluated one or more times to test the
# behaviour of the system when malloc() fails during preparation or
# execution of said statement. The Nth time the statement is executed,
# the Nth malloc is said to fail. The statement is executed until it
# succeeds, i.e. (M+1) times, where M is the number of mallocs() required
# to prepare and execute the statement.
#
# Each time an SQL statement fails, the driver program (see proc [run_test]
# below) figures out if a transaction has been automatically rolled back.
# If not, it executes any TEST block immediately proceeding the SQL
# statement, then reexecutes the SQL statement with the next value of N.
#
# If a transaction has been automatically rolled back, then the driver
# program executes all the SQL specified as part of SQL or PREP primitives
# between the current SQL statement and the most recent "BEGIN". Any 
# TEST block immediately proceeding the SQL statement is evaluated, and
# then the SQL statement reexecuted with the incremented N value.
#
# That make any sense? If not, read the code in [run_test] and it might.
#
# Extra restriction imposed by the implementation:
#
# * If a PREP block starts a transaction, it must finish it.
# * A PREP block may not close a transaction it did not start.
#
#--------------------------------------------------------------------------


# These procs are used to build up a "program" in global variable
# ::run_test_script. At the end of this file, the proc [run_test] is used
# to execute the program (and all test cases contained therein).
#
set ::run_test_script [list]
proc TEST {id t} {lappend ::run_test_script -test [list $id $t]}
proc PREP {p} {lappend ::run_test_script -prep [string trim $p]}

# SQL --
#
#     SQL ?-norollback? <sql-text>
#
# Add an 'SQL' primitive to the program (see notes above). If the -norollback
# switch is present, then the statement is not allowed to automatically roll
# back any active transaction if malloc() fails. It must rollback the statement
# transaction only.
#
proc SQL  {a1 {a2 ""}} {
  # An SQL primitive parameter is a list of two elements, a boolean value
  # indicating if the statement may cause transaction rollback when malloc()
  # fails, and the sql statement itself.
  if {$a2 == ""} {
    lappend ::run_test_script -sql [list true [string trim $a1]]
  } else {
    lappend ::run_test_script -sql [list false [string trim $a2]]
  }
}

# TEST_AUTOCOMMIT --
# 
#     A shorthand test to see if a transaction is active or not. The first
#     argument - $id - is the integer number of the test case. The second
#     argument is either 1 or 0, the expected value of the auto-commit flag.
#
proc TEST_AUTOCOMMIT {id a} {
    TEST $id "do_test \$testid { sqlite3_get_autocommit $::DB } {$a}"
}

#--------------------------------------------------------------------------
# Start of test program declaration
#


# Warm body test. A malloc() fails in the middle of a CREATE TABLE statement
# in a single-statement transaction on an empty database. Not too much can go
# wrong here.
#
TEST 1 {
  do_test $testid {
    execsql {SELECT tbl_name FROM sqlite_master;}
  } {}
}
SQL { 
  CREATE TABLE abc(a, b, c); 
}
TEST 2 {
  do_test $testid.1 {
    execsql {SELECT tbl_name FROM sqlite_master;}
  } {abc}
}

# Insert a couple of rows into the table. each insert is in it's own
# transaction. test that the table is unpopulated before running the inserts
# (and hence after each failure of the first insert), and that it has been
# populated correctly after the final insert succeeds.
#
TEST 3 {
  do_test $testid.2 {
    execsql {SELECT * FROM abc}
  } {}
}
SQL {INSERT INTO abc VALUES(1, 2, 3);}
SQL {INSERT INTO abc VALUES(4, 5, 6);}
SQL {INSERT INTO abc VALUES(7, 8, 9);}
TEST 4 {
  do_test $testid {
    execsql {SELECT * FROM abc}
  } {1 2 3 4 5 6 7 8 9}
}

# Test a CREATE INDEX statement. Because the table 'abc' is so small, the index
# will all fit on a single page, so this doesn't test too much that the CREATE
# TABLE statement didn't test. A few of the transient malloc()s in btree.c
# perhaps.
#
SQL {CREATE INDEX abc_i ON abc(a, b, c);}
TEST 4 {
  do_test $testid {
    execsql {
      SELECT * FROM abc ORDER BY a DESC;
    }
  } {7 8 9 4 5 6 1 2 3}
}

# Test a DELETE statement. Also create a trigger and a view, just to make sure
# these statements don't have any obvious malloc() related bugs in them. Note
# that the test above will be executed each time the DELETE fails, so we're
# also testing rollback of a DELETE from a table with an index on it.
#
SQL {DELETE FROM abc WHERE a > 2;}
SQL {CREATE TRIGGER abc_t AFTER INSERT ON abc BEGIN SELECT 'trigger!'; END;}
SQL {CREATE VIEW abc_v AS SELECT * FROM abc;}
TEST 5 {
  do_test $testid {
    execsql {
      SELECT name, tbl_name FROM sqlite_master ORDER BY name;
      SELECT * FROM abc;
    }
  } {abc abc abc_i abc abc_t abc abc_v abc_v 1 2 3}
}

set sql {
  BEGIN;DELETE FROM abc;
}
for {set i 1} {$i < 100} {incr i} {
  set a $i
  set b "String value $i"
  set c [string repeat X $i]
  append sql "INSERT INTO abc VALUES ($a, '$b', '$c');"
}
append sql {COMMIT;}
PREP $sql

SQL {
  DELETE FROM abc WHERE oid IN (SELECT oid FROM abc ORDER BY random() LIMIT 5);
}
TEST 6 {
  do_test $testid.1 {
    execsql {SELECT count(*) FROM abc}
  } {94}
  do_test $testid.2 {
    execsql {
      SELECT min(
          (oid == a) AND 'String value ' || a == b AND a == length(c) 
      ) FROM abc;
    }
  } {1}
}
SQL {
  DELETE FROM abc WHERE oid IN (SELECT oid FROM abc ORDER BY random() LIMIT 5);
}
TEST 7 {
  do_test $testid {
    execsql {SELECT count(*) FROM abc}
  } {89}
  do_test $testid {
    execsql {
      SELECT min(
          (oid == a) AND 'String value ' || a == b AND a == length(c) 
      ) FROM abc;
    }
  } {1}
}
SQL {
  DELETE FROM abc WHERE oid IN (SELECT oid FROM abc ORDER BY random() LIMIT 5);
}
TEST 9 {
  do_test $testid {
    execsql {SELECT count(*) FROM abc}
  } {84}
  do_test $testid {
    execsql {
      SELECT min(
          (oid == a) AND 'String value ' || a == b AND a == length(c) 
      ) FROM abc;
    }
  } {1}
}

set padding [string repeat X 500]
PREP [subst {
  DROP TABLE abc;
  CREATE TABLE abc(a PRIMARY KEY, padding, b, c);
  INSERT INTO abc VALUES(0, '$padding', 2, 2);
  INSERT INTO abc VALUES(3, '$padding', 5, 5);
  INSERT INTO abc VALUES(6, '$padding', 8, 8);
}]

TEST 10 {
  do_test $testid {
    execsql {SELECT a, b, c FROM abc}