Memory corruption issues on isolates

[orakemu]

Edit from team: These issues are likely the same underlying problem:

• The app doesn't work in Flutter release mode (powersync error when async with server) #129
• [Android][Flutter release] Crash in DartWorker during PowerSyncDatabase.initialize() (SIGSEGV/SIGABRT, sometimes sqlite_async RangeError) powersync.dart#393
• (maybe) sqlite3_finalize crash (EXC_BAD_ACCESS / SIGABRT double-free) on macOS with createBackgroundConnection simolus3/drift#3771
• https://discord.com/channels/1138230179878154300/1194710422960472175/1468475869147304149

Summary

We reproduced a matched iOS profile-mode crash on a physical iPhone while using:

• powersync 1.18.0
• powersync_core 1.8.0
• sqlite_async 0.13.1
• sqlite3 2.9.4
• iPhone 16 Pro, iOS 26.2 (23C55)

The crash is not in the native PowerSync/sqlite libs. It is caught by LLDB on a DartWorker thread inside App.framework, and symbolication points into the Dart-side sqlite connection-isolate path:

• sqliteConnectionIsolateInner.handle
• sqliteConnectionIsolateInner.runStatement
• PortServer._init.<anonymous closure>
• mapParameters

Repro shape

This was reproduced from a clean install on-device using:

1. flutter build ios --profile --no-tree-shake-icons
2. xcrun devicectl device install app ... build/ios/iphoneos/Runner.app
3. LLDB waiting attach:
   • xcrun lldb -o "device select <CoreDevice id>" -o "device process attach -w -n Runner -c"
4. Launch:
   • xcrun devicectl device process launch --device <CoreDevice id> <bundle-id>

Matched repro 1

Fresh matched crash:

• Runner-2026-04-04-172738.ips
• matching App.framework / dSYM UUID:
  • BF2DD795-731F-3166-95C8-F2A21751E099

LLDB caught:

• EXC_BAD_ACCESS
• SIGSEGV
• faulting thread: DartWorker
• faulting address: 0x83f69a47
• App load address: 0x110ce8000

Top App frames:

frame #0: App`___lldb_unnamed_symbol_2e3c84 + 216
frame #1: App`___lldb_unnamed_symbol_2e3c84 + 192
frame #2: App`___lldb_unnamed_symbol_2e3ba4 + 88
frame #3: App`___lldb_unnamed_symbol_2e3a44 + 236
frame #4: App`___lldb_unnamed_symbol_2e3908 + 216
frame #5: App`___lldb_unnamed_symbol_2d2400 + 268
...
frame #18: Flutter`dart::DartEntry::InvokeFunction(...)
frame #19: Flutter`dart::IsolateMessageHandler::HandleMessage(...)

Symbolicated App frames:

