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

IPC `ArrowFileWriter` can produce entirely zero-filled encapsulated messages

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

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
静か
技術スタック
csharp
領域
data

調査の方向性

まず ArrowFileWriter と、ArrowWriter.cs および ArrowBatchWriter.cs における使用箇所を読み、特に BaseStream.Position と、異なるスレッドからのシリアライズされた WriteRecordBatch 呼び出しを確認します。可能であれば、ゼロで埋められた IPC メッセージを再現し、圧縮書き込みと非圧縮書き込み、および影響を受けたオフセットを比較します。完了条件は、ArrowFileWriter が書き込みを行わずに位置を進められるかどうかを特定すること、または必要なストリームの使用方法や環境要因を記録することです。

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

説明

Describe the bug, including details regarding any error messages, version, and platform.

Environment

  • Apache.Arrow / Apache.Arrow.Compression 23.0.0, net472, x64, Windows 11
  • ArrowFileWriter over a plain FileStream, writing record batches continuously for the duration of a recording

Background

We are using Apache.Arrow to save continuous streaming data from ONIX hardware, where our project (OpenEphys.Onix1) is hosted as a package that can run in Bonsai-Rx.

Problem

Rarely, on one specific computer, a file comes out with an entire encapsulated message (continuation marker, metadata, and body) replaced by zeros. The footer is intact and its Block offsets are correct for every batch, including all batches after the zeroed one, so the file reads until it hits the gap and then raises ArrowInvalid: Unexpected empty message in IPC file format. Happens with and without Zstd compression, always early in the recording. Individual valid batches can be read and concatenated together, but this leaves a gap in the recorded samples as confirmed by our clock parameter.

ArrowFileWriter takes the block offset from BaseStream.Position and the following batch is recorded at the correct offset; we believe this points to Arrow having issued the writes and FileStream having accepted them, but the bytes were lost before being saved to disk. We'd like to confirm if this is the case before concluding it's environmental.

We are tracking this in our own issue in case it is how we are utilizing the API. For more details (e.g., byte offsets, and affected files), see open-ephys/bonsai-onix1#683. We have been unable to replicate this on two other systems.

Our usage

  • ArrowWriter.cs — construction, WriteRecordBatch, and WriteEnd on dispose
  • ArrowBatchWriter.cs — batches are accumulated with an Rx Buffer(timeout, count), so WriteRecordBatch calls are serialized but arrive on different threads (producer thread on a count flush, thread-pool timer thread on a timeout flush)

Note also that our ArrowBuffers wrap unmanaged memory via a custom MemoryManager<byte> to handle OpenCV.Net.Mat objects.

I'd be happy to answer any questions you might have about our usage, and if there is any other information I can provide to narrow this down please let me know.

Questions

  1. Is there any path in ArrowFileWriter that advances BaseStream.Position without writing bytes (a seek, or padding emitted by seeking)?
  2. Is there anything we should be doing differently? FileOptions.WriteThrough, periodic Flush(true) on the base stream, or otherwise to keep a lower layer from silently dropping a write like this?
主要言語
C#
スター
40
フォーク
30
平均マージ
1日 7時間
マージ済み PR（30日）
12

環境構築

はじめの一歩

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

apache/arrow-dotnet のほかの issue

apache/arrow-dotnet の issue をすべて見る

似ている issue

C# の issue をもっと見る

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

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