On 7/15/15, T?r?k Edwin <edwin+sqlite3 at etorok.net> wrote: > This might be just the test runner and not sqlite itself, I'm not sure: > > Time: capi2.test 25 ms > ================================================================= > ==2330==ERROR: AddressSanitizer: heap-use-after-free on address > 0x6180003b58dc at pc 0x7f5bb4894d49 bp 0x7ffd1e988d20 sp 0x7ffd1e988d18 > READ of size 4 at 0x6180003b58dc thread T0 > #0 0x7f5bb4894d48 in sqlite3SafetyCheckSickOrOk > /home/edwin/skylable/sqlite/sqlite3.c:25082 > #1 0x7f5bb49b1174 in sqlite3Close
I'm not able to reproduce this problem. Under valgrind, there are some tests in capi3c.test that deliberately do use-after-free in order to test some safety mechanisms built into SQLite. All such test cases have "misuse" in their names. The safety mechanisms implemented by sqlite3SafetyCheckSickOrOk() try to validate that an "sqlite3*" pointer passed into various APIs is really a valid "sqlite3*" pointer that has not been closed by looking at the "magic" integer that is part of the sqlite3 object. If the magic number is not correct, an error is raised. The magic number is cleared whenever a database connection is closed. The tests in this case close a database connection, which causes the sqlite3 object to be deallocated. Then they pass a pointer to that now-deallocated object into some other API and verify that the error is immediately detected and that the API returns SQLITE_MISUSE. Obviously, such things should never occur in a debugged applications. No application should ever do anything that returns SQLITE_MISUSE. The SQLITE_MISUSE return code is purely to alert programmers to coding errors during development. And, also obviously, since this mechanism violates memory safety rules (by reading the "magic" field in a block of memory that has been freed), it will raise alarms with memory debuggers. The test/releasetest.tcl script runs many test cases, including some that make use of -fsanitize on clang and that use valgrind. Whenever the test/releasetest.tcl script uses memory debuggers, it is always careful to omit "misuse" tests. -- D. Richard Hipp drh at sqlite.org