profilerNameAndArgs (profiler.dart)
TimeSync.timeSync (profiler.dart)
sqliteConnectionIsolateInner.handle (native_sqlite_connection_impl.dart:374)
sqliteConnectionIsolateInner.<anonymous closure> (#2) (native_sqlite_connection_impl.dart:398)
PortServer._init.<anonymous closure> (port_channel_native.dart:252)
RawReceivePort._handleMessage (isolate_patch.dart:194)

Follow-up mitigations tested

We tested two more fresh profile builds:

1. Force profileQueries: false for the PowerSync sqlite open factory.
2. Force maxReaders: 1.

Both still crashed.

Matched repro 2: profileQueries: false

• fresh crash: Runner-2026-04-04-174331.ips
• matching UUID:
  • FE3FCBDA-A0D7-3785-99DB-EF86CC72A0B8

Still crashed on DartWorker with:

• EXC_BAD_ACCESS
• SIGSEGV
• faulting address 0x74623

Symbolicated top frames:

FollowerLayer.findAnnotations (layer.dart:2688)
mapParameters (shared_utils.dart)
sqliteConnectionIsolateInner.runStatement
sqliteConnectionIsolateInner.handle.<anonymous closure>
TimeSync.timeSync
sqliteConnectionIsolateInner.handle
sqliteConnectionIsolateInner.<anonymous closure> (#2)
PortServer._init.<anonymous closure>

Matched repro 3: maxReaders: 1

• fresh crash: Runner-2026-04-04-174733.ips
• matching UUID:
  • D6659CCA-F367-38CC-963D-ACC59C81E244

Still crashed on DartWorker with:

• EXC_BAD_ACCESS
• SIGSEGV
• faulting address 0x7

LLDB top frame:

frame #0: App`___lldb_unnamed_symbol_7db774 + 84

This means the crash is not explained by:

• query timeline profiling alone
• the default multi-reader pool width alone

Why I think this belongs here

The matched symbolication consistently lands in sqlite_async’s Dart-side isolate / port-channel / parameter-mapping codepath, not in app-specific feature code and not in the native sqlite / PowerSync extension binaries.

The strongest recurring frames are:

• sqliteConnectionIsolateInner.runStatement
• sqliteConnectionIsolateInner.handle
• PortServer._init.<anonymous closure>
• mapParameters

Question

Does this look like a known iOS profile-mode issue in the sqlite isolate path on sqlite_async 0.13.x?

If not, what would you recommend as the next best narrowing step?

• instrument runStatement / mapParameters for the exact SQL + parameter types?
• try an older sqlite_async line against the same app code?
• avoid the isolate-backed connection implementation for PowerSync on iOS profile?

[orakemu]

We ran a second iOS profile repro with our app startup heavily minimized behind a gate:

ORAKEMU_IOS_PROFILE_MINIMAL_POWERSYNC_STARTUP=true

Under that gate we skipped/delayed our app-owned startup work, including:

• CalendarDotsGlobalWatch.attach()
• LiveSurfaceGlobalWatch.attach()
• startup rcconnectToRC()
• the startup repair query
• initpowersync() until after the first frame

Result: the app still crashes in the same place.

Observed on the gated repro:

• LLDB caught EXC_BAD_ACCESS
• crashing thread: DartWorker
• faulting address: 0x83f69a47
• fresh App.framework/App UUID: C93F2127-8949-3272-992F-33E2343AA6E6
• top symbolicated frames are still:
  • profilerNameAndArgs
  • TimeSync.timeSync
  • sqliteConnectionIsolateInner.handle
  • sqliteConnectionIsolateInner.<anonymous closure> (#2)
  • PortServer._init.<anonymous closure>

This seems to rule out our app’s heavier startup sequencing as the trigger, or at least makes it much less likely. The crash remains reproducible even with most of our integration-side startup work removed.

If helpful, I can also provide the exact LLDB transcript for this gated repro. For now, the key takeaway is that a minimal iOS/profile startup path still crashes in the same sqlite_async isolate/port path.

[simolus3]

We've seen one other report of this, but so far we haven't been able to track this down. My best guess at this point is that something, probably in the sqlite3 package, corrupts the heap which later causes a crash in another place (I really don't see how mapParameters could call findAnnotations in some Flutter rendering library).

One thing potentially worth trying could be to enable asan when compiling your app. I've not tried that with a Flutter app before though, I'm not sure if something in Dart might be incompatible with it. But if this comes from the ffi layer with SQLite, that might catch it.

[SadiqCyber]

It's not just on iOS devices, but also on Android devices. The application closes immediately when synchronization starts. If you are on the login screens, the application works normally, but as soon as I get the token and start the synchronization process, the application is killed and exits, and it doesn't work at all.

[SadiqCyber]

I reported the same error more than half a month ago, but I have not received a response to address this issue. The application is nearing its delivery deadline, and this is a major problem.

#129 (comment)

[sparrow58]

powersync-ja/powersync.dart#393 (comment)

check my issue.. it might help. we checked commit by commit until we identified the issue

[simolus3]

To give an update on this, I've started testing the sqlite3 package with AOT builds (previously, tests were only running through JIT). This is a bit annoying to set up, but we can likely do that for sqlite_async and the PowerSync SDK as well. I've also set up tests with sanitizers (asan, msan and tsan). However, none of these found any issues in the sqlite3 package itself, which is the only package here doing actual FFI. We also run a few tests for the PowerSync SQLite core extension with sanitizers, but since that's written in Rust I think the likelihood of memory issues originating from there is unlikely.

We are currently working on a major refactor of the sqlite_async package and the PowerSync Dart SDK, we should hopefully have a beta release of that ready in a few days. Those pending changes also affect how we manage isolates and concurrency, so it's possible those might fix this.

However, the fact that this only happens on release builds is really odd. There's no difference between debug and release builds for native libraries, so this must be coming from Dart. And Dart doesn't have the undefined behavior footguns we might have with native libraries, so we should expect debug mode builds to behave identically. Finally, it's worrying that this can be worked around with Dart code changes (see the reports from @sparrow58 and also the Discord thread linked in the issue where changing some widget setup related to riverpod fixes this). So at this point it seems possible that this is a Flutter/Dart VM or compiler bug.

It would be very helpful if those still running into this could report the following:

1. The Flutter version in use.
2. How consistently you run into this (on every release mode app start, a few times in crashlogs in the wild, ...).

If it turns out to be a Dart bug, we'll likely have to come up with a small app reproducing this that we could share with the Dart/Flutter team. So far I haven't been able to reproduce this, so if any of you run into this with source code you might be willing to share, that would be very helpful.

[orakemu]

@simolus3 what's the best way to reach out to you and share source code?
I spend many hours trying to debug this and burning tokens on this (kinda burned out on the issue 😅) so I'd gladly share source code.

[simolus3]

Does your app crash every time when you start it? If you have a repository on GitHub you could add me to that, otherwise you could also upload a zip to google drive and share it with simon@powersync.com. If it needs additional setup instructions you could also email those to me, I can share them with the team to reproduce this.

[orakemu]

Yes it crashes each time in release and profile mode (Flutter 3.41.4)
I invited you to the private repo and sent instructions and extra details by email. Thank you for looking into this.

[simolus3]

A quick update: So far we haven't been able to diagnose a specific root cause. But in the app that @orakemu shared with me, I was able to consistently reproduce the issue with the latest 1.x release of the powersync package and the app starts with the 2.0.0-wip.0 pre-release.

It would be helpful to know if upgrading to powersync: ^2.0.0-wip.0 resolves the issue for you or if you're still running into problems. Please note that we're still working on that version though. We expect to have a stable release for that next week, but trying the pre-release version to see if it fixes the issue for you would be helpful.

[ttcat]

iPhone 15 Pro + iOS 26.5 + 2.0.0-wip.0 fixed the crash for me