Import SQLite 3.8.7.4.

third_party/sqlite/src/test/crash5.test

 
 # 2007 Aug 13
 #
 # 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.
 #
@@ skipping 16 matching lines @@
 }
 
 db close
 
 for {set ii 0} {$ii < 10} {incr ii} {
   for {set jj 50} {$jj < 100} {incr jj} {
 
     # Set up the database so that it is an auto-vacuum database 
     # containing a single table (root page 3) with a single row. 
     # The row has an overflow page (page 4).
-    file delete -force test.db test.db-journal
+    forcedelete test.db test.db-journal
     sqlite3 db test.db
     set c [string repeat 3 1500]
     db eval {
       pragma auto_vacuum = 1;
       CREATE TABLE t1(a, b, c);
       INSERT INTO t1 VALUES('1111111111', '2222222222', $c);
     }
     db close
 
     do_test crash5-$ii.$jj.1 {
       crashsql -delay 1 -file test.db-journal -seed $ii -tclbody [join [list \
         [list set iFail $jj] {
-        sqlite3_crashparams 0 [file join [pwd] test.db-journal]
+        sqlite3_crashparams 0 [file join [get_pwd] test.db-journal]
       
         # Begin a transaction and evaluate a "CREATE INDEX" statement
         # with the iFail'th malloc() set to fail. This operation will
         # have to move the current contents of page 4 (the overflow
         # page) to make room for the new root page. The bug is that
         # if malloc() fails at a particular point in sqlite3PagerMovepage(),
         # sqlite mistakenly thinks that the page being moved (page 4) has 
         # been safely synced into the journal. If the page is written
         # to later in the transaction, it may be written out to the database
         # before the relevant part of the journal has been synced.
         #
         db eval BEGIN
         sqlite3_memdebug_fail $iFail -repeat 0
         catch {db eval { CREATE UNIQUE INDEX i1 ON t1(a); }} msg
         # puts "$n $msg ac=[sqlite3_get_autocommit db]"
       
         # If the transaction is still active (it may not be if the malloc()
-        # failure occured in the OS layer), write to the database. Make sure
+        # failure occurred in the OS layer), write to the database. Make sure
         # page 4 is among those written.
         #
         if {![sqlite3_get_autocommit db]} {
           db eval {
             DELETE FROM t1;  -- This will put page 4 on the free list.
             INSERT INTO t1 VALUES('111111111', '2222222222', '33333333');
             INSERT INTO t1 SELECT * FROM t1;                     -- 2
             INSERT INTO t1 SELECT * FROM t1;                     -- 4
             INSERT INTO t1 SELECT * FROM t1;                     -- 8
             INSERT INTO t1 SELECT * FROM t1;                     -- 16
             INSERT INTO t1 SELECT * FROM t1;                     -- 32
             INSERT INTO t1 SELECT * FROM t1 WHERE rowid%2;       -- 48
           }
         }
         
         # If the right malloc() failed during the 'CREATE INDEX' above and
         # the transaction was not rolled back, then the sqlite cache now 
         # has a dirty page 4 that it incorrectly believes is already safely
         # in the synced part of the journal file. When 
         # sqlite3_release_memory() is called sqlite tries to free memory
         # by writing page 4 out to the db file. If it crashes later on,
         # before syncing the journal... Corruption!
         #
-        sqlite3_crashparams 1 [file join [pwd] test.db-journal]
+        sqlite3_crashparams 1 [file join [get_pwd] test.db-journal]
         sqlite3_release_memory 8092
       }]] {}
       expr 1
     } {1}
   
     sqlite3 db test.db
     do_test crash5-$ii.$jj.2 {
       db eval {pragma integrity_check}
     } {ok}
     do_test crash5-$ii.$jj.3 {
       db eval {SELECT * FROM t1}
     } [list 1111111111 2222222222 $::c]
     db close
   }
 }
 
 
 finish_test