SQLite Toolkit crashing on Mac

[jsiegel]

If I execute a Select statement (using Execute SQL (Single Integer).vi) inside a parallel For loop, LabVIEW crashes, presumably when two instances of the VI actually run simultaneously. LabVIEW just disappears and the MacOS immediately shows a recovery dialog saying LabVIEW quit unexpectedly.

This is on a Mac Studio with M3 Ultra CPU, running Sequoia 15.7, LabVIEW 2023 Q3 (64-bit) 23.3.7f7, SQLite Toolkit v1.16.0.115 (latest version). I also see the crash on LabVIEW 2025 Community Edition and with all previous versions of the toolkit dating back to 2017.

The crash did not occur on an (older) Mac running LabVIEW 2017 with whatever version of the SQLite Library that was available in 2017.

This crash has never occured on Windows 10/11 machines on various versions of LabVIEW from 2017.

Is it okay to be performing multiple queries in parallel? I would assume all the tookit VIs to be thread-safe. Since the problem started after 2017 only on a Mac, my first inclination is to say that a change in the way MacOS or the hardware handles shared libraries is somehow to blame. But that goes way beyond my knowledge of Macs.

Any insight on what might be the problem, or what I am doing wrong?

[drjdpowell]

Goes beyond my knowledge of Macs as well, I'm afraid.  I've only ever tested on old Intel-CPU Macs.  SQLite should be entirely threadsafe though. 

Are you supplying the SQLite directly or letting the toolkit find the SQLite dll that comes with OSX?  Whichever you are doing, try the opposite.  You can download precompiled dll from https://sqlite.org/download.html

[jsiegel]

I am not supplying anything (explicitly) to the toolkit. I didn't even know that the Mac OS came with an SQLite dll or that the toolkit didn't provide its own. I'll try to supply the library directly and see what happens.

I should point out that CPU on the Mac I am using now is Apple silcon whereas the previous machine had an Intel CPU. That seems more likely the cause of the problem than a change in the MacOS.

[jsiegel]

I think I figured out the problem.

According to https://www.sqlite.org/threadsafe.html, SQLite has three threading modes: Single-thread, Multi-thread, and Serialized.

• For Multi-thread mode, SQLite can be safely used by multiple threads provided that no single database connection nor any object derived from database connection, such as a prepared statement, is used in two or more threads at the same time.
• For Serialized mode, API calls to affect or use any SQLite database connection or any object derived from such a database connection can be made safely from multiple threads. The effect on an individual object is the same as if the API calls had all been made in the same order from a single thread.

In my case, Serialized mode is necessary to avoid a crash. Serialized mode is the default mode for SQLite, but the SQLite library provided on the Mac (not included as part of the SQLite Toolkit) is compiled in Multi-thread mode. The library for a PC (included with the toolkit) seems to be compiled with the default mode of Serialized.

You can explicitly set the Serialized threading mode when opening a connection to a database by specifying the flag 0x10000 (SQLITE_OPEN_FULLMUTEX) as an input to the sqlite3_open_v2() function that is called in the toolkit VI Connection.lvclass:Open (DD).vi. Providing that flag prevents the crash that I mentioned. Unfortunately, that VI does not provide an input to specify the flag, so it requires modifying (or duplicating) the library VI and hierarch. It would be nice if that VI had the option to set the threading mode (or perhaps just hard-coded the option for Serialized threading to ensure consistent SQLite default behavior across platforms).

This solution doesn't explain the fact that I didn't see a crash on an older Mac from 2017. The best I can tell, the SQLite library on Mac has had the comple-time value of Multi-thread since the 2000s.