On some operating systems, the error log will contain a stack trace if
mysqld
dies unexpectedly. You can use this to find out where (and
maybe why) mysqld
died. See section 4.9.1 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 Attemping 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:
mysqld
server:
nm -n libexec/mysqld > /tmp/mysqld.symNote that most MySQL binary distributions (except for the "debug" packages, where this information is included inside of the binaries themselves) already 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
resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack
.
This will print 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 will 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.7.1.3 How to Report Bugs or Problems.