/ Check-in [3b8f9dec]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Disable the new malloc-37 test when locking_mode==exclusive. The test basically works, but sometimes reports "database is locked" instead of "out of memory" and that messes up the error reporting. (CVS 6811)
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:3b8f9dec24d06865455a75587bbfc199c19c6215
User & Date: drh 2009-06-24 13:13:45
Context
2009-06-24
13:16
Remove an ALWAYS() macro from vdbe.c that sometimes fails on thread tests. (CVS 6812) check-in: 52eac078 user: drh tags: trunk
13:13
Disable the new malloc-37 test when locking_mode==exclusive. The test basically works, but sometimes reports "database is locked" instead of "out of memory" and that messes up the error reporting. (CVS 6811) check-in: 3b8f9dec user: drh tags: trunk
11:08
Remove a declaration of the sqlite3Assert() function that was deleted by the previous check-in. (CVS 6810) check-in: ee20b6a2 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to test/malloc.test.

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
...
839
840
841
842
843
844
845
846

847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865

866
867
868
869
870
871
872
873
874
# This file attempts to check the behavior of the SQLite library in 
# an out-of-memory situation. When compiled with -DSQLITE_DEBUG=1, 
# the SQLite library accepts a special command (sqlite3_memdebug_fail N C)
# which causes the N-th malloc to fail.  This special feature is used
# to see what happens in the library if a malloc were to really fail
# due to an out-of-memory situation.
#
# $Id: malloc.test,v 1.80 2009/06/22 05:43:24 danielk1977 Exp $

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


# Only run these tests if memory debugging is turned on.
#
................................................................................
  INSERT INTO t1 VALUES(3, 4);
} -sqlbody {
  SELECT test_agg_errmsg16(), group_concat(a) FROM t1
}

# At one point, if an OOM occured immediately after obtaining a shared lock
# on the database file, the file remained locked. This test case ensures
# that bug has been fixed.

do_malloc_test 36 -tclprep {
  sqlite3 db2 test.db
  execsql {
    CREATE TABLE t1(a, b);
    INSERT INTO t1 VALUES(1, 2);
  } db2
} -sqlbody {
  SELECT * FROM t1;
} -cleanup {
  # Try to write to the database using connection [db2]. If connection [db]
  # has correctly released the shared lock, this write attempt should 
  # succeed. If [db] has not released the lock, this should hit an 
  # SQLITE_BUSY error.
  do_test malloc-36.$zRepeat.${::n}.unlocked {
    execsql {INSERT INTO t1 VALUES(3, 4)} db2
  } {}
  db2 close
}
catch { db2 close }


# Ensure that no file descriptors were leaked.
do_test malloc-99.X {
  catch {db close}
  set sqlite_open_file_count
} {0}

puts open-file-count=$sqlite_open_file_count
finish_test







|







 







|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>









12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
...
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
# This file attempts to check the behavior of the SQLite library in 
# an out-of-memory situation. When compiled with -DSQLITE_DEBUG=1, 
# the SQLite library accepts a special command (sqlite3_memdebug_fail N C)
# which causes the N-th malloc to fail.  This special feature is used
# to see what happens in the library if a malloc were to really fail
# due to an out-of-memory situation.
#
# $Id: malloc.test,v 1.81 2009/06/24 13:13:45 drh Exp $

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


# Only run these tests if memory debugging is turned on.
#
................................................................................
  INSERT INTO t1 VALUES(3, 4);
} -sqlbody {
  SELECT test_agg_errmsg16(), group_concat(a) FROM t1
}

# At one point, if an OOM occured immediately after obtaining a shared lock
# on the database file, the file remained locked. This test case ensures
# that bug has been fixed.i
if {[db eval {PRAGMA locking_mode}]!="exclusive"} {
  do_malloc_test 37 -tclprep {
    sqlite3 db2 test.db
    execsql {
      CREATE TABLE t1(a, b);
      INSERT INTO t1 VALUES(1, 2);
    } db2
  } -sqlbody {
    SELECT * FROM t1;
  } -cleanup {
    # Try to write to the database using connection [db2]. If connection [db]
    # has correctly released the shared lock, this write attempt should 
    # succeed. If [db] has not released the lock, this should hit an 
    # SQLITE_BUSY error.
    do_test malloc-36.$zRepeat.${::n}.unlocked {
      execsql {INSERT INTO t1 VALUES(3, 4)} db2
    } {}
    db2 close
  }
  catch { db2 close }
}

# Ensure that no file descriptors were leaked.
do_test malloc-99.X {
  catch {db close}
  set sqlite_open_file_count
} {0}

puts open-file-count=$sqlite_open_file_count
finish_test