On 2/3/16, Fredrik Gustafsson <iveqy at iveqy.com> wrote: > Hi, > I've a reproduceable error in my code, running a simple SQL question > gives me a segment fault. Running the program i gdb and doing backtrace > gives me this: > > (gdb) backtrace > #0 malloc_consolidate (av=av at entry=0x7ffff76be620 <main_arena>) at > malloc.c:4149 > #1 0x00007ffff7394ee8 in _int_malloc (av=0x7ffff76be620 <main_arena>, > bytes=3224) at malloc.c:3423 > #2 0x00007ffff7397070 in __GI___libc_malloc (bytes=3224) at malloc.c:2891 ... > #8 0x00007ffff7b87a66 in sqlite3_prepare_v2 () from > /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 > > Despite any errors in my code (which I'm sure there's), why does > sqlite3 crash this way? >
Heap corruption. Something in your application has continued to use (and write on) malloc-ed memory after it was freed, or written past the end of one malloc-ed buffer into an adjacent one, or something else along those lines. SQLite probably had nothing to do with this, other than being the unlucky library that happened to be the first to stumble over the corrupted memory. Running your program using valgrind (http://www.valgrind.org/) will likely find the problem quickly. Valgrind might already be installed on your Linux machine, or if not it is a simple "apt-get" away. -- D. Richard Hipp drh at sqlite.org
