Create Symbols and Resolve Stack (MySQL)

Luke Hebert

- 2 minutes read - 284 words

When MySQL crashes, the stack dump it produces is full of raw memory addresses. Without symbol information, those addresses are nearly useless for diagnosing the root cause. The two steps below turn that opaque dump into a readable list of function names so you can pinpoint where the failure occurred.

Step 1: Extract Dynamic Symbols

Run nm against the mysqld binary to pull out its dynamic symbol table and save the output to a dated file:

nm -D -n /usr/sbin/mysqld > /root/mysqld.sym-$(date +%F)
  • -D limits the output to dynamic (exported) symbols, which is what the stack resolver needs.
  • -n sorts the symbols by address, making lookups faster.
  • The $(date +%F) suffix keeps a timestamped copy so you can match the symbols to the exact build that was running at crash time.

Step 2: Resolve the Stack Dump

Point resolve_stack_dump at the symbol file and the raw stack file, then pipe the result through c++filt to demangle C++ names:

resolve_stack_dump -s mysqld.sym-2012-07-05 -n mysqld.stack-2012-07-05 | c++filt
  • -s specifies the symbol file created in Step 1.
  • -n specifies the stack dump file (typically found in the MySQL error log or the core file).
  • c++filt converts mangled C++ identifiers like _ZN5mysql10do_commandEP3THD into something you can actually read.

Tips

  • Make sure the symbol file was generated from the same mysqld binary that produced the crash. A mismatched build will give you wrong or missing function names.
  • If you are running a debug build, you can drop the -D flag from nm to capture static symbols as well, which often yields more detailed frames.
  • Save the resolved output alongside the original stack dump so your support ticket or bug report includes both the raw and human-readable traces.