On 11/26/2014 06:47 AM, Ward Willats wrote:
We are compiling the 3.8.7.1 using clang arm64 for iOS. Following set:
#define SQLITE_ENABLE_COLUMN_METADATA 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_USLEEP 1
#define SQLITE_DEBUG 1
#define SQLITE_MEMDEBUG 1
WAL mode.
In MallowRaw(), very rarely, seeing the lookaside buffer pBuf or pBuf->next
getting corrupted with ASCII from our CREATE TABLE statements. ('INTEGER' or part
of one of our field names). Thing is, we are not running the schema create code on
these runs (the DB already exists), so these strings must be coming from
sqlite_master, AFAIKT.
None of the SQLITE_DEBUG or SQLITE_MEMDEBUG asserts fire. When it happens, it
happens early in the application run.
Maybe try with both of those and SQLITE_OMIT_LOOKASIDE as well.
When SQLITE_DEBUG and MEMDEBUG are defined, fenceposts are used to
detect buffer overruns for all regular malloc/free allocations. If
lookaside is omitted these fencepost checks will be done for small
allocations as well, which may reveal the source of the memory corruption.
An assert() will fail if any of the fencepost checks indicate a buffer
overwrite.
Dan.
Hard to set a hardware write breakpoint on such a mutable thing.
I fully believe the problem is of my own creation, but interested in any
thoughts or if anyone has seen anything like this.
Thanks, as always,
-- Ward
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
