LL脳な人でもこれぐらいは覚えておくとうれしいgdbのつかいかた。または猫でもわかるgdb講座 LLつかってても「ばすえらーになるー」っていう状況ってたまにあるわけですが、LL しか普段つかわないゆとりは、ここでお手あげになってしまったりすることがままあります。 で、「ばすえらーになるんですが」ってときの最低限これだけはやってみたらどうか、という話。「えー、わたし gdb とかわかんないしー」とかいってる人でもこれぐらいならできるんじゃないかなーっと。 perl t/00_load.tというコマンドで segv するという場合、gdb をつかって % gdb --args perl t/00_load.tとうつ。 すると、以下のようにプロンプトがでるので、"run" とうつ。これでスクリプトがはしりはじめる。 % gdb --args perl t/00_load.t GNU gdb (G
死んだプロセス (あるいは kill したプロセス) の core イメージから自動的にスタックトレースを収集するデーモンを書いたので、これをセットアップしてサーバにインストールしとくといいかもです (kaztools/bt_cores at master · kazuho/kaztools · GitHub)。Linux のみ対応*1。使い方は bt_cores --help とするか、perl Makefile.PL && make install して man bt_cores。 具体的にいうと、Q4M とか Incline とか kazuho product が落ちたり固まったりしたらスタックトレース送ってくれると、私がうれしいです (古いバージョンのスタックトレースだととても悲しいです)。コアファイルは内部データがいろいろ入ってるから外部の人には見せられないけど、スタックトレース
バグ修正はプログラマの仕事の一つですが、このうちのかなりの時間は問題を再現することに費やされます。 症状からバグの全容が推察できる時もあるのですが、多くの場合には、手元で問題を再現し、更なるデータを集めることによって始めてバグが理解されるからです。しかし、環境に依存する問題などは再現が難しい場合もあります。どうしたらよいでしょうか。 ロギングというのがよく行われる解決・予防策ですが、「デバッガを走らせて変数xの値を教えてくれればいいのに！」と思った事があるのは私だけではないと思います。ロギングと異なり、デバッガは予めプログラムに障害発生を予期するコードを埋め込んでおく必要はありません。また、呼び出し元のローカル変数をアクセスしたり、任意の式を評価したり、あるいは変数の値を変更することもできてしまいます。当たり前ですが、障害分析ツールとしてはデバッガはずっと強力だからです。 ではなぜユーザー
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
どこでみたかわすれたけど : を使う方法。 #!/bin/sh [ "$VERBOSE" = '1' ] && VECHO='echo VERBO:' || VECHO=: [ "$DEBUG" = '1' ] && { VECHO='echo VERBO:'; DECHO='echo DEBUG:'; } || DECHO=: echo go ahead! $VECHO ugoiteru $$ now! $DECHO mou owari exit実行例 $ ~/t.sh go ahead! $ env VERBOSE=1 ~/t.sh go ahead! VERBO: ugoiteru 23055 now! $ env DEBUG=1 ~/t.sh go ahead! VERBO: ugoiteru 23115 now! DEBUG: mou owari
Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 p ご存じの人も多い Kernel#p メソッド。これを使うとオブジェクトの内容を見やすい形で出力してくれます。 >> p ({:foobar => :baz}) {:foobar=>:baz}Object#inspect を使うと、p で出力するときと同じ文字列を String として取得できます。 >> puts ({:foobar => :baz}).inspect {:foobar=>:baz}初心者の頃この p での出力を使う方法がわからなくて困った記憶が…。 pp pp というライブラリを使うと、p より、より見やすい形式で出力してくれます。たとえば >> a = Array.new(10) { {:foobar => :
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
