Using a stack trace
-------------------
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. Note:Error log. To get a stack trace, you
should NOT compile `mysqld' with the `-fomit-frame-pointer' option to
gcc. Note:Compiling 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:
1. Copy the above numbers to a file, for example `mysqld.stack'.
2. Make a symbol file for the `mysqld' server:
nm -n libexec/mysqld > /tmp/mysqld.sym
Note that many MySQL binary distributions comes with the above
file, named `mysqld.sym.gz'. In this case you must unpack this by
doing:
gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym
3. Execute `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 commend 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! Note:Bug reports.