かわいそうな質問を見かけました。
gdbデバッガって？
http://oshiete1.goo.ne.jp/qa103304.html
「gdbデバッガでスタックトレースを解析して、どこでアプリケーションが落ちているか解析してください。」
と言われました。
はっきり言って、何を言ってるのか全然分かりません・・・
プログラム開発はしたことが無いので、デバッグとかも全然わかりません。
新人イジメの一環か何かなんでしょうかネ。
それにしても回答もいい加減ですネぇ。
実行時に落ちたアプリの解析なんて、学校出たての新入社員か、配属されたばっかりの派遣社員のお仕事ですよ。
だって、UNIXやLinuxでコアファイルがあるなら、
$ gdb -c core
としてgdbを起動して、バカの一つ覚えで、
$ bt
とするだけで、バックトレース、つまりスタックトレースが表示され、どこで落ちているか解析完了ですから。
これは、クラッシュダンプ解析のキホンであり入門であるとどこかで習いました。
前提としては、
- 実行ファイルがあること
- コアダンプがあること
- -g付きでコンパイルされた実行イメージであること*1
- 実行ファイルに対応したgdbがあること(arch対応)
などが必要です。
ゆめゆめgdbから実行ファイルを起動して、ブレークポイントをしかけてどうのこうの、なんて誰も期待しませんよね。
でもgdb -c coreするだけなら、プログラム経験なんて一切不要です。5分あれば教えられます。
次に表示された関数名からソースを探すgrepのやり方エディタの使い方、該当バージョンのソースの取り出し方で構成管理について学ぶ・・・・
おそらく、ここから原因解析作業をエントリするのが王道であって、プログラムの組み方を覚えないと解析なんてできないなどと考えているプログラマはちょっと考えを改めるのが良いと思います。その考えが、人材の硬直化の原因の一部であったりしますので。また原因解析についての自分の無知にもう少し向き合ってください。
自動車工場の作業者は、自動車修理はできません。当たり前のことです。ですが一般的なプログラマやシステムエンジニアはそれと同じような勘違いをしています。
（補足）
ここで挙げたのはUNIX/Linux+gdbの組み合わせでの手順ですが、他の環境でも似たような手順や環境が作りこまれています。
作りこんでない人は猛省すべきです。
なのでひとつやり方を知れば他のやり方はちょっと応用するだけのことです。
コールスタックだったり、スタックダンプだったり、トレースログだったり名前もいろいろあるでしょう。
とにかく軽自動車が運転できるならBMWも運転できるというわけです。ダンプは無理ですが。
コメント