DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH
 

(mysql.info.gz) Using gdb on mysqld

Info Catalog (mysql.info.gz) Making trace files (mysql.info.gz) Debugging server (mysql.info.gz) Using stack trace
 
 E.1.3 Debugging `mysqld' under `gdb'
 ------------------------------------
 
 On most systems you can also start `mysqld' from `gdb' to get more
 information if `mysqld' crashes.
 
 With some older `gdb' versions on Linux you must use `run --one-thread'
 if you want to be able to debug `mysqld' threads.  In this case, you
 can only have one thread active at a time.  We recommend you to upgrade
 to gdb 5.1 ASAP as thread debugging works much better with this version!
 
 NTPL threads (the new thread library on Linux) may cause problems while
 running `mysqld' under `gdb'. Some symptoms are:
 
    * `mysqld' hangs during startup (before it writes  `ready for
      connections').
 
    * `mysqld' crashes during a `pthread_mutex_lock()' or
      `pthread_mutex_unlock()' call.
 
 In this case you should set the following environment variable in the
 shell before starting `gdb':
 
      LD_ASSUME_KERNEL=2.4.1
      export LD_ASSUME_KERNEL
 
 When running `mysqld' under `gdb', you should disable the stack trace
 with `--skip-stack-trace' to be able to catch segfaults within `gdb'.
 
 In MySQL 4.0.14 and above you should use the `--gdb' option to mysqld.
 This will install an interrupt handler for `SIGINT' (needed to stop
 `mysqld' with `^C' to set breakpoints) and disable stack tracing and
 core file handling.
 
 It's very hard to debug MySQL under `gdb' if you do a lot of new
 connections the whole time as `gdb' doesn't free the memory for old
 threads.  You can avoid this problem by starting `mysqld' with `-O
 thread_cache_size= 'max_connections +1''.  In most cases just using `-O
 thread_cache_size=5'' will help a lot!
 
 If you want to get a core dump on Linux if `mysqld' dies with a SIGSEGV
 signal, you can start `mysqld' with the `--core-file' option.  This
 core file can be used to make a backtrace that may help you find out
 why `mysqld' died:
 
      shell> gdb mysqld core
      gdb>   backtrace full
      gdb>   exit
 
  Crashing.
 
 If you are using `gdb' 4.17.x or above on Linux, you should install a
 `.gdb' file, with the following information, in your current directory:
 
      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
 
 If you have problems debugging threads with `gdb', you should download
 gdb 5.x and try this instead. The new `gdb' version has very improved
 thread handling!
 
 Here is an example how to debug mysqld:
 
      shell> gdb /usr/local/libexec/mysqld
      gdb> run
      ...
      backtrace full # Do this when mysqld crashes
 
 Include the above output in a mail generated with `mysqlbug' and mail
 this to the general MySQL mailing list.   Mailing-list.
 
 If `mysqld' hangs you can try to use some system tools like `strace' or
 `/usr/proc/bin/pstack' to examine where `mysqld' has hung.
 
      strace /tmp/log libexec/mysqld
 
 If you are using the Perl `DBI' interface, you can turn on debugging
 information by using the `trace' method or by setting the `DBI_TRACE'
 environment variable.
 
Info Catalog (mysql.info.gz) Making trace files (mysql.info.gz) Debugging server (mysql.info.gz) Using stack trace
automatically generated byinfo2html