多くのシステムでは、mysqld がクラッシュした際に、mysqld を gdb から起動することで、より多くの情報を取得することもできます。

Linux で使用される旧バージョンの gdb の一部では、mysqld スレッドをデバッグする際に run --one-thread を使用しなければなりません。この場合、一度にアクティブにできるスレッドは 1 つだけです。速やかに gdb 5.1 にアップグレードすることをお奨めします。このバージョンでは、スレッドデバッグの処理が大幅に改善されるからです。

gdb で mysqld を実行する場合、スタックトレースを --skip-stack-trace で無効化し、gdb 内部で segfault を捕捉できるようにする必要があります。

MySQL 4.0.14 以降では、mysqld に対して --gdb オプションを使用してください。このオプションを使用すると、SIGINT（mysqld を ^C で終了し、ブレークポイントを設定するために必要）の割り込みハンドラがインストールされ、スタックトレースとコアファイル処理が無効になります。

gdb で MySQL をデバッグするのが非常に困難な場合があります。たとえば、古いスレッドに対するメモリが gdb によって解放されず、デバッグ中に大量の新規接続を連続して確立しなければならない場合です。この問題を回避するには、-O thread_cache_size= 'max_connections +1' を指定して mysqld を起動します。多くの場合、-O thread_cache_size=5' を指定するだけで状況は大幅に改善します。

SIGSEGV シグナルで mysqld がクラッシュした場合、Linux 上でコアダンプを取得するには、--core-file オプションを指定して mysqld を起動します。 このコアファイルを使用してバックトレースを作成し、mysqld がクラッシュした理由を特定することもできます。

shell> gdb mysqld core
gdb>   backtrace full
gdb>   exit

See 項A.4.1. 「MySQL が何度もクラッシュする場合に行うこと」。

gdb 4.17.x 以降を Linux で使用している場合、.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

gdb でスレッドのデバッグに問題が起きた場合、gdb 5.x をダウンロードして代用してみてください。gdb の新規バージョンでは、スレッドの処理が飛躍的に改善されています。

以下の例は、mysqld をデバッグする方法を示します。

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

mysqlbug で生成された上記の出力内容をメールに取り込み、通常の MySQL メーリングリスト宛てに送信してください。 See 項1.7.1.1. 「MySQL メーリングリスト」。

mysqld がハングした場合、strace や /usr/proc/bin/pstack のようなシステムツールを使用し、mysqld がハングした場所を調べることができます。

strace /tmp/log libexec/mysqld

Perl DBI インタフェースを使用している場合、デバッグ情報を有効にするには、trace メソッドを使用するか DBI_TRACE 環境変数を設定します。 See 項11.5.2. 「DBI インタフェース」。