Linux platform.
A program is always running for two or three days, or a day or two suddenly collapsed, before a discussion but did not find a solution, the use of the database is SQLite
Using the GDB Tracker, the results found a crash where the stack was broken to show the method of the call, and it ran several times. The __MEMMOVE_SSSE3 was positioned inside the libc.
In order to restore the complete stack of information in the foreign Daniel to find two words
(GDB) Set $pc =* (void * *) $ESP (gdb) Set $esp = $esp +4
After execution, you can view the stack (32-bit platform). Note that this cannot be entered into GDB by the core file, it must only be a running program crash to be captured by GDB.
View stack See the wrong place
void Xxx::execsql (QString sql) { qmutexlocker locker (&this->readlock); Qsqlquery query (this->database); Run to crash here if (query.exec (SQL) ) ... ...}
The program is multithreaded to insert data into the database, although I have been very careful to deal with threads, but run to some point in the future will still crash.
Until I waited for another two or three days to test, the test to see the opportunity ah, sometimes it completely normal work ah, sometimes crash. The result is that the method executes very frequently, and only one thread accesses the database at the same time, but this sentence crashes. The reason I have not specifically known, my speculation: because in the stack display qsqlquery in the database resources of the application and release, in the application of resources when the error has been directly collapsed.
Then I promoted the query to a class member, and the code became the next.
void Xxx::execsql (QString sql) { qmutexlocker locker (&this->readlock); if (this->query->exec (SQL)) ... ...}
Run again, OK.
This problem occurs only in multi-threaded (even with a lock) and the operating database is frequent, and in other cases it works well.
Qsqlquery can make your program crash.