macOS: SIGSEGV (branch to 0x0) in sqlite3_update_hook during Database.close() — native-asset framework mapped twice in one process

[djbuys]

Environment

• sqlite3: 3.1.7 (transitive via drift 2.32), loaded through native assets with the hook override:

  hooks:
    user_defines:
      sqlite3:
        source: sqlite3mc

• Flutter 3.44.0 stable / Dart 3.12.0
• macOS 26.4.1 (25E253), arm64 (MacBook Pro, Mac17,9)
• App: Flutter desktop POS, several sqlite3mc-encrypted databases (drift NativeDatabase + occasional raw sqlite3.open health probes)

Symptom

Intermittent hard crash — 3 occurrences in one day of testing, same signature every time:

• EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0, pc = 0x0 (Instruction Abort — a branch to NULL)
• lr = sqlite3mc sqlite3_update_hook + 48
• Main thread, inside the Dart microtask queue, during package:sqlite3 Database.close() of a short-lived probe database (sqlite3.open → PRAGMA schema_version → close()), while the app holds other sqlite3mc databases open. close() detaches hooks via sqlite3_update_hook(db, NULL, NULL), which is the crashing frame.

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   ???                  0x0 ???
1   sqlite3mc            0x102d5f130 sqlite3_update_hook + 48
2   App                  0x117e45590 kDartVmSnapshotInstructions + 21904
...
21  FlutterMacOS         0x103c84a58 tonic::DartMicrotaskQueue::RunMicrotasks() + 176

The smoking gun: the native-asset framework is mapped TWICE in one process

Every crash report's Binary Images section lists the sqlite3mc native asset twice — same UUID, same on-disk path, two different load addresses — and the crashing address (0x102d5f130) lies inside the second mapping:

0x1225a0000 - 0x12274ffff io.flutter.flutter.native-assets.sqlite3mc (1.0) <dc12900b-c778-31a7-9fba-d6bd308fe478>
    .../Contents/Frameworks/sqlite3mc.framework/Versions/A/sqlite3mc
0x102d40000 - 0x102eeffff io.flutter.flutter.native-assets.sqlite3mc (1.0) <dc12900b-c778-31a7-9fba-d6bd308fe478>
    .../Contents/Frameworks/sqlite3mc.framework/Versions/A/sqlite3mc

With two copies of the library's static state in the process, a sqlite3* handle created through one copy can be passed to a function resolved against the other. If that second copy never ran sqlite3_initialize(), sqlite3GlobalConfig.mutex.xMutexEnter is NULL and sqlite3_update_hook's mutex-enter is a branch to 0 — which matches the register state (pc=0, lr=sqlite3_update_hook+48) exactly.

Two likely-related packaging artifacts from the same hook build:

1. Every flutter build macos emits a warning along the lines of "different framework names for different architectures … ignoring sqlite3mc1.framework" — suggesting the hook produces two asset registrations for one library.
2. The app bundle also ships CSQLite.framework alongside sqlite3mc.framework (a third sqlite copy), even though the user-define switches the source to sqlite3mc.

These persist through flutter clean and reproduce on every build with 3.1.7 (and per a quick changelog read, nothing addressing this landed through 3.3.x — happy to be corrected).

Reproduction

Not deterministic — it needs the right interleaving of open/close against multiple encrypted DBs, but it fired three times in one ~11-hour test day (09:30, 10:57, 20:07), always within ~100ms of a burst of sqlite3.open/close() probe activity. I have all three full .ips crash reports and can attach them.

Workaround

We reduced raw open/close frequency (probing each DB file at most once per process launch), which shrinks the window but obviously doesn't fix the dual mapping.

Happy to test patches, dump dyld info from a live process, or provide the full crash reports / a sample app skeleton.

[simolus3]

A sample app skeleton to reproduce this would actually be helpful. Is this in a release-mode app? I really don't see how the native asset would get loaded multiple times, it's not supposed to.

[djbuys]

Two more occurrences since filing, with new diagnostic signal.

Fourth crash — the "first open of a launch" pattern. Identical signature (pc=0, lr = sqlite3_update_hook + 48, framework mapped twice). Matching all four crashes against our open/close breadcrumb log: every crash hit the first open of the secondary module's databases in a given process launch, several minutes after boot; repeat opens in the same process never crashed (~15 successful opens across the same day), and neither did first opens that happened within the first minute after launch. Reducing the raw probe open/close frequency (once per launch instead of per module-mount) did not prevent it — the crash simply moved to the remaining first probe.

Fifth crash — a different entry point. We then added a boot-time warm-up (several sqlite3.openInMemory() → PRAGMA → close() cycles right after the app's first database open, confirmed by the breadcrumb log). The next crash still occurred — but this time in sqlite3_bind_double → vdbeUnbind + 64 → pc=0x0 during a live query, no close()/update-hook involvement at all. Same process state: the native-asset framework mapped twice (same UUID, two load addresses), crashing address inside the second mapping.

Reading of the evidence. This isn't specific to the hook-detach path: any call site that resolves into the second (never-initialized) mapping faults on its first sqlite3_mutex_enter (NULL xMutexEnter until sqlite3_initialize runs in that copy). The "warm-up doesn't help / repeat opens are safe / different API entry points crash" pattern is consistent with per-call-site lazy resolution of @Native symbols occasionally landing in a different mapping of the same asset once the second mapping exists — after that, which mapping a given call uses is fixed per call site, so a process either stays healthy or crashes on the first use of an unlucky call site.

All five .ips reports available — attaching the three from the first day plus the two new ones. Happy to run instrumented builds or dump dyld image lists from a live process if useful.

[djbuys]

Archive.zip

[djbuys]

the other IPS files have been deleted already - hope this helps!
thx

[simolus3]

In version 3.3.3 of package:sqlite3, we no longer call sqlite3_update_hook(null) if no update hook was installed in Dart. That might at least change the symptoms a bit, but I don't think it fixes the issue.

If you could provide a Flutter app that reproduces this (loading libsqlite3mc.dylib twice), that would be really helpful.

[djbuys]

hi Simon We are using 3.1.7 - so I will bump up to 3.3.3 and see if we get that same issue I will revert Regards

…

On 13 Jun 2026 at 11:26:37, Simon Binder ***@***.***> wrote: *simolus3* left a comment (simolus3/sqlite3.dart#381) <#381 (comment)> In version 3.3.3 of package:sqlite3, we no longer call sqlite3_update_hook(null) if no update hook was installed in Dart. That might at least change the symptoms a bit, but I don't think it fixes the issue. If you could provide a Flutter app that reproduces this (loading libsqlite3mc.dylib twice), that would be really helpful. — Reply to this email directly, view it on GitHub <#381?email_source=notifications&email_token=ARJ46J36ADQY6VOZVQJZ5Y347UM43A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHAYTENBVGIYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4698124520>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARJ46J5NRXFOAJL2W3CJQMD47UM43AVCNFSNUABFKJSXA33TNF2G64TZHMZDONZWGA4DINZUHNEXG43VMU5TINRUGMYTQMBZGUYKC5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>