macOS上のOpenAIのCodexデスクトップアプリのユーザーは、アプリケーションのクラッシュ報告メカニズムであるCrashpadが、無制限の保留中のメモリダンプを生成するという重大なバグを特定しました。GitHubの報告によると、この問題はアプリケーションのサポートディレクトリ内に、ペアになった`.dmp`および`_sidecar.json`ファイルが継続的に作成される形で現れます。ある記録された事例では、このプロセスによって1日で約4.9GBのデータと54,000以上のファイルがローカルディスクに追加され、調査中もその数は増加し続けていました。

CodexデスクトップアプリのCrashpadファイル増加を説明するGitHubの問題の概要
Codexデスクトップアプリがペアになった.dmpおよび_sidecar.jsonファイルを継続的に生成し、急速なディスク消費を引き起こしたことを詳述するGitHubの問題報告。github.com

この画像は、GitHubの報告で文書化されている、Crashpadメカニズムが無制限の保留中のメモリダンプを生成するという特定のバグを例示しています。

この問題の技術的な分析は、クラッシュ報告を管理するために使用されるヘルパープロセスである`browser_crashpad_handler`が、クラッシュと再起動のループに入っていることを示唆しています。あるユーザーは、ハンドラーがMachポート通知を要求する際に「無効な機能(invalid capability)」に関連する`FATAL`エラーを生成していることを観察しました。ハンドラーが繰り返しクラッシュして再起動するため、サイクルごとに新しいクラッシュレポートが生成されます。これにより、クラッシュ報告システム自体がクラッシュの原因となるフィードバックループが発生し、メインのアプリケーションが使用不能になることなく、急速なディスク消費を引き起こします。

このプロセス中、アプリ自体は動作し続けますが、ファイルの急速な蓄積により利用可能なストレージをすぐに使い果たす可能性があります。一部のユーザーはさらに深刻な事例を報告しており、あるユーザーはディレクトリサイズが61GBに達し、約1秒間に1つのクラッシュレポートが生成される速度であったと報告しています。ユーザーによって特定された一時的な回避策は、システムフラグを使用してCrashpadデータベースディレクトリを読み取り専用かつ不変に設定することであり、これによりハンドラーによる新しいファイルの書き込みを防ぎます。しかし、これはアプリがクラッシュレポートを正常に送信できなくなることを防ぐためのローカルな緩和策であり、根本的なループに対する恒久的な修正ではありません。