by
Anonymous Coward
on 2018年01月30日 18時17分
(#3353502)
If you want to try it out on your Mac, you can run the program yourself! (at your own risk – for me it freezes some things but everything goes back to normal if I press ctrl+c, I don’t know what will happen if you run it :) )
今は知らんが、Snow Leopard 位の時には固まっているウインドウに（固まっていることを知らずに）キー入力して 反応がないからおかしいなと思って別のアプリケーションに切り替えると切り替えた咲のウインドウに さっき入力した内容が入力されたりした。ほかにも、日本語入力をオンに切り変えてすぐに A I U E O キーを 叩くと「aiuえお」みたいな入力になるような問題もあった。Apple にはまともな非同期処理を書く能力が無いんじゃないか?
変なタイトル (スコア:4, すばらしい洞察)
PoCが短い（17行）ことは不具合の本質ではないだろう。
関心をもうちょっと分離して
『macOS High Sierraのシステム全体がフリーズする不具合、PoCが17行のCコードで実装される』
としてはどうか？
Re: (スコア:0)
キユーピー3分クッキング全否定
＃普通に作れば、絶対に3分じゃ終わらないことでも有名だけど。
Re:変なタイトル (スコア:1, オフトピック)
Re: (スコア:0)
長いだろ。去年は十文字程度のコードでアップル製OS上のソフトをクラッシュさせられる文字列もあった。オーエスまるごと落ちるこれとは威力が違うが。
Re: (スコア:0)
あれ？
macOSにはフリーズするバグがあり、
いかに短いコードで実現するのかを競う競技じゃないの？
#現在の暫定１位がCで17行って事なんじゃ？
Re: (スコア:0)
待て待て、PoCでコードゴルフやワンライナーを競ったらそれこそ問題点の本質が見え難くなってしまうぞ。
#「入力欄で×文字しか受け付けないので、このフォームではインジェクション攻撃はできません！サニタイズ不要です！」とかほざけた牧歌的な時代には、PoCの短さを示すことにも意味があったのだが
Re: (スコア:0)
# \rm -fr /
Re: (スコア:0)
すべてのファイルが消え、OSはそのまま動作し続けるだけ。それ以外の副作用が起きるってどうして思うの?
# それ以前にPOSIXで"rm -rf /"はエラーにしろって決まってるからできないけどな
ちゃんと読めよ (スコア:2, すばらしい洞察)
Re:ちゃんと読めよ (スコア:2)
試してみましたけど、Ctrl+Cで停止できるとは限らないようです(^^;)
iTerm2から実行したときは、しばらくはCtrl+Cで停止できたんですけど、あちこち試してみていたらiTerm2自体がハングアップして応答しなくなりました。
こうなると、もうお手上げ。フリーズプログラムをkillできなくなります。
iTerm2は強制終了した後に起動しなくなるし、そもそもps使えないですし。
もちろんmacOS標準のアクティビティモニタも動作しません。
（プロセス一覧に何も表示されない）
ターミナル.appから起動したときは、最初からCtrl+Cに反応しませんでした。
Re: (スコア:0)
10.11.6 (El Capitan) では大丈夫みたい。
xterm (XQuartz) と Terminal.app で何度か試したけど、固まらないし、[Ctrl]+[C] で終了できた。
Re:ちゃんと読めよ (スコア:1)
システムの一部がフリーズするという記事から「システム全体がフリーズ」という見出しになってしまう安心と安定のスラドクオリティ。
Re: (スコア:0)
論理反転には定評のあるフェイクニュース拡散サイトです。
Re: (スコア:0)
その点についてはGoogle翻訳も人のことは言えないしなあ。
アップルもいろいろ大変だな（雑な感想） (スコア:0)
よし、私は2行でシステムを固めてやるぞ。
ちょっと違うか。(念のため書いとくけど、試すなら被害少ないところで)
#include <unistd.h>
int main(){while(fork()+fork()); return 0;}
Re:アップルもいろいろ大変だな（雑な感想） (スコア:2)
昔、sunosでsocket開いて、bindして自分にconnectに行ったらシステムごとfreezeしたなぁ。
Re: (スコア:0)
PC-9801シリーズ用Windows95なら1行で落とせました
sqrt(-1);
# PC-9801シリーズ用Windows95は浮動小数点例外の処理にバグがあり、
# 発生させるとブルースクリーン（PC-9801版は青くないが）になって
# 再起動するしかなくなる。Windows98では修正された
Re: (スコア:0)
これじゃコンパイラ通らないよ。
やりなおし
Re: (スコア:0)
Win9xとか0xfaの1バイトのCOMファイルで落とせるけど。
# たぶん仕様
Re: (スコア:0)
不具合でシステムがフリーズするのと、意図してシステムをフリーズさせるコードを書くのは全然違うだろ
そもそも1行でシステムなんぞ落とせるわ
# rm -rf / とか
# format c: とか、あるいはcmd /c rd /s /q c:\ とか
Re:アップルもいろいろ大変だな（雑な感想） (スコア:2, おもしろおかしい)
shutdown now
Re:アップルもいろいろ大変だな（雑な感想） (スコア:1)
権限が不足しています(棒)
Re:アップルもいろいろ大変だな（雑な感想） (スコア:1)
常にrootでログインしているので無問題です！(キリッ
Re: (スコア:0)
今日のプークス案件ですな
Re: (スコア:0)
C: から OSが起動している状態で、Cドライブのロックが解除されることはないから format c: は実際には実行できんけどな。
cmd /c rd /s /q c:\ は実行できるし、起動に必要なファイルもいろいろ消せるので起動しなくなるが、全てのファイルを消すことはできない。
ぬるぽ (スコア:0)
execはファイルロードまで含めたとても時間の掛かる処理だから単発のシステムコールとしてブロックせずに内部でバックグラウンド処理してると思うんだけど
プロセス管理データーの生成と基本的な初期化くらいはコール終了までに処理しとかないといけないところをバックグラウンド処理部分に入れちゃって
次のコールで未完成の管理データーにアクセスして落ちるとか？
Re: (スコア:0)
時間かかる処理だとしてもバックグラウンドでやる理由にはならないよ、固まって困るなら別スレッドで呼ぶ等の対策をシステムコールする側がとればいいだけ。
Re: (スコア:0)
ブロックも何もexecは戻ってこないよ？
Re: (スコア:0)
何言ってんだ、ファイルが無かったら戻ってくるだろ(棒
Re: (スコア:0)
今は知らんが、Snow Leopard 位の時には固まっているウインドウに（固まっていることを知らずに）キー入力して
反応がないからおかしいなと思って別のアプリケーションに切り替えると切り替えた咲のウインドウに
さっき入力した内容が入力されたりした。ほかにも、日本語入力をオンに切り変えてすぐに A I U E O キーを
叩くと「aiuえお」みたいな入力になるような問題もあった。Apple にはまともな非同期処理を書く能力が無いんじゃないか?
Re: (スコア:0)
Apple にはまともな非同期処理を書く能力が無いんじゃないか?
いつから同期処理ならまともにできると錯覚していた。
# ソフトの品質問題、ここ1～2年は酷すぎじゃね？
Re: (スコア:0)
> ここ1～2年は酷すぎじゃね
いつからここ1～2年の問題だと錯覚していた？
Re: (スコア:0)
プロセス管理構造体アクセスの排他設計が腐ってるだけでしょ。
例えばAのセマフォとって、Bのセマフォとるお約束のところを、
あるエントリーからはBとって、Aとってとかやってると死ぬ、とかの
初心者にはありがちなミスじゃないかと愚行するが。
3行で頼む (スコア:0)
Title Only
Re: (スコア:0)
相変わらず
macは
糞
Re: (スコア:0)
アイマックソ。縦に読んでもあんまり変わらない。
Re: (スコア:0)
・バッテリー劣化
・そのせいでフリーズ
・クロック半分にすれば回避加納
Pentium F00F バグ (スコア:0)
Pentium F00F バグ [wikipedia.org]ってのを思い出したわ。
アセンブリ言語一行でシステムがフリーズするというエラッタ。
そんなのに比べたらこんなのは大した事なさそうね。
Re: (スコア:0)
もっと例を用意しないと
うやむやにはできないぞ
むかし (スコア:0)
昔のMSのメーラで何かの文字列を書くだけでフリーズさせるってのがあった記憶がありんす
Re: (スコア:0)
つい最近も携帯で見たような…?
コードが短いことより (スコア:0)
htop みたいなメジャーなコマンドで固まることの方が問題だな。
(ubuntu 使いだけど htop は多用する)
Re: (スコア:0)
そうじゃない。センセーショナルにするためにわざとなのか、翻訳者の能力が足りないのか。
今回のバグは
「サンプルにあるコード(fork()とtask_for_pid()をループで全力)を回している状態で、
裏で ps を実行すると ps が固まることがある。ps 以外にも htop も固まる」
というもの。
task_for_pid なんてそうそう使う関数ではないし、fork と task_for_pid の間が
ミリ秒でも開くと起きなくなるらしいので、実環境では起こるとしても極稀な事象と
思われる。DoS に使うとしても微妙でセキュリティ的なリスクも高くない。
# ローカルから DoS したいだけなら fork 爆弾とかの方がよっぽど有効
こんなしょうもないバグがわざわざニュースになるとかアップルも大変だなあ的な話。
我らが linux なら見つけた人が即パッチ書いて、カーネルにコミットされて、
git の log に数行残るだけ忘れさられる程度ものではないだろうか。
Re: (スコア:0)
htopで監視してると、サーバーが高負荷になるった時に固まるだけだしね