E.1.4. Using a Stack Trace
On some operating systems, the error log contains a stack trace
if mysqld dies unexpectedly. You can use this
to find out where (and maybe why) mysqld
died. See Section 5.11.2, “The Error Log”. To get a stack trace, you
must not compile mysqld with the
-fomit-frame-pointer option to gcc. See
Section E.1.1, “Compiling MySQL for Debugging”.
If the error file contains something like the following:
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack range sanity check, ok, backtrace follows
0x40077552
0x81281a0
0x8128f47
0x8127be0
0x8127995
0x8104947
0x80ff28f
0x810131b
0x80ee4bc
0x80c3c91
0x80c6b43
0x80c1fd9
0x80c1686
you can find where mysqld died by doing the
following:
Copy the preceding numbers to a file, for example
mysqld.stack.
-
Make a symbol file for the mysqld server:
nm -n libexec/mysqld > /tmp/mysqld.sym
Note that most MySQL binary distributions (except for the
"debug" packages, where this information is included inside
of the binaries themselves) ship with the above file, named
mysqld.sym.gz. In this case, you can
simply unpack it by doing:
gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym
-
Execute resolve_stack_dump -s /tmp/mysqld.sym -n
mysqld.stack.
This prints out where mysqld died. If
this doesn't help you find out why mysqld
died, you should make a bug report and include the output
from the above command with the bug report.
Note however that in most cases it does not help us to just
have a stack trace to find the reason for the problem. To be
able to locate the bug or provide a workaround, we would in
most cases need to know the query that killed
mysqld and preferable a test case so that
we can repeat the problem! See
Section 1.8, “How to Report Bugs or Problems”.
