GOT IT. Well, I found my mistake that lead to all this. I'm sorry to have wasted your time. Here's what happened for those who struggle with similar issues...
I originally opted to make sqlite3_module a member of my C++ "module" class. My C++ constructor was therefore assigning all the xFunctions to that module's members. Later, without realizing the impact, my implementation changed so my class derived sqlite3_module. However, I failed to switch the xFunc assignements to this->xFunc = foo; In the end, it was exactly as if I had never assigned anything to them. Thank you all very much! :) Simon On Fri, Oct 4, 2013 at 3:14 PM, Simon <turne...@gmail.com> wrote: > The option was already on for my own stuff but not sqlite. However, I > just had to recompile libSqlite3 with debug option to get more details and > it's a bit scary... > > SQL query using sqlite3_exec() and stmt: create virtual table foo using > vtable_module1; > -Calling sqlite3_prepare_v2()... > -Calling sqlite3_step()... > staging.bin: sqlite3.c:103774: vtabCallConstructor: Assertion `xConstruct' > failed. > > What's that xConstruct?! I can't even grep that in the sqlite source > files! :( > > After having browsed around, I think it might actually be a macro > (somehow) which aliases either xCreate or xConnect depending on the > situation, but this is just a guess... and still, it doesn't really help. > I reviewed my xCreate and xConnect and they look fine at first glance... > > Thanks, > Simon > > > On Fri, Oct 4, 2013 at 2:26 PM, Richard Hipp <d...@sqlite.org> wrote: > >> >> >> >> On Fri, Oct 4, 2013 at 2:22 PM, Simon <turne...@gmail.com> wrote: >> >>> Hi Richard, >>> >>> That helped a lot and got me passed that point. However, I didn't go >>> very far from where I were... >>> >>> It now compiles fine, however the program segfaults within the >>> sqlite3_step() of the "create virtual table foo using vtable_module1;" >>> statement. >>> >>> Using valgrind, I get this interesting message: >>> >>> ==31748== Jump to the invalid address stated on the next line >>> ==31748== at 0x0: ??? >>> ==31748== by 0x5A0D119: vtabCallConstructor (in >>> /usr/lib64/libsqlite3.so.0.8.6) >>> ==31748== by 0x5A3D499: sqlite3VdbeExec (in >>> /usr/lib64/libsqlite3.so.0.8.6) >>> ==31748== by 0x5A3E969: sqlite3_step (in /usr/lib64/libsqlite3.so.0.8.6) >>> [...] >>> >>> This looks (to me) like one of the NULL function pointers in struct >>> sqlite3_module is being called. I added a valid xRename() function as I >>> had initially thought it was optionnal, but still not working. I then >>> tried creating a dummy function for every one of these pointers, but I get >>> the same result. I even tried changing the "create virtual..." statement >>> to include module params (which my module ignores) but again it didn't >>> change anything. >>> >>> Where should I look at next? >>> >>> >> Recompile with line-number information (-g is it?) so that you know >> exactly which line of code tried to jump to the NULL pointer. Then you'll >> know exactly which method you need to add. >> >> >> -- >> D. Richard Hipp >> d...@sqlite.org >> > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
