Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#18,664 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

  • #18667 @SelaseKay による — マージされずにクローズ

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
cpp, flutter
領域
desktop-dev, operating-systems

調査の方向性

まず Windows PutDataStreamHandler、PutFileStreamHandler、GetFileStreamHandler の所有権とコールバックのパスを確認し、次に提供された並行 putData harness を Windows 上で実行します。変更していない plugin と commit f9ea66025cbdd8b2b32fa762282194b4ba454d40、およびその一覧にある stress checks を比較します。完了の条件は、ネイティブクラッシュや保留中の Dart completions が発生せず、SDK の readback がバイト単位で一致した状態で、アップロードを繰り返し完了できることです。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Dart
スター
9.3k
フォーク
4.1k
平均マージ
3日 4時間
マージ済み PR（30日）
56

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

firebase/flutterfire のほかの issue

firebase/flutterfire の issue をすべて見る

似ている issue

Dart の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。