Ok. My bad for singling out SQLite, I should have rather mentioned that the problem exists with all memory allocation routines (malloc/free or new/delete), at least on windows.
A workaround is to pass around allocator / deallocator function pointers with any data structure which contains pointers which might be free'd or realloc'd in a different module. My assumption was that SQLite does not do this, since being Lite is a main priority and if one is using multiple modules then option to dynamically link to SQLite avoids the problem. My reason for assuming memory corruption (or invalid call to free(...)) was the fact that Brett is encountering an exception rather than an invalid return code. On 8 February 2017 at 14:16, Richard Hipp <d...@sqlite.org> wrote: > On 2/8/17, Barry Smith <smith.bar...@gmail.com> wrote: > > > > I believe SQLite doesn't use the standard memory allocation routines, but > > instead has its own routines. > > SQLite has its on memory allocation routines (if you use the right > compile-time and start-time options) but it uses system > malloc()/realloc()/free() by default. > > There are internal wrappers routines for the memory allocator that > dispatch requests to the appropriate implementation. Again, unless > you take special actions to change it, memory allocation request are > satisfied by malloc(). > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
