Possible bug: Unable to find an entry point
(1) By anonymous on 2021-11-23 16:45:24 [link] [source]
Hardware: Raspberry Pi 3 B+ OS: Debian Bullseye ARMv8 (64 bit) from the DietPi org libSQLite.Interop.dll compiled on above using sqlite-netFx-full-source-126.96.36.199 When running a .net 6 (core) app using System.Data.SQLite.Core 188.8.131.52 the following error is encountered on start: Unable to find an entry point named 'SIa069da76968b7553' in shared library 'SQLite.Interop.dll' When running the same app but with System.Data.SQLite.Core 1.0.115 (previous version) no error is encountered and the app functions normally. It’s unclear to me if this is a bug in 184.108.40.206 or if I’m doing something incorrect. Just throwing it out there in case it is a bug. Thanks.
(2) By Larry Brasfield (larrybr) on 2021-11-23 21:08:24 in reply to 1 [link] [source]
... the following error is encountered on start: Unable to find an entry point named 'SIa069da76968b7553' in shared library 'SQLite.Interop.dll'
I am highly skeptical that a name like that is supposed to be exported by that DLL. I've seen many name decoration schemes, but never one that appears to encode a 64-bit number with a prefix. And all the names exported by SQLite.Interop.dll for x86 and amd64 platforms are more ordinary, semi-meaningful-to-humans identifiers.
Do you have any reason, beyond this error message, to believe that the System.Data.SQLite.Core library is, in fact, linked (albeit dynamically) to such an entry point?
(4) By anonymous on 2021-11-24 01:35:58 in reply to 2 [link] [source]
I agree, it seemed quite unusual to me too. But that was the message verbatim. I have no other reason nor evidence. And admittedly I am in a litter over my head here. All I know is the same steps taken for two very close versions resulted in one working and one not. The possibility exists that I was just getting lucky with having one working as the following post might suggest. Thanks.
(3) By mistachkin on 2021-11-23 23:09:35 in reply to 1 [source]
The precompiled managed assemblies within the official NuGet packages are only intended to be used with the interop assemblies also from those NuGet packages.
(5) By anonymous on 2021-11-24 01:39:10 in reply to 3 [link] [source]
Ah. That is good to know. Thank you!
(6) By webprofusion on 2021-12-20 03:27:33 in reply to 3 [link] [source]
Further to this I can confirm that when upgrading from System.Data.SQLite.Core 220.127.116.11 to 18.104.22.168 and distributing our application to users that the users are frequently encountering the following error (not universally):
System.EntryPointNotFoundException: Unable to find an entry point named 'SIfcfad09d1b0a60ec' in DLL 'SQLite.Interop.dll'.\r\n at System.Data.SQLite.UnsafeNativeMethods.sqlite3_open_interop(Byte utf8Filename, Byte vfsName, SQLiteOpenFlagsEnum flags, Int32 extFuncs, IntPtr& db)\r\n at System.Data.SQLite.SQLite3.Open(String strFilename, String vfsName, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool)\r\n at System.Data.SQLite.SQLiteConnection.Open()\r\n at System.Data.Common.DbConnection.OpenAsync(CancellationToken cancellationToken)\
We have been distributing this app with SQLite for years, generally following the latest System.Data.SQLite.Core
My (unsubstantiated) theory is there could be a particular brand of Anti-Virus that's somehow interfering with the assembly load, or certain users have older SQLite.Interop.dll installed in the GAC and for some reason it's picking that up.
I can confirm
SIfcfad09d1b0a60ec is the SQLite.Interop.dll export of sqlite3_open_interop in 22.214.171.124
[DllImport("SQLite.Interop.dll", EntryPoint = "SIfcfad09d1b0a60ec")] internal static extern SQLiteErrorCode sqlite3_open_interop( byte utf8Filename, byte vfsName, SQLiteOpenFlagsEnum flags, int extFuncs, ref IntPtr db);
(7) By tsuckow on 2022-03-06 04:37:44 in reply to 6 [link] [source]
When building from the source zip, I don't get a compatible library. This must mean the nuget packages are built from a different set of source...
Makes it rather difficult to support other platforms. Guess I'll just have to go back to 126.96.36.199 for freebsd
(8) By cguardia on 2022-04-13 01:53:36 in reply to 7 [link] [source]
Same error here. Any update?
(9) By anonymous on 2022-04-22 22:04:36 in reply to 8 [link] [source]
(10) By mistachkin on 2022-04-23 17:11:37 in reply to 9 [link] [source]
Per my previous reply (see #3 above), this is by design.
(11) By anonymous on 2022-04-29 15:09:06 in reply to 10 [link] [source]
for me, these are my test results:
- v188.8.131.52 seems to work without exception
- v184.108.40.206 runs into this exception
so, the System.EntryPointNotFoundException at "SQLite.Interop.dll" might be introduced with some of last changes?
(12) By Paul Smith (PaulSmith) on 2022-05-01 07:09:45 in reply to 11 [link] [source]
I had the same problem, so I uninstalled v220.127.116.11, and installed 18.104.22.168. Now I get this exception:
System.IO.FileLoadException HResult=0x80131040 Message=Could not load file or assembly 'System.Data.SQLite, Version=22.214.171.124, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I'd be grateful for any help with this.
(13) By anonymous on 2022-06-01 08:37:39 in reply to 12 [link] [source]
This simply means that the newer version i still referenced somewhere in your code
(14) By anonymous on 2022-06-13 11:29:10 in reply to 6 [link] [source]
I don't understand why these SQLite.Interop.dll builds now use "encoded" entry point names. Just use plain english e.g. sqlite3_open_v2 or whatever.
The newer versions which use these encoded entry points means the DLLs become useless for any use-cases outside of the "official" System.Data.Sqlite assembly.
There are more use-cases for the SQLite.Interop.dll files than the maintainers perhaps realised.
(15) By jaymac on 2022-07-12 15:04:10 in reply to 14 [link] [source]
We too are desperate to see this fixed. Surely this is a backwards compatibly bug / oversight and not intentional, right?
I've spent much of a morning trying to guess the mangled name of sqlite3_create_window_function. Looking at the code it looks like it should be exported cleanly, but clearly it is not.
If you compare:
dumpbin /exports SQLite.Interop.dll
(on a Win64 machine) between 126.96.36.199 and 188.8.131.52 (both from the official nugets)
Dump of file SQLite.Interop.dll
File Type: DLL
Section contains the following exports for SQLite.Interop.dll
00000000 characteristics 5ED282B6 time date stamp Sat May 30 16:58:46 2020 0.00 version 1 ordinal base 387 number of functions 387 number of names ordinal hint RVA name 1 0 000380D0 _interop_compileoption_get@4 2 1 000380F0 _interop_compileoption_used@4 3 2 00038040 _interop_libversion@0 4 3 00038030 _interop_sourceid@0 9 4 000378E0 _sqlite3_backup_finish_interop@4 17 5 00037D00 _sqlite3_bind_double_interop@12 20 6 00037CC0 _sqlite3_bind_int64_interop@12 25 7 00037C50 _sqlite3_bind_parameter_name_interop@12 35 8 00037880 _sqlite3_blob_close_interop@4 44 9 00037F10 _sqlite3_changes_interop@4 47 A 00038050 _sqlite3_close_interop@4 57 B 000373B0 _sqlite3_column_database_name16_interop@12 58 C 00037410 _sqlite3_column_database_name_interop@12 61 D 00037AF0 _sqlite3_column_decltype16_interop@12
... 106 7F 00088820 sqlite3_create_module_v2 107 80 0006C1F0 sqlite3_create_window_function (THIS IS WHAT I NEED!) 109 81 000D3B10 sqlite3_data_count ... 386 181 00042380 sqlite3session_patchset_strm 387 182 00043B80 sqlite3session_table_filter
3000 .data 1000 .gfids 27000 .rdata 8000 .reloc 1000 .rsrc 107000 .text
Dump of file SQLite.Interop.dll
File Type: DLL
Section contains the following exports for SQLite.Interop.dll
00000000 characteristics 62979CAB time date stamp Wed Jun 1 18:06:51 2022 0.00 version 1 ordinal base 206 number of functions 206 number of names ordinal hint RVA name 1 0 00057EA0 SI02815e94e2c315f7 2 1 000586A0 SI039413da2b10b773 3 2 00090410 SI054e3c8468772b2b 4 3 001500B0 SI0628e029b7e108db 5 4 001197F0 SI077534168313d3ed 6 5 0004A300 SI0938f783b19237a0 7 6 00053990 SI0a886fd4c720116f 8 7 0011AD00 SI0bdc6d0c384d2e10 9 8 000457E0 SI0ce1fad4c4f4a7fb 10 9 00119F40 SI0cff507887d45bcd 11 A 000580D0 SI0d6b1c4a8f9f99d4 12 B 0008E370 SI0da8b85fb82501d5
.. 194 C1 00042CC0 SIf7e752fd3d0936c7 195 C2 0011A610 SIfc766c3d655f3fe2 196 C3 000453B0 SIfd60417394c54f67 197 C4 000F1FD0 SIfdd143ea824fb4f0 198 C5 0011BE60 SIff65f01991d44537 199 C6 00018DC0 sqlite3_cryptoapi_init 200 C7 00026870 sqlite3_fts5_init 201 C8 00026880 sqlite3_fts_init 202 C9 0001DFC0 sqlite3_percentile_init 203 CA 0001C4B0 sqlite3_regexp_init 204 CB 00019FA0 sqlite3_sha_init 205 CC 000193C0 sqlite3_totype_init 206 CD 00042C20 sqlite3_vtshim_init
7000 .data 1000 .gfids 12000 .pdata 43000 .rdata 2000 .reloc 1000 .rsrc 154000 .text
(16) By mistachkin on 2022-07-12 18:53:41 in reply to 15 [link] [source]
Follow up to #3: The precompiled interop assemblies within the official NuGet packages are only intended to be used with the managed assemblies also from those NuGet packages.
(17) By jaymac on 2022-07-12 19:17:23 in reply to 16 [link] [source]
That somewhat misses the point. We are using them from the managed assemblies, but happened to have added support for custom aggregate-window functions
so need the following to be callable
[DllImport("SQLite.Interop.dll"] private static extern SQLiteErrorCode sqlite3_create_window_function( IntPtr db, byte strName, int nArgs, int nType, IntPtr pvUser, SQLiteCallback fStep, SQLiteFinalCallback fFinal, SQLiteFinalCallback fValue, SQLiteCallback fInverse, SQLiteDestroyCallback fDestroy);
to work... just as it was in older versions like 184.108.40.206
(18) By mistachkin on 2022-07-12 19:31:09 in reply to 17 [link] [source]
I understand what you are saying; however, I think a better solution would be for me to enhance the SQLiteFunction class to support window functions.
(20) By jaymac on 2022-07-12 19:37:50 in reply to 18 [link] [source]
By all means, that would be great! I spent a fair day or two building that functionality (always tricky to toenail things in like that) - and would love it to be core
Still I really can't understand why you would expose mangled names, when you used to support readable ones.
I call that a backward compatibility break, and limits how people can extend the great work of this library (as we have done).
(22) By jaymac on 2022-07-12 21:29:32 in reply to 20 [link] [source]
In 220.127.116.11 maybe? :)
(23) By mistachkin on 2022-07-13 17:24:40 in reply to 22 [link] [source]
Yes, that is the plan.
(19.1) By Larry Brasfield (larrybr) on 2022-07-12 19:44:52 edited from 19.0 in reply to 17 [link] [source]
Joe has stated a true fact which is relevant to your "need". What you need to do is ensure that the correct DLL is loaded. This will necessitate more than merely naming "SQLite.Interop.dll" in the attribute. When a DLL to be loaded is specified without an absolute path, it is loaded according to a set of rules which you can lookup and exploit to solve your problem. First among those rules is that if the named DLL can be found in the same directory as the .exe which began the process, that will be loaded. (This is called "side-by-side" loading.)
What will not solve your problem is noisily hoping/wishing that what once happened to work for you will continue to work for you. If you were not taking care to get the correct DLL loaded, it was only an accident that one was found and loaded which happened to work. Taking such care is your job.
(Added via edit:) Taking care to ensure the correct DLL is loaded is established good practice even if somebody obviates your need to explicitly load a DLL or name mangling is done differently. The reason that side-by-side loading was added to the DLL locating algorithm was that problems such as are evident in this thread had proved to be very troublesome using the previous DLL loading rules.
(21) By jaymac on 2022-07-12 20:33:58 in reply to 19.1 [link] [source]
I agree with the point of "having to work carefully to load the right dll".
We do and are. Finding the right dll to side-by-side load is clearly important (we support many OSs for example), but again, we are doing that correctly.
Our issue is in attempting to update the nugets to pull in new SQLite dlls/features - and is focused only on the name mangling (in the correct new dlls).
After a huge amount of manual effort (change mangled name EntryPoint, re-build, run unit test, record failure... repeat 198 times) I failed to find the right entry point.
The closest I got was
[DllImport("SQLite.Interop.dll", EntryPoint = "SI1f188bbd4af5db07", CallingConvention = CallingConvention.Cdecl)] private static extern SQLiteErrorCode sqlite3_create_window_function( ...
which eventually led to:
braycurtis_distance() may not be used as a window function
so must map to one of these, presumably
sqlite3_create_function sqlite3_create_function16 sqlite3_create_function_v2
as opposed to sqlite3_create_window_function.
Is there any way in the source code that would let me reverse the name mangling (I worry I could have made a mistake in the aforementioned process, which was tedious and manual)? Another possibility is that it simply is not exported (which looking at the code I don't see why would be the case).
(24) By mistachkin on 2022-08-05 02:34:38 in reply to 21 [link] [source]
The feature is now present on the trunk in the System.Data.SQLite repository. Could you please test it out and let me know of any problems you encounter?