[Android][Flutter release] Crash in DartWorker during PowerSyncDatabase.initialize() (SIGSEGV/SIGABRT, sometimes sqlite_async RangeError)

[sparrow58]

Note: We are tracking this in powersync-ja/sqlite_async.dart#137.

Summary

We are seeing a release-only crash on Android when PowerSync initializes the local DB.
The crash happens in a DartWorker thread during PowerSyncDatabase.initialize() (or immediately around that call).

Debug mode works.
Release mode crashes consistently (startup or right after login, depending on startup sequencing).

Environment

• Flutter: 3.41.4 (stable)
• Dart: 3.11.1
• Platform: Android 15 (arm64)
• Device: Samsung SM-S908U
• powersync: 1.18.0
• powersync_core: 1.8.0
• powersync_flutter_libs: 0.4.15+1
• sqlite_async (transitive): 0.13.0
• sqlite3: 2.9.4
• sqlite3_flutter_libs: 0.5.41

Expected behavior

PowerSyncDatabase.initialize() should complete successfully in release mode (same as debug), and app should continue to sync normally.

Actual behavior

App crashes in release mode during DB initialization.

Crash signature A (native)

• Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR)
• thread: DartWorker
• occurs right after app logs:
  • [DB_DIAG] before db.initialize()

Crash signature B (native VM abort)

• Fatal signal 6 (SIGABRT)
• Dart VM abort message includes:
  • runtime_entry.cc: ... hit null error with cid 94
• thread: DartWorker

Crash signature C (Dart-side, seen in some variants)

• RangeError (length): Invalid value: Valid value range is empty: 31
• stack includes:
  • mapParameters (package:sqlite_async/src/utils/shared_utils.dart:78)
  • _sqliteConnectionIsolateInner.runStatement (...)

App-side call path (from logs)

AppDatabase._initDatabase -> AppDatabase.database -> AppDatabase.connectWithToken/watch... -> db.initialize()

Example trace from app logs:

• [DB_DIAG] init start
• [DB_DIAG] before creating PowerSyncDatabase
• [DB_DIAG] before db.initialize()
• then native crash in DartWorker

Repro notes

• Reproducible in release builds.
• Not reproducible in debug builds.
• We also tested schema exclusion experiments:
  • Excluding item_categories and item_category_map changed behavior/signature in some runs, but crashes still occur in release.
• Upgrading to latest powersync stack listed above did not resolve.

Additional context

This appears to be a release/AOT path issue in or around PowerSync/sqlite_async initialization on Android arm64.
Happy to run test builds or provide additional diagnostics if maintainers suggest specific instrumentation.

Artifacts available

I can provide:

• full adb logcat -b crash output for both SIGSEGV and SIGABRT variants
• full app logs around [DB_DIAG] before db.initialize()
• minimal sanitized schema subset if needed

[simolus3]

See also powersync-ja/sqlite_async.dart#137, this is the third report of this that I'm aware of.

Does this reproduce every time in a release-mode app for you? We haven't made any larger changes to the initialization logic for some time, so I also wonder if this might be a regression in Dart/Flutter at this point.

I don't think the schema is relevant here, but having access to the adb crash log might be helpful.

[sparrow58]

Yes — for us this reproduces consistently in release mode only on Android (arm64), while debug mode is stable on the same device and app state.

Crash point:

• Right after PowerSyncDatabase.initialize() is about to run ([DB_DIAG] before db.initialize())

Also important context: this is not a new issue introduced by upgrading to latest PowerSync.
We also observed this problem on an earlier stack in our app history. So from our side, this appears to be a long-standing release-mode issue that still reproduces on current versions.

Fresh logs from latest run

I/flutter (  444): [DB_DIAG] before db.initialize()
E/Dart    (  663): ../../../flutter/third_party/dart/runtime/vm/runtime_entry.cc: 392: error: hit null error with cid 94, caller context: ...
F/libc    (  663): Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 663 (DartWorker), pid 444 (com.example.mahalkm_pos)

04-05 17:11:53.936   444   663 F libc  : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 663 (DartWorker), pid 444 (com.example.mahalkm_pos)
04-05 17:11:54.452   668   668 F DEBUG : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
04-05 17:11:54.452   668   668 F DEBUG : Abort message: '../../../flutter/third_party/dart/runtime/vm/runtime_entry.cc: 392: error: hit null error with cid 94, caller context: ...'


Why I think it is a schema problem, or it could be file attachment syncing?

I made a hard reset to a certain commit and the release problem solved.

I'm open to add any further information or make a zoom meeting with you

[simolus3]

Please also follow powersync-ja/sqlite_async.dart#137. I'll keep this issue open for visibility, but we want to track this in a single place ideally.

Having access to the schema or additional information that might allow us to reproduce this would be very helpful. I've sent you an email.

[sparrow58]

Thanks a lot for the quick response and for sending the email — really appreciate the support.

We were able to stabilize the app in release mode and identify the practical fix on our side.
The regression was introduced by a UI upload-hook call path where we passed the attachment write context into repository photo update calls (attachmentWriteContext usage in category/product/service screens). In release builds this led to login-time stalls/failures, and reverting those call sites restored stability all the way to our latest commit.

So this specific issue is fixed in our app, but one important takeaway is: this class of failure is very hard to trace. It can be triggered by different app-level scenarios/bugs, not only this exact one, and the runtime symptoms are often indirect (stall/crash elsewhere).

What would help a lot from the SDK side is clearer diagnostics when attachment/update-hook context usage is invalid or risky, for example:

explicit runtime validation of hook context compatibility,
structured error messages with operation context (table/query/hook phase),
non-fatal warnings before reaching opaque native/worker failures.
That would make these issues much easier to root-cause quickly and would help prevent similar reports from other integrations.

Thanks again.

[simolus3]

The regression was introduced by a UI upload-hook call path where we passed the attachment write context into repository photo update calls (attachmentWriteContext usage in category/product/service screens)

This should never cause a native crash! There must be something wrong on the SDK-side here still. It's helpful to know that there is apparently a way to reproduce this with Dart code changes. I'll try to use that to reproduce this on my end.

[sparrow58]

Absolutely — here’s a concise repro you can reply with (using the exact pattern that triggered it for us):

Thanks — agreed, this should not end in a native crash.

We can reproduce by passing the attachment hook write context into our repository update call from uploadPhotoFromPath(...) hooks.

Repro pattern
In UI save flows (category/product/service), this pattern triggered release-mode failures for us:

await uploadPhotoFromPath(
  path: selectedImagePath,
  updateHook: (ctx, attachment) async {
    await repository.updateProductPhotoId(
      itemId,
      attachment.id,
      attachmentWriteContext: ctx, // <- problematic path
    );
  },
);

and similarly:

await repository.updateCategoryPhotoId(
  categoryId,
  attachment.id,
  attachmentWriteContext: ctx, // <- same issue
);

In our datasource/repo, that context is then used as:

if (attachmentWriteContext != null) {
  await (attachmentWriteContext as dynamic).execute(sql, args);
} else {
  await db.execute(sql, args);
}

Behavior we observed
Debug: usually works / harder to trigger
Release: app can stall/fail around login/startup flow; we also saw native DartWorker crashes in some commit states
Removing this context usage from those UI hook call sites fixed stability across latest commit
Stable workaround on our side
Use hook without passing context through repo APIs:

await uploadPhotoFromPath(
  path: selectedImagePath,
  updateHook: (_, attachment) async {
    await repository.updateProductPhotoId(itemId, attachment.id);
  },
);

(and same for category/service photo update path)

If helpful, we can share the exact three call-site diffs where removing attachmentWriteContext made release stable.