使用堆栈跟踪

zhanghuiyun

使用堆栈跟踪
        在一些操作系统上，如果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  /tmp/mysqld.sym

            执行 resolve_stack_dump -s /tmp/mysqld.sym -n
            mysqld.stack.
         
            这个命令会打印出mysqld死在哪里。如果这个不能帮你找出mysqld为什么死掉，你应该生成一个缺陷报告，并在缺陷报告里包含上述命令的输出结果。
            注意，尽管在多数情况下，仅有一个堆栈跟踪不能帮助我们找出问题的原因。为了定位缺陷或找到一个大致范围，我们在大多数情况下需要知道杀掉mysqld的查询，并最好知道一个测试案例
                        ，以便我们能重复问题！请参阅
1.7.1.3节，“如何报告缺陷和问题”
。
         
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/74118/showart_1300635.html