Crash on just _some_ client PCs related to sqlite
MortenMacFly opened this issue · 2 comments
(wx)sqlite3 works just fine for me on many PCs! But there are two PCs where I can't figure out whats going on and any application that uses (wx)sqlite3 there crashes when accessing the database. On is a Win10 and the other a Win7 machine. In the crash log I see:
00007FF78FE2EF86 0000000000000028 000001BACA0F5E00 0000000B245FE9F0 Tool.exe!sqlite3_regexp_init
00007FF78FBA4966 00000000000001DF 0000000B245FE760 0000000000000001 Tool.exe!0x7ff7000d4966
00007FF78FB18D53 0000000000000000 0000000F0000029E 0000001B00000000 Tool.exe!0x7ff700048d53
00007FF78FC478D9 0000BC1E88FFAAFC 00007FFAE2369993 0000000000000008 Tool.exe!0x7ff7001778d9
00007FF78FE83B64 000001BAC7E40900 00000000000000A1 0000000002010005 Tool.exe!sqlite3_regexp_init
00007FF78FE83FF7 0000BC1E00000102 0000000000000000 0000000000000048 Tool.exe!sqlite3_regexp_init
00007FF78FE84385 0000000000000001 000001BAC6405940 0000000000000000 Tool.exe!sqlite3_regexp_init
...followed by way more references to sqlite3_regexp_init.
Sometimes it suddenly works if I change the compiler flag (GCC 10.3.0) from "-msse4.2" to "-msse4" but not always. I can't remember such issues on older versions other than sqlite3mc_amalgamation.
Did you experience similar? Do you have any solution?
That's why I added the wish to a "simple version" of (wx)sqlite probably w/o any encryption here:
#72 (comment)
(wx)sqlite3 works just fine for me on many PCs! But there are two PCs where I can't figure out whats going on and any application that uses (wx)sqlite3 there crashes when accessing the database. On is a Win10 and the other a Win7 machine.
Well, there are tons of reasons why an application can fail or crash. You will have to debug your application to find out what is causing the crash.
In the crash log I see:
00007FF78FE2EF86 0000000000000028 000001BACA0F5E00 0000000B245FE9F0 Tool.exe!sqlite3_regexp_init
00007FF78FBA4966 00000000000001DF 0000000B245FE760 0000000000000001 Tool.exe!0x7ff7000d4966
00007FF78FB18D53 0000000000000000 0000000F0000029E 0000001B00000000 Tool.exe!0x7ff700048d53
00007FF78FC478D9 0000BC1E88FFAAFC 00007FFAE2369993 0000000000000008 Tool.exe!0x7ff7001778d9
00007FF78FE83B64 000001BAC7E40900 00000000000000A1 0000000002010005 Tool.exe!sqlite3_regexp_init
00007FF78FE83FF7 0000BC1E00000102 0000000000000000 0000000000000048 Tool.exe!sqlite3_regexp_init
00007FF78FE84385 0000000000000001 000001BAC6405940 0000000000000000 Tool.exe!sqlite3_regexp_init...followed by way more references to sqlite3_regexp_init.
The function sqlite3_regexp_init belongs to the regular expression extension of SQLite. This is an extension that is coming with SQLite - wxSQLite3 resp SQLite3MultipleCiphers use the unmodified code of the extension. The function only registers 2 SQL functions with the database connection. Therefore it is rather unlikely to crash. However, it may be a subsequent fault due to the application overwriting memory that doesn't belong to it.
If you don't need support for the REGEXP operator in SQL, you may undefine the compiler symbol SQLITE_ENABLE_REGEXP to exclude the regular expression extension. However, I doubt that this extension is the causal reason for the crashes you experience.
Sometimes it suddenly works if I change the compiler flag (GCC 10.3.0) from "-msse4.2" to "-msse4" but not always. I can't remember such issues on older versions other than sqlite3mc_amalgamation.
In 2020 I added code for AES hardware support to accelerate the encryption extension, if the hardware supports it. Again, this should not cause any problems, if your database connection doesn't make use of encryption.
GCC needs compiler flags to enable compile time support for the AES hardware instruction set. Which option you need may depend on the CPU you are targetting.
Did you experience similar? Do you have any solution?
No - to both questions. You are the first one, reporting such issues. The first step will be to track down what is actually causing the problem. That can be a hard task, if your application overwrites memory.
That's why I added the wish to a "simple version" of (wx)sqlite probably w/o any encryption here:
#72 (comment)
As I answered already there, it is very unlikely that I will publish a version with encryption support removed. The code related to encryption will get executed only, when the application actually uses encryption. It is extremely unlikely that just the presence of such code causes failures of the application.
Since I can't reproduce the problem and since you didn't provide any further evidence that there is actually a bug in wxSQLite3 or the underlying component SQLite3 Multiple Ciphers, I close this issue.
Please reopen, if you can come up with additional information to reproduce and/or track down the problem you experience.