- PR -

泥臭いデバック方法に関して

1|2 次のページへ»
投稿者投稿内容
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2004-12-22 14:42
こんにちわ。

まず私は前提として、よくあるプロファイラー系のツール使用経験は
ありません。java標準でついてるやつも使い方・見方がいまいちわか
りません。そして使う場面もなかったもので・・。

そこで質問なのですが、例えば以下のようなケース

・画面から投入されて、最終的にDBに格納される変数がある。
・事象として、画面で入力したのにDBにはnullとなって入ってしまった。
・同一の業務を行っているのに起こる時と起こらない時がある。

こういうケースにおけるデバック方法に関してなのですが、

・単純に該当変数のDBまでのルートにデバックプリント文を入れて
　再現を待ち、再現したらログから解析

という方法しか思い浮かびません。

非常に泥くさいわけですが、このようなケースでプロファイラー系の
ツールは役に立つのでしょうか？

また、皆さんはこのような時どのように解析されてますか？

参考にお聞かせください。


##誤字だらけ修正

[ メッセージ編集済み 編集者: (株)ぽち 編集日時 2004-12-22 14:47 ]
n.w
大ベテラン
会議室デビュー日: 2003/07/15
投稿数: 126
お住まい・勤務地: 神奈川
投稿日時: 2004-12-22 15:59
eclipse 使用時はデバッグモードで起動し、
ブレークポイントを貼ってあとは値が格納されるという変数を
ステップインなどしながらひたすら監視しますが、
環境や状況によって使えない場合は同じくひたすら泥臭いことしてます

引用:

このようなケースでプロファイラー系の
ツールは役に立つのでしょうか？

状況にもよりますが個人的には役立つと思います。
1行ずつ進めて実行させられる上、移動する毎に現在データが
どのようになっているかが更新されていくのでかなり便利かと
yuu
大ベテラン
会議室デビュー日: 2002/06/12
投稿数: 152
お住まい・勤務地: 美味しいケーキ店のそば
投稿日時: 2004-12-22 16:46
ぽちさん、こんにちは。
私もログ解析派(?) です。

私の場合、システムを作る時点で、実行したSQL文、ユザーからの入力値
(WebアプリならPost/Get された値など)や大体の処理の流れがわかるようなログ書くフレームワーク的なものを容易しておき、開発時、テスト時、テスト稼動の際はこれらのログを有効にしておきます。 これらである程度のバグの推論が出来ますので、あとは推論に基づき、各モジュールの出入り口等で問題ありそうな変数のログを取り、バグを探してます。

あとは開発・テスト環境、無心になって色々なケースを試してみるとか・・・


早くバグが見つかると良いですね
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2004-12-22 16:53
こんにちわ。

デバッガとか実は使ったことないんですよね。。
プロファイラとかも使えたらやっぱり便利そうですね。
今度触ってみようかと思います。


あと、今バグが出ているわけではなくて

私の周りで出てまして。。
そこで私にどうすればいいですかねぇ的なアドバイスを
求められてまして、私は泥臭い方法を薦めたりしたんで
すが、ふと「もっと効率的でスマートな方法」ってある
のかなぁと疑問に思って投稿してみました。
シュン
ぬし
会議室デビュー日: 2004/01/06
投稿数: 328
お住まい・勤務地: 東京都
投稿日時: 2004-12-22 20:52
高機能のデバッガが存在する実行環境(JavaとかCとか)で、かつ調査対象
のプログラムをローカルの環境で実行可能ならば、デバッガを使うのが
おすすめです。

サーバープロセスのような長期間稼動するプロセス上で、特定の変数が
想定外の状態になることでバグが起きるなら、「条件付ブレークを張っ
ておいてデバッグモード実行し、停止するまでほっとく」が最強でしょう。

ログはプログラマが「ログに出す！」と決めた変数しか監視できませんが、
デバッガによる実行時インスぺクションなら、スレッド停止時に、その
スレッドのスコープからアクセス可能な全ての変数の、その時点での状態
をすべてみることができる(プリミティブやStringなら書き換えも可能)の
で、ログ出力の書き直し→再実行を行うよりずっと効率的に解析できると
思いますよ。

実行中プロセスのリモートデバッグというのも、便利な機能ですよ。


