Openapoc: ログサイズが82MiBを超えるとクラッシュする

私はこれを再現することができませんでした-それはまだ起こりますか？

数週間前、500MBを超えるログファイルがありました。

不和からコピーアンドペーストするだけで、最新のダウンロードでこれを自分で複製することはできませんでした

閉鎖されますが、必要に応じていつでも再開できます

デバイスではなく、ATMでgitにアクセスできますが、82MBを超えるログの問題に関して

これはまだいくつかのデバイスで発生します...私が持っていた最低の端は82MBです

最高は4GBのFAT32ファイルサイズの上限です

再現するのは難しいですが、事実上、82MBを超えると、遅かれ早かれ、Windowsシステムは大きなログファイルへの書き込みに失敗し、OpenApocはログへの書き込みに失敗してクラッシュします。

ログをファイルシステムの制限まで拡張し続ける必要がありますか、それとも50MBで切り捨てる必要がありますか？
明らかにNTFSとexFATでは制限が高いため、書き込みが遅れない限りクラッシュするのに時間がかかります

JonnyH昨日09:14
まだこれを再現できません。ログが500MBを超えていて、クラッシュは見られませんでした。
たぶんそれは実際にはログではありませんが、たまたま同じタイミングで何か他のものがありますか？ メモリリークか何かのように？
クラッシュからバックトレースがありますか？ appveyorビルドを使用している場合、pdbファイルからシンボルを取得するためにデバッグパッケージを抽出する必要がある場合があります

Filmboy84昨日09:17
可能性がありますが、Win7NTFSシステムではめったに発生しませんでした

それは、古いFAT32WinXPインストールでより多く発生します

バックトレースを取得してみることができます

これを見てから久しぶりです（今は癖ごとにログファイルを削除してます）

デバッグパッケージが再び機能している場合（思い出すとしばらくはありませんでした）、調査します

JonnyH昨日09:19
うーん、私はもうwin7やfat32には何も持っていないので、それらが関連している場合は再現に問題があるかもしれません
しかし、それがログファイルのサイズそのものだったとしたら驚きます-私たちは、時間をかけてかなりの戦闘テストが行​​われた標準のAPIを使用しています

Filmboy84昨日09:49
それは確かに奇妙なものです

NTFSを使用したWin10で問題が発生したことはありません

次のGitフレンドリーなデバイスで、これらすべての問題を更新します

また、無数のLinuxファイルシステムの下では問題ないようです（HPFSのような古いものを含む）

そのため、ファイルサイズの制限に達する以外は、ファイルシステムにリンクされていない可能性が高いことに同意しました。その時点まで、メモリリークについては考えていませんでした。