10

私の現在の問題は libwebkitgtk-3.0-0 にありますが、この問題は一般的なもので十分だと思います。

アプリケーションが Webkit コードのどこかでクラッシュしています。私の仮定は、私たちは何かばかげたことをしていて、それを知りたいと思っているということです。最も簡単なのは、ブレークポイントを設定するか、デバッグ バージョンのライブラリを使用することです。

  1. ライブラリがビルドされた正確なソース コードを取得するにはどうすればよいですか? コアをダンプした後にスタック トレースを取得していますが、gdb の行番号がコードに表示されているものと一致しないと言っています。つまり、libwebkitgtk-3.0-0 をインストールした場合、その正確なソース コードを取得したいと考えています。

  2. Webkit ライブラリのデバッグ バージョンをインストールしました。これらのデバッグ バージョンは、webkit を --enable-debug フラグでコンパイルしている場合と同じ機能を持っていますか? Webkit のデバッグ バージョンでは WEBKIT_DEBUG 環境変数に基づいてログが有効になりますが、ライブラリのデバッグ バージョンを使用しても同じログを取得できませんでした。

  3. コンパイルに成功したデバッグ バージョンの使用方法 私はなんとか自分のマシンで Webkit をコンパイルし、ロード パスなどをいじってみました。私のアプリケーションは、何をしても新しい共有ライブラリを取得しません。ユーザー エージェントの署名に基づいて判断できます。ある時点でライブラリを取得できましたが、SSL が機能しなくなりました。GtkLauncher でも同じ SSL 問題が発生します。だから私はどこかで間違っています。

ポインタをありがとう。

4

4 に答える 4

29

TL;DR: libwebkitgtk-3.0-0-dbglibwebkitgtk-3.0-0-dbg をインストールしますをインストールすると、必要なデバッグ シンボルが得られます。

##デバッグ シンボルの場合、通常はソースからインストールする必要はありません。

ご存じのとおり、自分で構築しているソフトウェアのデバッグ シンボルを取得するには、GCC を で実行できます-g

オペレーティング システムのパッケージ マネージャー (libwebkitgtk-3.0-0ここには が含まれています) を介してインストールされたソフトウェアの場合、少なくとも公式パッケージの場合、通常、デバッグ シンボルを提供するパッケージもあります。

でシンボリック スタック トレースを取得するために、プログラムまたはライブラリのデバッグ ビルドを実際に行う必要はありませんgdbgdbでは、「アドオン」デバッグ シンボルを提供するファイルもサポートしています/usr/lib/debug

質問のタグによると、Ubuntuを使用しています。-dbgUbuntu では、デバッグ シンボル パッケージはとの 2 種類で利用できます-dbgsym。にあるプログラムまたはライブラリは、 でデバッグ シンボルを取得します。/path/usr/lib/debug/path

##-dbgパッケージ

これらのパッケージは、多くの場合、実際の実行可能ファイルまたはライブラリ ファイルを提供する対応するパッケージとは異なる名前が付けられています。-dev多くの場合、パッケージ (ヘッダー ファイルを提供する) およびパッケージに似た名前が付けられ-docます。パッケージの-dbg名前に含まれるライブラリのバージョン番号は、実際のライブラリ パッケージよりも少ない場合があり、他の複数のパッケージで提供されるバイナリをカバーする場合があります。

たとえば、libgtkmm-3.0-1の対応する-dbgパッケージはlibgtkmm-3.0-dbgです。

一方、-dbgパッケージは、それが提供するシンボルを持つパッケージと同じ名前が付けられることがあります (-dbgサフィックスを除く)。たとえば、libwebkitgtk-3.0-0の対応する-dbgパッケージはlibwebkitgtk-3.0-0-dbgです。 それはあなたが望むものです。

ソフトウェアセンターにインストールするか、次を実行してインストールできます。

sudo apt-get update && sudo apt-get install libwebkitgtk-3.0-0-dbg

が提供するライブラリにリンクするプログラムをデバッグするとlibwebkitgtk-3.0-0gdbが提供するファイルからシンボルが自動的に読み込まれlibwebkitgtk-3.0-0-dbgます。

##-dbgsymパッケージ

公式パッケージによって提供されるバイナリ実行可能ファイルには、どの-dbgパッケージにもシンボルが含まれていないことがあります。これが発生した場合、通常は-dbgsymパッケージをインストールできます。

パッケージとは異なり-dbg-dbgsymパッケージ:

  • プログラムまたはライブラリ自体を提供するパッケージのX-dbgsym場所は、ほとんどの場合、単純に (そして予想どおり) 名前が付けられています。X
  • 対応するプログラム/ライブラリ パッケージおよびパッケージを提供するものと同じソフトウェア ソースではなく、特別なソフトウェア ソース (リポジトリ) によって提供され-dbgます。

パッケージは別々のリポジトリにあるため-dbgsym、これらのリポジトリを有効にする必要があります。彼らの DEB 行は次のとおりです。

