MySQL Bugs: #31891: Meaningful stack trace

Bug #31891	Meaningful stack trace
Submitted:	26 Oct 2007 21:02	Modified:	6 Mar 2008 13:02
Reporter:	Davi Arnaut (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: General	Severity:	S4 (Feature request)
Version:	5.1	OS:	Linux
Assigned to:	Davi Arnaut	CPU Architecture:	Any

Description:
Currently, when the MySQL server crashes, the generated stack
dump is numeric and needs external tools to properly resolve
the functions names. The problem is that this is not very helpful
to someone who has a limited knowledge of debugging techniques.
Also the generated stack trace only contains the functions names
and requires special code for each platform (because of different
stack layouts).

Nowadays, newer versions of the GNU C Library provides a set of
functions to obtain and manipulate a stack traces from within the
program. On systems that use teh ELF binary format, the stack trace
will contain important informations such as the shared object where
the call was generated, an offset into the function, and the actual
return address, and on other systems, only the return address is
presented -- which equals the current MySQL stack trace. Currently,
the library generates meaningful stack traces on the following
platforms: i386, x86_64, powerpc, ia64, alpha and s390. Having
the function name also makes possible the name demangling of
C++ functions.

Link to the GNU C Library manual entry on the backtrace functions:

http://www.gnu.org/software/libc/manual/html_node/Backtraces.html#Backtraces

How to repeat:
See a MySQL stack trace.

Suggested fix:
Implement MySQL stacktrace using glibc's backtrace function.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/40285

ChangeSet@1.2644, 2007-12-20 15:11:16-02:00, davi@mysql.com +3 -0
  Bug#31891 Meaningful stack trace
  
  Currently, when the MySQL server crashes, the generated stack
  dump is numeric and needs external tools to properly resolve
  the functions names. The problem is that this is not very helpful
  to someone who has a limited knowledge of debugging techniques.
  Also the generated stack trace only contains the functions names
  and requires special code for each platform (because of different
  stack layouts).
  
  Nowadays, newer versions of the GNU C Library provides a set of
  functions to obtain and manipulate a stack traces from within the
  program. On systems that use teh ELF binary format, the stack trace
  will contain important informations such as the shared object where
  the call was generated, an offset into the function, and the actual
  return address, and on other systems, only the return address is
  presented -- which equals the current MySQL stack trace. Currently,
  the library generates meaningful stack traces on the following
  platforms: i386, x86_64, powerpc, ia64, alpha and s390. Having
  the function name also makes possible the name demangling of
  C++ functions.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/40442

ChangeSet@1.2644, 2007-12-27 23:21:28-02:00, davi@mysql.com +3 -0
  Bug#31891 Meaningful stack trace
  
  On crashes generate a user-friendly resolved and demangled stack
  trace when libc provides the necessary functions (newer libc on i386,
  x86_64, powerpc, ia64, alpha and s390). Otherwise print a numeric
  stack trace as before, relying on resolve_stack_dump utility.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/41635

ChangeSet@1.2516, 2008-02-04 10:05:06-02:00, davi@mysql.com +4 -0
  Bug#31891 Meaningful stack trace
  
  On crashes generate a user-friendly resolved and demangled stack
  trace when libc provides the necessary functions (newer libc on i386,
  x86_64, powerpc, ia64, alpha and s390). Otherwise print a numeric
  stack trace as before, relying on resolve_stack_dump utility.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/41905

ChangeSet@1.2524, 2008-02-07 19:58:06-02:00, davi@mysql.com +4 -0
  Bug#31891 Meaningful stack trace
  
  On crashes generate a user-friendly resolved and demangled stack
  trace when libc provides the necessary functions (newer libc on i386,
  x86_64, powerpc, ia64, alpha and s390). Otherwise print a numeric
  stack trace as before, relying on resolve_stack_dump utility.

Pushed in 5.1-runtime

Pushed into 5.1.24-rc

Pushed into 6.0.5-alpha

Documented in the 5.1.23-ndb-6.2.14, 5.1.24, and 6.0.5 changelogs as follows:

        Formerly, when the MySQL server crashed, the generated stack
        dump was numeric and required external tools to properly resolve
        the names of functions. This is not very helpful to users having
        a limited knowledge of debugging techniques. In addition, the
        generated stack trace contained only the names of functions and
        was formatted differently for each platform due to different
        stack layouts.

        Now it is possible to take advantage of newer versions of the
        GNU C Library provide a set of functions to obtain and
        manipulate stack traces from within the program. On systems that
        use the ELF binary format, the stack trace contains important
        information such as the shared object where the call was
        generated, an offset into the function, and the actual return
        address. Having the function name also makes possible the name
        demangling of C++ functions.

        The library generates meaningful stack traces on the following
        platforms: i386, x86_64, PowerPC, IA64, Alpha, and S390. On
        other platforms, a numeric stack trace is still produced, and
        the use of the resolve_stack_dump utility is still required.

Davi, thanks for the clear explanation of this feature enhancement.

Also documented in the 5.1.23-ndb-6.3.11 changelog.