アカウント名:
パスワード:
makeを繰り返さなければ問題ないのか?
makeは単に複雑で負荷が高いから、それで気付いた、ってだけのようですよ。
現象から見ると、どんなプログラムでいつ起きてもおかしくない、エラーで落ちる以外にもデータの破壊等が起きてるかもしれない(気付いてないだけ)、という可能性も否定できない、というか十分ありそうとのこと。
Windowsで発生しない理由は不明ですけどね…。
makeというかgccによるコンパイルですね。今回に限らず、gccだけで症状が出るハードウェアの個別不良ってよくあって、以下のようにFAQ にまでなってます。https://linuxjf.osdn.jp/JFdocs/GCC-SIG11-FAQ/sig11faq.html [linuxjf.osdn.jp]一番よくあるのがメモリ不良で、今回もみんな最初はそちらを疑ってたんですが、色々調べているうちにどうやらメモリじゃないっぽいなということに。
ハードウェア不良なわけで他の処理で症状が出ても不思議はないんですが、他では症状がでなくてgccだけで出るせいでgccの方のバグだと疑われることも多く、FAQにまでなってるのはその辺の事情もあります。
6月頭のPhoronixの記事に対するコメントで、 [phoronix.com]「ハイパースレッディングを有効化していて、二つある内の一つのスレッドが(CPUコアをまたがずに収まる?)ループにある時に、もう片方のスレッドに割り込みがかかると、割り込み処理が終わった時のIRETQで復帰するタイミングでCPUが不安定化する」みたいなことを書いて、調査データをAMDに送付した。と言う人がいましたから、そこら辺の状況確認がやっと出来たんじゃないですかね。で、Linuxのスケジューラがどういうコア割付してるかはともかく、gccみたいにシングルスレッドをガンガン廻していくソフトだと、割り込み時処理のスレッドと、処理のスレッドが同じコアで共存しやすいとかそういう話なんでしょうかね。
OSのハードウエア差異の吸収可能範囲を超えた事をやらかしてるんだから、それはgccのバグでしょう。作法を無視してるとも言える。
> 最初に、トラブルの原因がハードウェアであることを確認してみよう。 make が停止したら、もう一度 make とだけタイプする。 停止する前にもう少しだけファイルをコンパイルしたなら、 トラブルの原因はハードウェアに間違いない。 また即座に停止する (すなわち、``nothing to be done for xxxx'' を表示しながら少しばかりディレクトリをスキャンした後、 きっちり同じ場所で玉砕する) なら、
これ、今どきの並列化されたmakeでは必ずしも当てはまらないのでは。
> kernelやgccなど大きなソフトウェアを繰り返し
ですからね。直接的なmakeの話ではなくて大事なのはこっちでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
繰り返し (スコア:0)
makeを繰り返さなければ問題ないのか?
Re:繰り返し (スコア:0)
makeは単に複雑で負荷が高いから、それで気付いた、ってだけのようですよ。
現象から見ると、どんなプログラムでいつ起きてもおかしくない、エラーで落ちる以外にもデータの破壊等が起きてるかもしれない(気付いてないだけ)、という可能性も否定できない、というか十分ありそうとのこと。
Windowsで発生しない理由は不明ですけどね…。
Re:繰り返し (スコア:2, 参考になる)
makeというかgccによるコンパイルですね。
今回に限らず、gccだけで症状が出るハードウェアの個別不良ってよくあって、以下のようにFAQ にまでなってます。
https://linuxjf.osdn.jp/JFdocs/GCC-SIG11-FAQ/sig11faq.html [linuxjf.osdn.jp]
一番よくあるのがメモリ不良で、今回もみんな最初はそちらを疑ってたんですが、色々調べているうちにどうやらメモリじゃないっぽいなということに。
ハードウェア不良なわけで他の処理で症状が出ても不思議はないんですが、他では症状がでなくてgccだけで出るせいでgccの方のバグだと疑われることも多く、FAQにまでなってるのはその辺の事情もあります。
Re:繰り返し (スコア:1)
6月頭のPhoronixの記事に対するコメントで、 [phoronix.com]
「ハイパースレッディングを有効化していて、二つある内の一つのスレッドが(CPUコアをまたがずに収まる?)ループにある時に、もう片方のスレッドに割り込みがかかると、割り込み処理が終わった時のIRETQで復帰するタイミングでCPUが不安定化する」みたいなことを書いて、調査データをAMDに送付した。と言う人がいましたから、そこら辺の状況確認がやっと出来たんじゃないですかね。
で、Linuxのスケジューラがどういうコア割付してるかはともかく、gccみたいにシングルスレッドをガンガン廻していくソフトだと、割り込み時処理のスレッドと、処理のスレッドが同じコアで共存しやすいとかそういう話なんでしょうかね。
Re: (スコア:0)
OSのハードウエア差異の吸収可能範囲を超えた事をやらかしてるんだから、それはgccのバグでしょう。
作法を無視してるとも言える。
Re: (スコア:0)
> 最初に、トラブルの原因がハードウェアであることを確認してみよう。 make が停止したら、もう一度 make とだけタイプする。 停止する前にもう少しだけファイルをコンパイルしたなら、 トラブルの原因はハードウェアに間違いない。 また即座に停止する (すなわち、``nothing to be done for xxxx'' を表示しながら少しばかりディレクトリをスキャンした後、 きっちり同じ場所で玉砕する) なら、
これ、今どきの並列化されたmakeでは必ずしも当てはまらないのでは。
Re: (スコア:0)
> kernelやgccなど大きなソフトウェアを繰り返し
ですからね。直接的なmakeの話ではなくて大事なのはこっちでしょう。