On 05/04/2010 22:04, Pavel Ivanov wrote: Thank you for reply. > Looking at this output from gdb: > > >> #0 0x00000000 in ?? () >> #1 0x08058f8e in sqlite3_mutex_enter (p=0x90d98c0) at >> 3rdparty/sqlite3/sqlite3.c:14549 >> > I can say that you don't have any mutex module installed (even a no-op > mutex module). It means that sqlite3_intialize() wasn't called because > mutex system is always initialized in sqlite3_initialize(). But you > work with SQLite via Qt API without problems, i.e. Qt called > sqlite3_initialize() which seems to be contradictory. But > sqlite3_initialize() initializes static structures which means that > SQLite API used inside Qt and SQLite API that you use yourself see the > same static variables as different memory locations. I suspect this > can happen if Qt is some dynamically linked library which has SQLite > library statically linked inside. And you link SQLite statically with > your application, so you've got 2 completely different instances of > SQLite API working with completely different static variables. > I did consider this as the issue. However tracing through with gdb the sqlite3 "handle" (ie sqlite3*) is the same memory location from Qt calls and the returned handle from
sqlite3 *handle = *static_cast<sqlite3 **>(v.data()); I also thought that sqlite3_initialize shouldn't need to be called and looking through the Qt code it isn't. Also just to be clear I open the sqlite3 database with a Qt call. I then use the returned handle to execute sqlite3 functions directly. This is to extend the Qt sqlite3 implementation. So I can't see how I would have two instances. But willing to be corrected! > If everything is indeed how I said then I doubt the code where Qt API > and SQLite API are used interchangeably will work properly. I guess > you can fix your SIGSEGV by calling sqlite3_initialize() somewhere at > the beginning of your application but I think inconsistency in static > variables of SQLite can surface in some other errors along the way. > > > Pavel > > On Sun, Apr 4, 2010 at 4:48 PM, Neville Dastur<q...@dastur.me.uk> wrote: > >> |Hi I am using Qt to connect to a Sqlite3 database (3.6.23-1). Source is >> just included with my app, not a dll / lib. >> System: Mac OSX 10.6 and Ubuntu 9.10 (GCC 4.4) >> The method of getting a sqlite* is described in the Qt docs and I have >> checked the memory addresses in gdb and the returned sqlite3* really is >> valid. sqlite.magic also = OPEN. >> Other ref: >> |http://www.mail-archive.com/sqlite-users@sqlite.org/msg25807.html >> | >> The issues is I get a SIGSEGV on the sqlite_exec call >> >> QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE"); >> db.setDatabaseName("test.db"); >> if ( db.open() ) { >> >> // If uncommented this works fine >> //db.exec("CREATE TABLE normalMethod1 ( id INT(64), value >> CHAR(32) )"); >> >> // This is taken from the Qt Docs >> QVariant v = db.driver()->handle(); >> if (v.isValid()&& qstrcmp(v.typeName(), "sqlite3*")==0) { >> // v.data() returns a pointer to the handle >> sqlite3 *handle = *static_cast<sqlite3 **>(v.data()); >> if (handle != 0) { // check that it is not NULL >> >> qint64 id = sqlite3_last_insert_rowid((sqlite3 >> *)handle); //<-- This works fine >> >> char* localError=0; >> const char* sql = "CREATE TABLE tblOne (id int(32), name >> char(16))"; >> int rc = sqlite3_exec(handle, sql, 0, 0,&localError); >> //<-- This causes SIGSEGV >> if (rc != SQLITE_OK) { >> qFatal("Sqlite3 failed with %i", rc); >> } >> } >> } >> } | >> >> The gdb output and stack backtrace is: >> >> Core was generated by `./pcs_debug'. >> Program terminated with signal 11, Segmentation fault. >> [New process 31016] >> [New process 31017] >> #0 0x00000000 in ?? () >> (gdb) run ./pcs_debug >> Starting program: /...../pcs_debug ./pcs_debug >> [Thread debugging using libthread_db enabled] >> [New Thread 0xb7749970 (LWP 31147)] >> Xlib: extension "RANDR" missing on display ":0.0". >> >> ** (<unknown>:31147): CRITICAL **: atk_object_set_name: assertion `name >> != NULL' failed >> [New Thread 0xb7516b70 (LWP 31152)] >> [Thread 0xb7516b70 (LWP 31152) exited] >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0xb7749970 (LWP 31147)] >> 0x00000000 in ?? () >> (gdb) backtrace >> #0 0x00000000 in ?? () >> #1 0x08058f8e in sqlite3_mutex_enter (p=0x90d98c0) at >> 3rdparty/sqlite3/sqlite3.c:14549 >> #2 0x080bc6d5 in sqlite3_exec (db=0x90d3ab0, zSql=0x80f4f34 "CREATE >> TABLE tblOne (id int(32), name char(16))", xCallback=0, pArg=0x0, >> pzErrMsg=0xbfda0388) at 3rdparty/sqlite3/sqlite3.c:76821 >> #3 0x0804f732 in main (argc=2, argv=0xbfda04b4) at src/main.cpp:58 >> >> I have to say that I'm stuck and think this is an issue with threading >> in sqlite3. >> >> Thanks >> >> Neville >> >> _______________________________________________ >> 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 > -- Surgeons Net Education w: http://www.surgeons.org.uk e: i...@surgeons.org.uk _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
