> Rule of Repair > Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.
Windowsでもクラッシュ (スコア:0)
Windowsでもクラッシュするということは、メモリ確保に失敗したのに
エラー処理をせずに未確保領域を使用してしまっているということ?
Re:Windowsでもクラッシュ (スコア:2)
(´・ω・`)しらんがな。
読書き無しでも、割当失敗で即例外を吐いて死ぬっていう実装は、割とよくある。
Re: (スコア:0)
チェックしたら遅くなるだろ
Re: (スコア:0)
ioのエラーかもよ。実装次第だけど。pushstateはセッション履歴だけど、モダンブラウザはセッション履歴もローカルファイルに書き込む(=クラッシュした時やり直せるように)から、通信時間がゼロな分、DOS系としては割と脆弱になりやすい。(関係者談)
Re: (スコア:0)
メモリ確保に失敗したらリカバリは原則不可能だからね。
メモリ切れになると例外を動かすメモリがない可能性があるし。
一部の高信頼性が必要な機器は対策してるかもしれないけど。
Re: (スコア:0)
Firefoxの場合だと(プロジェクトが古いので例外の使用を禁止している関係もあるけど)infallible allocatorという、割り当てに失敗したらその場でクラッシュするアロケーターを原則として使って、明らかに失敗する可能性が高そうな割り当て(大量のグラフィックメモリの確保とか)だけ、個別に失敗をチェックできるアロケーターを使っている。
ただしこれはGeckoの場合なので、iOS版では単にSafariと同じWKWebKitのバグを踏んでいるだけだと思う。
Re: (スコア:0)
うろ覚えだが、以前Becky!の開発者が、「復旧不可能な問題が起きたらアプリをクラッシュさせるのが一番安全だ」と言ってた記憶がある。
例えばメモリが確保できないような状況ではプログラムが予想通りの動作をすることは期待できないから、
無駄なあがきをしてデータをぶっ壊すよりも、一度プロセスを落っことして、再起動したプロセスでリカバリするほうがよいとか何とか。
(記憶違いだったらごめんなさい)
なので、アプリが落ちるのは一見みっともないけど、実はそんなに悪くもない対応らしい。
#でもOSがクラッシュするのはあかんな。
Re: (スコア:0)
新人のころ、出力に信頼が求められる類のアプリで変に生かすよりも落とした方がいいって教育された思い出
Re: (スコア:0)
gzipのLZH脆弱性に対するパッチ [mie-u.ac.jp]は、明らかに入力がおかしくてまともに展開できるはずがないのに無理やり処理を続けるような方針でなかなかひどかった。あげくの果てに(micco氏が指摘する通り)パッチがバグってたし。Googleの研究者が書いたというのだからなかなか絶望感がある。ほかのLHA絡みのプロジェクトもたいていはほぼそのままこのパッチを取り込んでるし。
Re: (スコア:0)
よく言われるこれですね。
> Rule of Repair
> Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.