ユメのチカラ: gdb/xemacs/cscopeの使い方
プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。 ポインタによって字面では変数が登場しなくても参照、変更される事もあるので油断禁物である。 またグローバル変数が嫌われるのは、ソースコードを局所的に調べていてもその代入、参照の範囲がつかめないからである。別のディレクトリに格納されている見た事も聞いた事もないファイルで変更されていて、当該ディレクトリをgrepしただけでは発見できなかったりする。 ローカルな変数ならばソースコードを静的に読解していけば、宣言、代入、参照それぞれが局所化しているので簡単に理解できる。 変更の影響もローカル変数ならば局所化されているがグローバル変数だとどこに影響が発生するかよくわからないのである。 さてブレークポイントを設定し、そこで実行が停止したとする。最初の仕事はその関数がどこから呼ばれ
ユメのチカラ: ソースコードの読み方（ニコニコ動画(RC2)で公開）
ユメのチカラ インターネットの時代になって、地球規模の知恵の集積が 可能になった。ソフトウェア開発においてもオープンソースソフトウェアのバザール的開発が注目されている。いまおきているその現実を現場の視点から記していきたい。 吉岡 弘隆 - よしおか ひろたか 日本OSS推進フォーラム ステアリングコミッティ委員 OSDL Board of Directorsを歴任 カーネル読書会主宰 2000年6月、ミラクル・リナックスの創業に参加。 95年～98年、米国OracleにてOracle RDBMSの開発をおこなっていた。 98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。 2008年6月取締役CTOを退任し一プログラマとなった。
みたのブログ: Bisection searches
あるプログラムをバージョンアップすると、それまでちゃんと動いていたのに何か動作がおかしくなってしまうということはよくあると思います。 再現性のあるバグがあって、ちゃんと動作するバージョンと、そうでないバージョンがあってそのプログラムが適切にバージョン管理されていれば、ほとんどの場合バージョン間の二分探索することによって、そのバグがいつどの変更によって引き起こされるようになったか特定することができます。 Linux kernel は、 v2.6.12 ぐらいから git というリビジョン管理システムで管理されていて、 上記のようなバグの二分探索は git-bisect というツールでおこなえます。 http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html たとえば v2.6.16 ではちゃんと動いていたけど v2.6.17
ユメのチカラ: カーネルにおけるリグレッションの特定
例えば、2.6.17では問題ないのに、2.6.18だとなぜか問題が発生するとする。linux kernel は git というソースコード管理システムによって、全ての変更が管理されているので、その機能を利用して問題を発生させたパッチを特定する事ができる。 基本的な考え方は、コミットしたパッチを問題を発生させた組と、発生しない組にわけていって、問題を絞り込む。2分検索だ。 例えば、1000個分の変更がコミットされていたとする。これを問題が発生しない状況から一個一個順ぐりにあてていき、問題が発生したら、最後にあてたパッチが原因だということがわかる。この順ぐりにあてていく場合、最悪1000回試行錯誤しなくてはいけない。 2分検索の場合、まづ、500個分あてた状態で(gitで簡単にそのような状況をつくれる)試験をし、仮に問題が発生しなければ、残りの500個に問題があるので、さらに、その半分250個
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
