Repository navigation
M.D.Sqlite: More robust cross-platform extension loading #35715
Description
Activity
- linked a pull request that will close this issueImprove LoadExtension to work correctly with dotnet run and lib* named libs #35617
on Mar 3, 2025 Keeping open to track backporting to 8.0 and 9.0, for a better sqlite_vec story.
- changed the title
[-]M.D.Sqlite: more robust cross-platform extension loading[/-][+]M.D.Sqlite: More robust cross-platform extension loading[/+]on Mar 3, 2025 The
SpatialiteLoaderclass has static stringmod_spatialitebut the LoadExtension class fully supports also absolute paths.
The EF core more or less forces a callSQLitePCL.Batteries.Init()but it is sometimes not wanted, especially if an open sqlite connection used for the DBContextOptions.There is a very nasty behavior with the none standard module loading of sqlite extension like of spatialite
and it seams there is no guard against dual loading of two versions of libsqlite3 native and also libe_sqlite3 by mistake.with only native libsqlite3 or libe_sqlite3 it is easy but to have both in a project for cross platform use
theSQLitePCL.Batteries.Init()call will take alwayslibe_sqlite3if the depdency is added
and even if the native module was already used.This results in a very unstable and none-deterministic crashes (2/3 simple runs will work).
See my working example to overcome this issue and use a project with docker and also on windows:
dotnet/EntityFramework.Docs#5308 (comment)@Zetanova is your comment specifically related to work in #35617 (the PR for this issue)? In any case, is this the issue already being tracked in dotnet/EntityFramework.Docs#5308, or are you reporting an additional problem?
@roji yes the issue is tracked there, but it is related to
cross-platform.
Currently if only one of the packages is used (SQLitePCLRaw.bundle_e_sqlite3orSQLitePCLRaw.bundle_sqlite3)
then it works great and it will be locked more or less to one platform.If both are used in a project, then it will generate sometimes hard errors
because of the internal setup in EF core of the sqlite connections.
It took me long time to discover that EF core tries to load also the e_sqlite3 bundle over the already loaded libsqlite3,
even if the sqlite connection was manually setup and all modules loaded and initialized.Errors could be under docker/ubuntu:24.04, and more often then not it works without any errors:
corrupted size vs. prev_size
malloc(): unaligned tcache chunk detected
AddGeometryColumn() error: unexpected metadata layout
munmap_chunk(): invalid pointerReacted by Shay Rojansky/cc @cincuranet
Our current (native) extension loading story for Sqlite isn't great: it's usually up to the user to make sure that the native DLL/so/dylib is present in the operating system search path, etc. (e.g. spatialite docs). This notably makes the getting started story for popular extensions like sqlite_vec much more difficult than it should be.
Thanks to @krwq for working on improving this.
Note: update the spatialite docs.