コンソールプログラムでWindows 2000がハングアップ 38
ストーリー by Oliver
緊急停止用の仕様です 部門より
緊急停止用の仕様です 部門より
odaken 曰く，"ニュースグループfj.os.ms-windows.programmingの一連の投稿によると、コンソールプログラムで簡単にWindows 2000がハングアップするかリブートするそうです。さぞかし巧妙なセキュリティーホールをついたものと思いきや、なんとprintf("\t\b\b")一発でいっちゃうというものでした。ちなみに私もWindows XPで試したところハングアップしちゃいました。プロセスが落ちるならまだしも、カーネルまで逝かないでほしかった。NT系カーネルは信用できると思ってたのにー。"
Re:このコマンドって (スコア:4, 参考になる)
Re:これですな (スコア:4, 参考になる)
コンソール出力APIの問題? (スコア:4, 興味深い)
大昔、JNetHackをwin32で作っていた時、似たような症状を見ました。putc()で2バイト文字を1バイトずつ出力するとfaultを食らうというものです(NT 4.0で。OSごと落ちたかどうかは失念)。
記憶がおぼろげですが、win32のコンソール出力APIには1バイト単位での入出力を行うものがなく、すべて文字列としていたような気がします。マルチバイト文字列がきちんと完結していることを前提にしてAPIを作っているのでしょう。最も、端末という考えのないOSに文字の片割を正しく扱えというのにも無理があるといえばありますが。
Re:これですな (スコア:4, 興味深い)
# リコール不要ですが修正パッチは欲しい...
Re:コンソール出力APIの問題? (スコア:4, 参考になる)
Unixでも確かにttyを使えばkernelは通ります。ですが、Unixのttyが解釈するのは基本的にフロー制御やジョブ制御などです。それ以外のデータについてはcharsetすら仮定をおいていません。あるいはラインディシプリンでも、せいぜい通信路が8bitか7bitかを指定できるぐらいです。
charsetやlocaleに基づいたデータの解釈など、より複雑な処理を実現するためには、Unixではpty(pseudo-tty)を使うのが普通です。これを使えばOSが想定していないようなラインディシプリンであっても、ユーザプロセスで実現できます(xtermやtelnetdなどもこれで動いている)。作れるttyドライバの自由度が高いことや、デバッグが容易なことから、現代のUnixではptyを使うことが多くなっています。
ptyに相当するものは、win32ではまだ出現していないはずです。といっても、ジョブ制御自体win32にはありませんが。
これですな (スコア:3, 参考になる)
どーいうことなのか… (スコア:3, 参考になる)
コンソール出力で\bを処理する時にバグでもあるのかな？
けど、コンソール出力関係の一般的な問題だったら、"copy con"かなんかで[Tab]-[BS]-[BS]で落ちそうですし。(元ニュースによると「漢字コード第二バイトの\t」と「\b\b」だったら落ちないそうです。)
なんかこのバグ自体の問題はともかくこういう基本的な部分でバグが出たということでNTの内部(ソースやら構造やら)が結構ぐちゃぐちゃなのではないか、という考えが頭をよぎります。
おそれることはありません (スコア:3, おもしろおかしい)
Re:コンソール出力APIの問題? (スコア:3, 興味深い)
表示のハードに至るまでの経路が全部、カーネルじゃなくプロセスの所有物ならば話は別ですが、
ふつーそういうことは無いでしょうし。
(俺は知りませんがきっと)unixでも、
あるバイト列を表示するまでに原理的に最低1回はプロセスからカーネルかなにかに処理が回ってくるはずですよね？
まぁ、どっちにせよ今回の失態は笑って看過できるもんじゃないですが＞win
他にも...(was Re:コンソール出力APIの問題?) (スコア:3, 参考になる)
結局、どう解決したかというと、Ctrl-M(CR) コードで１カラム目に戻してから、戻るべき 位置まで同じ文字列をもう１度出力してから カーソルを右に移動させるという力技。
エスケープシーケンスがまともにつかえたらなー。
Re:これですな (スコア:3, 参考になる)
@echo off
cls
:LOOP
echo " " ←"\t\t\b\b\b\b\b\b" に当たるコードを直埋め込み
goto LOOP
でもいけました。
ポイントは、cls みたいです。これが無いとコマンドラインからは再現できませんでした。
内部的に、画面左上より戻ったバッファ位置に書き込んじゃうんではないかと想像されます。
kaokun
Re:これですな (スコア:3, すばらしい洞察)
# で、修正パッチを探しているのですが
# まだ公開されていないんですかね？ > MS さま
Re:これですな (スコア:2)
元ネタのコンパイラはなんですか?
わしのは cygwin....
Re:これですな (スコア:2, おもしろおかしい)
Re:他にも...(was Re:コンソール出力APIの問題?) (スコア:2)
件の役に立つかどうかは存じませんが CONSOLE_SCREEN_BUFFER_INFO 構造体周りをホゲればどうにかなりませんかね？ (ウソだったらごめんなさい)
Re:他にも...(was Re:コンソール出力APIの問題?) (スコア:2)
多分カーソルの位置設定は SetConsoleCursorPosition() の方です。_(_ _)_
Re:このプログラムは.. (スコア:2, 参考になる)
結果：
16bit版:正常
32bit版:即死
でした。DOS仮想マシンの中では大丈夫みたいですね。
以前SJISを1byteずつ出力して落ちた時も、16bitアプリは大丈夫でした。
四年前に (スコア:2, 興味深い)
罪深いでしょうか?
Re:これですな (スコア:2)
# 一ヶ月周期くらいにしとけば誰も疑わなかったりして。 :-)
Re:「死ぬのはそのプロセスだけにする」とは (スコア:2)
# 今回の問題って WIN32 サブシステムだと思うんですけど...
このコマンドって (スコア:1)
できたら大変なことになると思うのですけど…。
k2luna−来栖 香
Re:これですな (スコア:1)
WindowsXPは発売早々リコールしてくれないかな。
Re:これですな (スコア:1)
オフトピ失礼 (スコア:1, おもしろおかしい)
Re:コンソール出力APIの問題? (スコア:1, すばらしい洞察)
(というより、それをWindowsに求めるのはユーザのあるべき姿ではないのかも知れない)
Re:コンソール出力APIの問題? (スコア:1, すばらしい洞察)
どこで落ちているのかは知りませんが…。 (スコア:1)
や、関連するユーザプロセスがお亡くなりになることまでは
許せても、リブートするなんてのは、論外なのでは…。
from もなか
Re:これですな (スコア:1)
いまだに来るんですが...(^^;>Nimda
Re:コンソール出力APIの問題? (スコア:1)
UNIX System V Release 4 (SVR4) 系のシステムには， そのラインディシプリンモジュールである ldterm に文字エンコーディングを意識する部分があります．
それは canonical 入力処理で ERASE 文字を操作する部分で， 端末から ERASE 文字が入力されると，直前の文字が何バイトの文字で，画面上を何カラム占有しているかを意識して，バッファの最後の文字を削除し，画面上の消去処理 を行います．(ERASE 文字は直前の「1文字」を削除する処理ですので，当然1文字が何バイトかを意識するし， それを画面上で反映する必要性から，カラム数も意識します．)
Re:これですな (スコア:1)
":LOOP"と"goto LOOP"はなくても確実に落ちるようです。
環境によってはループさせないと落ちないことがあるのでしょうか。
タイミング依存?
感想 (スコア:1)
まだ、DOS 世代なわけですな。
Re:コンソール出力APIの問題? (スコア:0)
このプログラムは.. (スコア:0)
Re:コンソール出力APIの問題? (スコア:0)
> 腐った仕様変更ばかり続けてるよなぁ。個々の判断にエンジ
> ニアリング的な合理性はあるんだろうが、 気が付いたらと
> てもサーバーには使えない構造になっ てるんじゃないか？
カトラーの不在中にGDIがカーネルモードで動くように改悪されてカトラーがキレたという噂が。
罪は深くないが (スコア:0)
罪は深くないと思うけど、せっかく３年もあっためたんだから、もっと派手に発表してもらいたかった、という感じやね。
「死ぬのはそのプロセスだけにする」とは (スコア:0)
何かトラブルが起こったとき、その原因は、 カーネルにあるか、カーネル以外にあるか、 どちらかです。
- カーネルに原因があるのなら、
デバッグしましょう。
- カーネル以外に原因があるのなら、
問題が起きたときに、
問題を起こしたプロセス以外は保護しましょう。
これが、"最低限、死ぬのはそのプロセスだけにするのが、OSの役割なのでは？"という意味です。Re:四年前に (スコア:0)
Re:四年前に (スコア:0)
もう環境がないから確認できないけど、3.51では落ちなかったように記憶している。