deb http://ddebs.ubuntu.com YOUR_RELEASE main restricted universe multiverse
deb http://ddebs.ubuntu.com YOUR_RELEASE-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com YOUR_RELEASE-security main restricted universe multiverse
deb http://ddebs.ubuntu.com YOUR_RELEASE-proposed main restricted universe multiverse

それらを有効にするには、次のコマンドを実行できます ( 「Ubuntu ドキュメント wiki への貢献者」セクション 2によるDebuggingProgramCrashから適応):

echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-security main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse
" | sudo tee -a /etc/apt/sources.list.d/ddebs.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01
sudo apt-get update

開発リリース (アルファ版またはベータ版) を使用している場合は、イタリック体の行を省略してください。ただし、安定したリリースを引き続き使用する場合は、必ず追加してください。

これらのコマンドは、次の 3 つのことを行います。

  1. ファイル/etc/apt/sources.list.d/ddebs.list(DEB 行を含む) を作成します。
  2. これらのリポジトリの署名キーをインポートします。
  3. どのパッケージとバージョンがどこからインストールできるかについて、システムの情報を更新します。

-dbgsymしたがって、提供されたシンボルの代わりに-dbg提供されたシンボルを使用したい場合、 の-dbgsymパッケージlibwebkitgtk-3.0-0は (上記の単純な命名規則に従って)libwebkitgtk-3.0-0-dbgsymです。

-dbgとパッケージの両方を-dbgsym同じシステムにインストールできますが、それらが同じファイルのシンボルを提供する場合はインストールできません。それでlibwebkitgtk-3.0-0-dbglibwebkitgtk-3.0-0-dbgsym互いに対立します。両方を (同時に) インストールすることはできません。

##シンボルの使用

ほとんどの Unix ライクな OS では、デバッガーはインストールされているシンボルを自動的に探します。Ubuntu も例外ではありません。Ubuntu では、 でgdb自動的に検索されます/usr/lib/debug。したがって、特別なことをする必要はありません。

ただし、gdb特定のデバッグ シンボル ファイルを読み込むように指示する必要がある場合は、フラグを使用します。詳細については、GNU のマニュアルgdb(1)を参照してください。-s file

于 2013-01-20T02:14:18.900 に答える
4

1) パッケージを介してインストールしたライブラリを掘り下げる必要がある場合、最初に行うことは、ソースからインストールすることです。つまり、configur/make/make install です。私は通常、ソース コードを /usr/local/src に置き、それを /usr/local にインストールします。これは、私の意見では、ソースを持っている正確なコードを実行する最も信頼できる方法です。

3)

コンパイルに成功したデバッグ バージョンの使用方法

これは、私が上で説明したことをしたように聞こえます。あなたがしなければならないことは、あなたのソフトウェアがあなたのコンパイルされた、デバッグ可能なライブラリをホストしているインクルードとリンクのディレクトリを使用していることを確認することです。-I/usr/local/include および -L /usr/local/lib フラグが設定され、/usr/include および /usr/lib の前に来ることを確認することを意味します。

ライブラリのバイナリ バージョンを ubuntu インストールから削除し、ビルドしてインストールしたバージョンがハード ディスク上に存在する唯一のバージョンであることを確認することで、さらに確実にすることができます。このようにして、そのライブラリを使用するようにアプリを構成できたことを確実に知ることができます。そうしないと、新しいライブラリを使用しているのか古いライブラリを使用しているのかを常に疑問に思う代わりに、失敗するだけです。

2) 通常、はい。ただし、ライブラリの作成方法と、ubuntu パッケージャーが何を決定したかによって異なります。

ローカルにビルドされたライブラリを使用してプログラムをコンパイルしたら、最初にまったく同じエラーが発生するかどうかを確認します。そうでない場合、それもデータポイントです。前回ubuntuがライブラリをパッケージ化してから問題が修正された可能性があります。ライブラリが適切にパッケージ化されていない可能性があり、それが問題です。ubuntuパッケージャーがライブラリを特定の方法で構成して機能するように構成し、同じことをしなかったため、新しいエラーが発生することさえあります。とにかく興味深いリードが得られます。

幸運を

于 2013-01-15T19:43:05.990 に答える
3

@Eliahの回答は、便利な方法でシンボルを取得する方法を示しています。

「正確なソース コードを入手するにはどうすればよいか」という疑問が残ります。.

パス参照がルートではなくサブディレクトリからのものであることを理解する必要があるeglibcのようなパッケージである場合は、apt-get source <pkgname>手動で gdb に伝える必要があります。 dir <path-to-wherever-I-put-the-source>nss

RHEL では、たとえばyum install --enable-repo rhel-debuginfo libX11-debuginfo( yum install libX11-debuginfoCentOS 7 だけで) 簡単に実行でき、余分な操作をすることなく、gdb で完全なシンボルとソースをすぐに取得できます。私はまだUbuntuでその便利さを探しています。

于 2013-05-09T15:50:50.463 に答える