#GDB(GNUのデバッガ)を初めて使い始めた頃の衝撃といったら…
#作業スタイルの激変でショック死寸前になりました。個人的には、プログ
#ラミングの学習過程で、言語仕様の次に覚えるのはデバッガの使い
#方じゃないかと思っています。
前川
常連さん
会議室デビュー日: 2004/04/27
投稿数: 38
お住まい・勤務地: １DK
投稿日時: 2004-12-23 00:42
引用:
引用:
このようなケースでプロファイラー系の
ツールは役に立つのでしょうか？
状況にもよりますが個人的には役立つと思います。
1行ずつ進めて実行させられる上、移動する毎に現在データが
どのようになっているかが更新されていくのでかなり便利かと
それはプロファイラではなくてデバッガですね。
プロファイラとはチューニングに役立つ情報を集める物です。デバッグに使うものではありません。

今回のぽちさんの提示されたケースでは、デバッガが使えます。
…と思いますが、ちょっと気になる表現が。
引用:
再現を待ち、再現したらログから解析
ってもしや、たまたま発生するまでひたすら叩く、という意味でしょうか。だとしたらデバッガもあまり向いているとは言えません。毎回止めてステップ実行していては効率が悪すぎるので。

ちなみに上記の方法も悪くは無いですが、Javaの達人が手配できるなら、その人にチェックリストとソースをそれぞれレビューし直してもらうのも吉です。

ちなみにちなみに、私の経験則ですが
  • チェックリストは十分な項目を作成＆消化したはず
  • なのに、動かしているとデータが突然化けてしまう事がある
という現象が起きるのはマルチスレッドが絡んでいる事が多いです。
ちいにぃ
大ベテラン
会議室デビュー日: 2002/05/28
投稿数: 244
投稿日時: 2004-12-23 00:52
自分なら、たぶん次の方法でやるでしょう。

通過点をログ(log4j)に出力するようにしておく
デバッガ（Eclipseの）を使ってブレークポイントを仕掛ける、
BugDel（Eclipseの）やAspectJ（Eclipseの）を使って変数の値を表示するように
しておく、
カバレッジツールで通過点の確認（Eclipse + clover）

もしバグ再現方法が判明したら、自動テストを書いてから上記の方法を使います。

プロファイラ（主に devPartner for Java と Eclipse+Hyades を使ってます）は
チューニングの時や所定の性能が出ないとき、リファクタリングするときしか
使ってません。

あと、ソースコードレビュー（XPのペアプログラミングができればもっと良い）や
ピアレビューを行って、バグを減らすとか。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-12-23 13:49
unibon です。こんにちわ。

引用:

(株)ぽちさんの書き込み (2004-12-22 14:42) より:
・画面から投入されて、最終的にDBに格納される変数がある。
・事象として、画面で入力したのにDBにはnullとなって入ってしまった。
・同一の業務を行っているのに起こる時と起こらない時がある。

変数が null になるかどうかを調べるのならば、
コード:
if (hoge == null) {
    // ここでモーダルダイアログを出して止まる(GUI アプリケーションなら)。
    // あるいはデバッガーでブレークポイントを設定しておく。
}

などのようにすれば、パフォーマンスを損なうことなくデバッグができます。とにかく、異常状態のときに if 文で分岐できるかできないかで、デバッグのやりやすさが格段に違いますよね。

あるいは、変数の時点では分からないが、DB の内容がおかしくなるのならば、DB に書きに行く時点で SQL 文をトレースするようにすれば良いかもしれません。DBMS のサーバー側にその機能があったり、ODBC だったらクライアント側で設定できます。JDBC をコールする時点でフックするのは割と面倒かも。PreparedStatement が実際に発行する SQL はウラワザを使えば見ることができると、どこかの掲示板で以前にみたことがあります。

なお、客先のアプリケーションにデバッガーを仕掛けるのは結構勇気(?)が要りますよね。Linux などでネイティブなアプリケーションならば、if 文でキャッチできた時点でわざと Null Pointer でアクセス違反をおこすなどして core ファイルを吐くようにしておけば、あとからそれを持ち帰って分析もできるみたいですし、Windows でもネイティブならば同様なやりかたはあるだろうと思います。しかし Java だとこれに相当するものがなさそうですよね？それともあるのかな？
しかし、こういう分析は人的なコストがバカになりません。これにコストをかけるのならば、その人員を最初からアプリケーションの開発時に割り当てておけば、そもそもバグが残る可能性も低くなるわけだし。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）