> 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
Sure thing, it will be the same because you requested pointer from inside Qt. But it's not a static object which I talked about. > I also thought that sqlite3_initialize shouldn't need to be called and > looking through the Qt code it isn't. It is called automatically from inside some of SQLite functions including sqlite3_open*(), but not from sqlite3_exec(). > 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. That's exactly why problem of several instances of static objects can appear. > So I can't see how I would have two instances. But willing to be corrected! If you can trace with gdb then enter into sqlite3_exec, then enter into sqlite3_mutex_enter and then look on the address of sqlite3GlobalConfig.mutex that is used there (or to the same extent on the address of just sqlite3GlobalConfig). I guess db.exec() will also enter into sqlite3_exec so you'll be able to go the same path and look at the address of sqlite3GlobalConfig.mutex there (if the path is different then just go through all SQLite functions until you see sqlite3GlobalConfig somewhere). I bet you'll discover that addresses of this variable are different inside db.exec() and inside sqlite3_exec(). Pavel On Tue, Apr 6, 2010 at 3:51 PM, Neville Dastur <q...@dastur.me.uk> wrote: > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
