Forum > Database
Strange sqlite sigsev
Чебурашка:
I have a software with two threads doing operations on sqlite databases.
The strange fact is that the two threads do not operate on the same sqlite database, but on different databases. And the connection objects used are local to each thread (actually created and destroyed on the stack of the running method, not even global to the thread), so non sharing nor concurrent access is occurring.
Nevertheless I get random SIGSEV when doing conn.Connected := True;
--- Code: Bash [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---[Current thread is 1 (Thread 0xec2ffb40 (LWP 13364))](gdb) where#0 0x00000000 in ?? ()#1 0xeb5324de in ?? () from /usr/bin/mep/libsqlite3.so#2 0xed0b5cae in SQLITE3CONN$_$TSQLITE3CONNECTION_$__$$_DOINTERNALCONNECT () from /usr/bin/mep/libMEPPanelDataExporter-i386-linux.so#3 0xed0607a1 in DB$_$TDATABASE_$__$$_DOCONNECT () from /usr/bin/mep/libMEPPanelDataExporter-i386-linux.so#4 0xecfbf151 in SQLDB$_$TSQLCONNECTION_$__$$_DOCONNECT () from /usr/bin/mep/libMEPPanelDataExporter-i386-linux.so#5 0xed061c86 in DB$_$TCUSTOMCONNECTION_$__$$_SETCONNECTED$BOOLEAN () from /usr/bin/mep/libMEPPanelDataExporter-i386-linux.so Line "#6 0xed0abef4" was doing conn: TSQLConnection;conn.Connected := True; #6 0xed0abef4 in TDBIOCONNECTION__CONNECTIONOPEN (this=0xeca035e0) at /home/mep/dev/src/fp/MEP-poleis/components/db/Poleis.Components.DB.Toolkit.pas:1459#7 0xed0a77f3 in TDBIOKIT__CONNECTIONOPEN (this=0xec489080) at /home/mep/dev/src/fp/MEP-poleis/components/db/Poleis.Components.DB.Toolkit.pas:564#8 0xed0a7ae4 in TDBIOKIT__CONNECTANDSTARTTRANSACTION_SQLITE (SQLITEDATABASEFILENAME=0xed73238c "/mnt/mep/libMEPPanelDataExporter-tmpfs/transmission_register_db", this=0xec489080) at /home/mep/dev/src/fp/MEP-poleis/components/db/Poleis.Components.DB.Toolkit.pas:627#9 0xed11600f in LOCALRUNCYCLE_DOCYCLE (SQLITEDB=0xed73238c "/mnt/mep/libMEPPanelDataExporter-tmpfs/transmission_register_db", HADERROR=false, LASTATTEMPTEDNO=0, LASTSUCCESSFULNO=0, parentfp=0xec2ff078) at /home/mep/dev/src/fp/MEP-poleis/processing/Poleis.Processing.HandleRemoteForwarding.pas:545#10 0xed115bc1 in LOCALRUNCYCLE_MAKENORMAL (parentfp=0xec2ff078) at /home/mep/dev/src/fp/MEP-poleis/processing/Poleis.Processing.HandleRemoteForwarding.pas:691#11 0xed1159ef in TREMOTESENDINGTHREAD__LOCALRUNCYCLE (this=0xeca8a080) at /home/mep/dev/src/fp/MEP-poleis/processing/Poleis.Processing.HandleRemoteForwarding.pas:757#12 0xed10d163 in MEPTHREADIOEXECUTE_TRYEXECHOOK (LOGGER=..., HOOK=0xed1159c0 <TREMOTESENDINGTHREAD__LOCALRUNCYCLE>, HOOKNAME=0xed272b0c "OnRunCycle", THREADNAME=0xed2738a0 "TRemoteSendingThread", RESULT=true, MESSAGE=0x0) at /home/mep/dev/src/fp/MEP-poleis/components/threads/Poleis.Components.Threads.ThreadIO.pas:195#13 0xed10d833 in MEPTHREADIOEXECUTE_EXECHOOK (LOGGER=..., HOOK=0xed1159c0 <TREMOTESENDINGTHREAD__LOCALRUNCYCLE>, HOOKNAME=0xed272b0c "OnRunCycle", THREADNAME=0xed2738a0 "TRemoteSendingThread") at /home/mep/dev/src/fp/MEP-poleis/components/threads/Poleis.Components.Threads.ThreadIO.pas:264#14 0xed10e990 in MEPTHREADIOEXECUTE_LOOP (PARAM=0xeca8a080, LOOPMODE=MFREE, MAXLOOPCYCLES=0, MAXPROCESSEDMESSAGES=0, EXITASRESTARTED=false, EXITASTERMINATED=false) at /home/mep/dev/src/fp/MEP-poleis/components/threads/Poleis.Components.Threads.ThreadIO.pas:630#15 0xed10ebdc in MEPTHREADIOEXECUTE (PARAM=0xeca8a080) at /home/mep/dev/src/fp/MEP-poleis/components/threads/Poleis.Components.Threads.ThreadIO.pas:859#16 0xecf5140e in CTHREADS_$$_THREADMAIN$POINTER$$POINTER () from /usr/bin/mep/libMEPPanelDataExporter-i386-linux.so#17 0xef44b27a in start_thread () from /lib/i386-linux-gnu/libpthread.so.0#18 0xef370366 in clone () from /lib/i386-linux-gnu/libc.so.6
Is it possible that the sqlite.so does not like at all thread concurrence? Any other clue?
Thaddy:
Not any other, but the single clue: You must run Sqlite inside the threads, so two instances.
Note you can avoid that if you are able to compile SQLite yourself from source. On the SQLite.org website are instructions to compile it thread safe. At the cost of considerable speed loss.
Чебурашка:
--- Quote from: Thaddy on February 23, 2024, 09:54:16 pm ---Not any other, but the single clue: You must run Sqlite inside the threads, so two instances.
--- End quote ---
As I said, it is what I currently do.
I open conn inside a thread (local stack variable), I work on conn, then I close it. No globals, also each conn points to a different sqlite db file.
BTW, what do you intend to say when you say 2 instances? I geuss you refer to the instances of the connection object, isn't it?
Чебурашка:
I also modified code so that, after conn creation, it sets the OpenFlags to FULL_MUTEX.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- Result := TSQLite3Connection.Create(nil); TSQLite3Connection(Result).OpenFlags := TSQLite3Connection(Result).OpenFlags + [sofFullMutex];
But I get same error.
Zvoni:
First check, how your Lib is compiled
https://www.sqlite.org/threadsafe.html
That said: If each thread has its own connection, transaction and TSQLQuery, then you're accessing SQLite actually in Single-Thread mode.
sofFullMutex is only needed if you have concurrent access via a single Connection
Navigation
[0] Message Index
[#] Next page