macOSx /カーネル変数os_refcnt countとは何ですか?オーバーフローの原因は何ですか?

macOSx /カーネル変数os_refcnt countとは何ですか?オーバーフローの原因は何ですか?

開発中の一部のソフトウェアを実行すると、Macが16時間ごとにパニック再起動を引き起こし、tcshスクリプトを実行すると常に「os_refcnt」カーネル変数がオーバーフローする理由を特定しようとします。テストケースでは、中断された部分から再起動してコードを再実行すると、正しい結果が得られます。最初はこれがシェル変数への参照だと思いましたが、スクリプトを使用した後、いくつかの異なる方法ですべての変数を設定解除しても効果はありませんでした。

最大の質問は、「os_refcnt」が計算する「参照」はどのような種類のイベントですか?

カウント値がオーバーフローするのはなぜですか?なぜリセットしないのですか?同時スレッドが多く、メモリがリセットされるのを防ぐ「競争条件」のため、「参照」数のオーバーフローが発生しますか? (このプログラムは、12の独立した分岐で異なるデータに対して同時に実行されます。これは利用可能な最大値であり、実行時間は短くなります。)

Macのテクニカルサポートでは良いアドバイスを提供していません。

UNIXに似たシステムコールに加えて、スクリプトは、該当する場合はGNUプロジェクトのコンパイラでコンパイルされたプログラムを使用します。 CPU 時間の観点から、メインプログラムはスクリプトで作成されコンパイルされます。このプログラムは、他のプログラムによって計算された定数データの大きな配列をスクリプトに保存します。 4つの入力値は、配列の2つの要素のインデックスを指定する4つの整数であり、プログラムはこの2つの要素の値を掛けます。

「緊急報告ウィンドウ」のエラーは、「os_refcnt」(カーネルで使用する整数値システム変数)オーバーフローと関連があり、カーネルが何をしているのか分からなかったため、Google検索で調べた内容は次のとおりです。カーネルがすることの1つは、CPU温度を制御するために作業を遅くすることです。奇妙に見えて、温度を確認するためにCPU温度表示アプリをダウンロードしましたが、CPU温度がかなり高く、84℃から86℃の間を飛び回ってクラッシュが発生しました。円筒形MacPro「スタック」に外部ファンを追加して設置することで、ほとんどの場合、最大持続温度を82〜84℃に保つことができました。 16時間には2つのジョブが同期していたため、ジョブ内のセグメント間でCPUのダウンタイムがほとんどなく、CPUもやや暖かくなりました。しかし、外部ファンを使用すると、少し涼しい温度でも16.5時間後にコンピュータが死ぬことがわかりましたが、これは16時間と大きく変わらないようです。冷却が問題の場合は、CPUの冷却を試み、有用であることを確認するために意図的に遅延を追加することもできます。

私は成功せずにos_refcountインターネット検索を試しました。参照カウントオーバーフローがパニック再起動を引き起こす可能性がある理由について他の多くの推測をしました。メインスクリプトから呼び出されるすべての2次スクリプトと3次スクリプトが、「source」コマンドの代わりに「tcsh」コマンドを使用して実装されるようにスクリプトを設定し、2次スクリプトの終了時に変数の値を「忘れる」ようにしました。 、私も私が使用するすべてのシェル変数に明示的に "unset"を追加します。

カーネル変数"os_refcnt"が継続的にオーバーフローする原因が何であるかを知っている人はいますか? (私が使用しているスクリプトをtcshからbashに翻訳して状況が改善されるかどうかを調べようとしていましたが、それも少し無理なように見え、必要なデバッグをすべて実行する前に合理的な試みであることを確認したかったです。)現在は必要な結果を得ています16時間ごとにコンピュータを再起動するだけです。

問題はしばらくありました。現在MacOS10.15.4 Catalinaで動作しています。同じプログラムは以前のMacのように頻繁にOSをクラッシュさせませんが、〜10^8 "egrep -c"コマンドで1にNaN(エラー値)を返すようにします。これらのNaN値は実行中のスクリプトから取得でき、egrepsがすぐに再実行されると正しい数値が得られます。しかし、古いMacは約5〜20倍遅いです。また、円筒形ではなく、より一般的な長方形の箱型の煙突を持っており、うんざりする音がするファンがあります。古いMacは約1〜2週間後にクラッシュしました。おそらく、同じ数のプログラムサイクルの後に動作が停止したため、同じ問題が引き続き発生する可能性があります。 (衝突を避けるために、「egrep」の代わりに「awk」に対応するバージョンを使用して別のバージョンを試しました。他のバージョンでは、「egrep」がはるかに高速です。

Appleサポートチームに助けを求めたとき、「あなたのプログラム(他社製ソフトウェアなど)がクラッシュしました」という回答を受けましたが、「あなたのプログラムを実行しないでください」という状況が発生する以外はこれを防ぐためにあることはほとんどありませんでした。

ベストアンサー1

おすすめ記事