2017-04-16 16 views
0

私は現在、セグメンテーションフォルトで突然クラッシュし、コアファイルをダンプしたファイルマネージャプログラムを実行しています。だから私はコアファイルをデバッグするためにgdbを使いました:gdb list error "そのようなファイルやディレクトリがありません"

gdb /path/to/executable /path/to/core 

実行していたプログラムはC++で書かれています。私は、GDBを実行し、「リスト」を使用してソース行を印刷しようとしたとき、私は次のエラーを得た:

(gdb) bt 
#0 0x0000000000554286 in 
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&)() 
#1 0x00000000005ab2e8 in 
MyGenericDirCtrl::OnFileWatcherEvent(wxFileSystemWatcherEvent&)() 

(gdb) f 0 
#0 0x0000000000554286 in 
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&)() 
(gdb) l 
1 /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory. 

はなぜgdbがこの「/build/glib2.0-prJhLS/glib2.0-2.48と言っています.2 /./ glib/gmain.c:そのようなファイルやディレクトリはありません。 "私はgdbを使ってデバッグした他のいくつかのプログラムでこの問題にぶつかりません。

使用されるオペレーティングシステムは、Oracle仮想ボックスで動作するUbuntu 16.04です。私はgdbシンボルが読み込まれていない可能性があります。なぜ私は "-g"オプションを使ってプログラムをコンパイルしたのか分かりません。私は実際にコードがgdbでクラッシュするソース行を知る必要があります。

提案がありますか?

EDIT:雇われたロシアからの提案後に変更

私は「-g」オプションを使用して私のメインをコンパイルし、それがそうするとき、明らかに「-g」を使用してコンパイルされていないオブジェクトファイルを「既存」にリンクされましたコアがダンプされましたが、私はこれらのファイルのソースを見ることができませんでした。そこで私は先に進み、 "-g"オプションを付けてファイルを再コンパイルし、コアダンプを再現しました。私は現在、ソースラインを表示することができます。

答えて

1

Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory."

あなた本当には、あなたのシステム上のファイルを持っていないので。しかし、これはあなたの実際の問題には関係ありません。 無関係ある

The operating system used is Ubuntu 16.04

I think may be the gdb symbols were not loaded

GDB はglibのためではなく、あなたのメインの実行のための負荷デバッグシンボルをしました。

I'm not sure why since I compiled the program using the "-g" option.

プログラムを間違って作成する方法はたくさんあります。あなたはコンパイルとリンクの線を表示していないので、あなたがどのようにしっかりとねじ込んだかを正確に伝えることはできません。

一般的な方法のいくつかは:

  1. あなたのリンク行に「浮遊」-sまたは-Wl,-sを持っている(これは、結果のバイナリからデバッグ情報をストリップ)。
  2. あなたのmain.cをコンパイルするときに-gを持っていますが、MyFSEventManager::AddEvent()

P.S.を定義されているソースをコンパイルしていないとき

(gdb) bt

btコマンドからの出力は完全ではありません。出力の一部を削除すると、がより堅くなります。

+0

bt出力には68個のトレースがあります。ここにそれらをすべて貼り付けるのは面倒で、すべてを混乱させるでしょう。だから私はそれらを投稿しませんでした。 makeファイルをチェックして、-sまたは-Wl、-sオプションが誤って使用されているかどうかを確認してみましょう。 – paratrooper

+0

@paratrooper "There are 68 ..." - 実際にはかなり関連性があります(スタックオーバーフローがあるかもしれません)。私のポイントは、情報を省略することによって、あなたを助けることをより困難にすることです。 –

+0

上記の内容に基づいて、私はmakeファイルとBoomをクロスチェックしました。あなたは絶対に正しいです。 "-g"オプションを使用して私のメインをコンパイルし、 "-g"を使ってコンパイルされていない "existing"オブジェクトファイルにリンクしていたので、コアがダンプされたときにこれらのファイルのソースを見ることができませんでした。そこで私は先に進み、 "-g"オプションを付けてファイルを再コンパイルし、コアダンプを再現しました。私は現在、ソースラインを表示することができます。私はあなたの答えを受け入れています – paratrooper

関連する問題