2011年5月15日のブックマーク (2件)

  • メモリ破壊の現場を見つけるTips - I am Cruby!

    RubyAdventJP, GC, Ruby(この記事はRuby Advent Calendar jp: 2009 : ATNDの4日目です。前日はmrknさんでした) 健全なるRubyistであれば、RubyのGCをいじることが週に一度はあるでしょう。そのときに困るのが、GCをいじってしまったことによるバグの修正です。GCをいじるというのは想像以上に難しく、少しでも書き間違えるとメモリ破壊が発生します。そのときに使えるTipsをこの記事で書くことにします。 みなさんご存じの通り、メモリ破壊というのは原因を特定するのが困難です。これは問題が発覚する場所とメモリ破壊が起こった現場が位置的に遠いことに起因しています。偉大なるハッカーのまつもとさんですら、その発見は困難です。 [ruby-dev:38628] Re: [BUG: trunk] called on terminated objec

    ImKim
    ImKim 2011/05/15
    メモリ破壊、デバッグ
  • コンピューター:C言語講座:デバッグについて

    コンピューター:C言語講座:デバッグについて 概要 プログラムを作成し、避けては通れない作業がデバッグです。理想的にはプログラムが完成した時点で動作も完璧であるのが最高ですが、さすがにどれだけ構造化を行って、丁寧にプログラムを組み上げても問題ゼロということは滅多にありません。ただし、元の作りが良いか悪いかによってデバッグの難易度は大きく左右されますので、まずはコーディング時にきちんと考えながら丁寧に組むことが一番です。 さて、デバッグですが、動かしてみて問題が出た場合にどうやって解決するかという点がメインになります。いちばん簡単確実なのはデバッガや、各種デバッグ用ツールを使うことですが、それぞれノウハウが必要です。個人的にはデバッガではdbxが使い慣れていて好きなのですが、GNUのgdbなど、環境に合せて使い分けが必要です。デバッグツールでもメモリーの不正アクセスやリークを検出してくれる非

    ImKim
    ImKim 2011/05/15
    デバッグログ