Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[firebase_storage] Windows native crash in upload progress callback, sink ownership and thread dispatch

Open
  • Is something wrong?
#18,664 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #18667 by @SelaseKay — closed without merging

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp, flutter
Domain
desktop-dev, operating-systems

Research direction

Start with the Windows PutDataStreamHandler, PutFileStreamHandler, and GetFileStreamHandler ownership and callback paths, then run the supplied concurrent putData harness on Windows. Compare the unchanged plugin with commit f9ea66025cbdd8b2b32fa762282194b4ba454d40 and its listed stress checks. Done means repeated uploads complete without a native crash or pending Dart completions, with byte-for-byte SDK readback.

Written by the indexing model from the issue text.

Description

blocked: flutter platform: windows plugin: storage reproduced type: bug

Concurrent putData calls can terminate the Windows process with an unhandled access violation in TaskStateListener::OnProgress / flutter::EventSink::Success. A Dart catch cannot catch this native exit.

Reproduced with firebase_storage 12.4.10, Firebase C++ SDK 12.7.0, and a Windows release build on Windows Server 2019 (17763). The relevant ownership and callback code is also present in current main (a57837ef40f73f0187b45125ecc0d81811b71bd9, firebase_storage 13.5.0); I have inspected that source but have not runtime-tested 13.5.0.

After normal Firebase initialization and authentication, run repeated bursts of small uploads to an authorized test path:

final bytes = Uint8List.fromList(utf8.encode(jsonEncode({
  'id': List.generate(300, (i) => i),
  'label': List.generate(300, (i) => 'Synthetic customer $i'),
})));
for (var round = 0; round < 3; round++) {
  await Future.wait(List.generate(13, (i) => FirebaseStorage.instance
      .ref('YOUR_TEST_PATH/${DateTime.now().microsecondsSinceEpoch}_$i.json')
      .putData(bytes, SettableMetadata(contentType: 'application/json'))));
}

The storage-only reproduction initializes Core/Auth/Storage, with no Hive, Firestore database initialization, or SQL. The unchanged plugin exited with 0xC0000005 about 14 seconds into one run. A separate release-app dump identifies the progress callback stack:

flutter::EventSink<flutter::EncodableValue>::Success
TaskStateListener::OnProgress
firebase::storage::internal::RestOperation::NotifyListenerOfProgress

Three relevant findings in the Windows plugin:

  • PutDataStreamHandler, PutFileStreamHandler, and GetFileStreamHandler store the sink as a std::unique_ptr<...>&& member. OnListenInternal assigns into that referenced temporary instead of owning the incoming sink.
  • Progress and completion call EventSink::Success from SDK worker threads. Flutter's platform message API requires the platform thread.
  • Keeping only the sink alive was insufficient in our stress checks: transfers could upload remotely while Dart completions remained pending. Keeping the exact StorageReference that starts each operation alive through completion, and moving completion processing onto the platform thread, resolved the tested stalls. SDK 12.7 source shows a potential FutureManager/API mutex inversion when a reference is orphaned during a pending Metadata result; I am not claiming the dump alone proves that entire lock cycle.

A local plugin candidate owns the sinks, posts events through a message-only Windows window, retains operation references and buffers until completion, and drops callbacks after plugin shutdown. It has passed 140 small uploads with byte-for-byte SDK readback (including ten bursts of 13), metadata updates, putString, putFile/writeToFile, overwrite, download URL, a 13 MB result, accepted pause/resume, eight accepted cancellations, missing-object and signed-out errors, and uploads after signing back in. The unchanged native plugin still crashes with the same Dart harness. Requested close during 13 active uploads exits without leaving a process. A separate super_native_extensions/msctf error during requested process shutdown also occurs without any Storage upload in the unchanged plugin, and in our previous full-app build; that is outside this report.

Candidate patch: https://github.com/BlazeSQL/flutterfire/commit/f9ea66025cbdd8b2b32fa762282194b4ba454d40 (based on our existing Firestore fork; this commit changes only Windows Storage).

Could you confirm the intended sink/reference lifetime and platform-thread dispatch approach? I can supply a minimal patch or further diagnostics. No customer data is needed to reproduce this.

Dominant language
Dart
Stars
9.3k
Forks
4.1k
Avg merge
1d 22h
Merged PRs (30d)
79

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from firebase/flutterfire

All issues in firebase/flutterfire

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.