Come ottenere uno stack trace completo di mysqld (il server MariaDB)
Contents
- Compilare MariaDB per il debug
- Aggiornare il file my.cnf
- Rimpiazzare temporaneamente il mysqld standard con la versione di debug
- Ripristinare la versione originale di mysqld
- Using the core file
- What to do if you don't get a core file when mysqld crashes
- Running a copy of the database directory
- Reporting the problem
Se si verifica un errore critico di mysqld
(core dump), per default scriverà uno stack trace nel file 'nomehost'.err
nella directory dei database. Tuttavia vi sono casi in cui questo non è sufficiente per individuare il problema.
Le seguenti istruzioni spiegano come ottenere uno stack trace completo su Unix.
Per capire dov'è il problema, uno sviluppatore di MariaDB necessita di una o più fra le seguenti informazioni:
- Uno stack trace completo (che si può ottenere solo usando un binario compilato per il debug)
- Un file core (immagine del programma crashato)
- Un mysqld compilato per il debug.
Ecco come creare tutto questo:
- Si scarichi un file tar.gz dei sorgenti
(like
mariadb-5.2.9.tar.gz
). - Lo si compili per il debug
- Si aggiorni il file my.cnf per ottenere un
core
e uno stack trace. - Si installi il mysqld di debug al posto di quello regolare.
- Si esegua la versione di debug fino a quando non avviene un nuovo crash.
- Si ripristini la vecchia versione di
mysqld
.
Compilare MariaDB per il debug
Segue un esempio di come compilare MariaDB per il debug nella propria home directory con MariaDB 5.2.9:
cd ~ mkdir mariadb cd mariadb tar xvf mariadb-5.2.9.tar.gz ln -s mariadb-5.2.9 current cd current ./BUILD/compile-pentium64-debug-max
L'ultimo comando produce una versione di debug di sql/mysqld
. Se si ha un sistema che non sia Intel/AMD a 64 bit con Linux, si può utilizzare un diverso file BUILD/...-debug-max
. Se il comando fallisce, si provi in questo modo:
./BUILD/autorun.sh ./configure --with-debug=full -with-extra-charsets=complex \ --with-plugin-aria --with-aria-tmp-tables --without-plugin-innodb_plugin \ --with-plugins=max \ --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static make
Aggiornare il file my.cnf
Si aggiungano le righe seguenti al file ~/.my.cnf
:
[[mysqld]] --stack-trace --core-file [[mysqld-safe]] --core-file-size=unlimited
Si può lasciare anche per il futuro, non creano problemi.
Nota: Se si sta utilizzando safe_mysqld
ed eseguendo mysqld
come root
, su alcuni sistemi non verrà creato alcun file core
. La soluzione è eseguire mysqld
con un altro utente.
Rimpiazzare temporaneamente il mysqld standard con la versione di debug
Ecco come farlo su Open SuSE. Sulle altre distribuzioni di Linux, mysqld
potrebbe trovarsi in altre directory.
mysqladmin shutdown cd /usr/local/mysql/libexec mv mysqld mysqld-orig cp ~/mariadb/current/sql/mysqld mysqld-debug ln -s mysqld-debug mysqld
I comandi sopra riportati rimpiazzano mysqld
con la versione di debug, e lo fanno in un modo che rende semplicissimo il ritorno alla versione originale.
A questo punto, si avvi di nuovo mysqld con un comando come:
/etc/rc.d/mysql start
Ripristinare la versione originale di mysqld
E' possibile ripristinare il binario originale di mysqld in questo modo:
cd /usr/local/mysql/libexec rm mysqld ln -s mysqld-orig mysqld
Si noti che il binario di debug non viene cancellato: viene rimosso soltanto il sym-link, che immediatamente viene sostituito con uno che punti al binario originale. In questo modo, il binario di debug potrà essere riutilizzato in futuro.
Using the core file
If the debug version of mysqld crashes, you should now have:
- A more precise stack trace in the
'hostname'.err
file in the data directory. - A
core
orcore.
file in your data directory.##
To examine the stack trace and other information in the
gdb
debugger you can do:
cd ~/mariadb/current cp mariadb-database-directory/core* core gdb ~/mariadb/current/sql/mysqld core backtrace full
What to do if you don't get a core file when mysqld crashes
On some systems there is a limit of the size of the core file. You can check and increase the limit with:
ulimit -c ulimit -c unlimited
The above are shell limits and you should do this before you start mysqld again.
On some Linux systems the core files are disabled in the kernel. You can check this with:
sysctl -a | grep k.*core sysctl -a | grep dumpable
Ensure that fs.suid_dumpable=2
. You can set it with:
/sbin/sysctl -w fs.suid_dumpable=2
See also http://www.cyberciti.biz/tips/linux-core-dumps.html#comments
Running a copy of the database directory
If you are concerned with running the debug binary on your production database you can also copy the database to another location and use the new debug-enabled version with this. In this case you can skip the above instructions of installing MariaDB and instead run mysqld directly from the source directory.
This is useful when you know which statement crashed the server.
Just start mysqld with the option
--datadir=/copy-of-original-data-directory
Reporting the problem
Report the problem, including the stack information in the MariaDB bugs database.
For very difficult or critical errors, you should consider
sending the debug version of mysqld
and the
core
file and some information of how to contact you
in a .tar
or .zip
file to the
MariaDB developers at Monty Program Ab so they can analyze it and try to
create a fix.