在一些操作系统上，如果mysqld意外死掉，错误日志包含一个堆栈跟踪。你可以用它来找出mysqld 在哪里（也许可能找出为什么）死掉。请参阅5.11.1节，“错误日志”。要获得堆栈跟踪，你不能用-fomit-frame-pointer 选项编译mysqld 为gcc。 请参阅E.1.1节，“针对调试编译MySQL”。
如果错误文件包含类似下面的一些内容：
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
你可以使用如下步骤找出mysqld在什么地方出现问题：
复制前面的数字到一个文件，如mysqld.stack。
为 mysqld 服务器生成符号文件：
nm -n libexec/mysqld > /tmp/mysqld.sym
注意，多数MySQL二进制发布包（"debug" 软件包，包含这些信息的地方就在二进制发布包本身之内）带上述文件，在其中这些文件名为mysqld.sym.gz。在这种情况下，你可以简单地解压缩它：
gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym
执行 resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack.
这个命令会打印出mysqld死在哪里。如果这个不能帮你找出mysqld为什么死掉，你应该生成一个缺陷报告，并在缺陷报告里包含上述命令的输出结果。
注意，尽管在多数情况下，仅有一个堆栈跟踪不能帮助我们找出问题的原因。为了定位缺陷或找到一个大致范围，我们在大多数情况下需要知道杀掉mysqld的查询，并最好知道一个测试案例 ，以便我们能重复问题！请参阅1.7.1.3节，“如何报告缺陷和问题”。
