このページは機械翻訳したものです。

5.9.1.4 gdb での mysqld のデバッグ

ほとんどのシステムでは、mysqld がクラッシュした場合に詳細な情報を取得するために、gdb からも mysqld を起動できます。

Linux の一部の古い gdb バージョンでは、mysqld のスレッドをデバッグできるようにするには、run --one-thread を使用する必要があります。 この場合、一度にアクティブにできるのは 1 つのスレッドのみです。

gdb で mysqld を実行すると、NPTL スレッド (Linux の新しいスレッドライブラリ) に起因する問題が発生することがあります。 次のような現象が発生します。

• mysqld が起動中 (「接続準備完了」と出力される前) にハングアップする。

• mysqld が pthread_mutex_lock() または pthread_mutex_unlock() の呼び出し中にクラッシュする。

この場合、gdb を起動する前に、シェルで次の環境変数を設定してください。

LD_ASSUME_KERNEL=2.4.1
export LD_ASSUME_KERNEL

gdb で mysqld を実行するときは、--skip-stack-trace を使用してスタックトレースを無効にし、gdb 内でセグメンテーション違反を捕捉できるようにする必要があります。

mysqld の --gdb オプションを使用して、SIGINT の割込みハンドラ (^C でブレークポイントを設定するために mysqld を停止するために必要) をインストールし、スタックトレースおよびコアファイル処理を無効にします。

gdb では古いスレッドのメモリーが解放されないため、すべての時間に多数の新しい接続を行う場合、gdb で MySQL をデバッグすることは非常に困難です。 この問題を回避するには、thread_cache_size を max_connections + 1 に等しい値に設定して mysqld を起動します。 ほとんどの場合、--thread_cache_size=5' を使用するだけでもかなり改善されます。

SIGSEGV シグナルが発生して mysqld が異常終了したときに Linux でコアダンプを取得する場合は、--core-file オプションを指定して mysqld を起動します。 このコアファイルは、mysqld が異常終了した理由を見つけるために役立つことがあるバックトレースを作成するために使用できます。

shell> gdb mysqld core
gdb>   backtrace full
gdb>   quit

セクションB.3.3.3「MySQL が繰り返しクラッシュする場合の対処方法」を参照してください。

Linux で gdb を使用している場合は、次の情報を含む .gdb ファイルを現在のディレクトリにインストールする必要があります:

set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint

mysqld をデバッグする方法の例を次に示します。

shell> gdb /usr/local/libexec/mysqld
gdb> run
...
backtrace full # Do this when mysqld crashes

上記の出力をバグレポートに含め、セクション1.6「質問またはバグをレポートする方法」の手順を使用してバグレポートを提出できます。

mysqld がハングアップした場合は、strace、/usr/proc/bin/pstack などのシステムツールを使用して、mysqld がハングアップした場所を調査できます。

strace /tmp/log libexec/mysqld

Perl の DBI インタフェースを使用している場合は、trace メソッドを使用するか、DBI_TRACE 環境変数を設定することによって、デバッグ情報をオンにできます。