Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb


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

5.9.1.4 gdb での mysqld のデバッグ

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

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

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

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

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

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

LD_ASSUME_KERNEL=2.4.1export LD_ASSUME_KERNEL

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

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

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

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

shell> gdb mysqld coregdb>   backtrace fullgdb>   quit

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

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

set print sevenbit offhandle SIGUSR1 nostop noprinthandle SIGUSR2 nostop noprinthandle SIGWAITING nostop noprinthandle SIGLWP nostop noprinthandle SIGPIPE nostophandle SIGALRM nostophandle SIGHUP nostophandle SIGTERM nostop noprint

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

shell> gdb /usr/local/libexec/mysqldgdb> 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 環境変数を設定することによって、デバッグ情報をオンにできます。