Analyzing MySQL Crash Without Core Dump Using Error Log and GDB
This article explains how to investigate a MySQL crash when core dumps are disabled by extracting the crash address from the error log, obtaining the matching binary, using GDB to map the address to source code, and decoding encoded function signatures to pinpoint the underlying bug.
Problem: When MySQL crashes and core dump is not enabled, only the error log contains a stack trace. How can we extract useful information from it?
Experiment: Using the same crash scenario from the previous “09 Question”, we examine the error log to obtain the crash address 0xee36f1.
We retrieve the corresponding MySQL version package, extract it, and open the mysqld binary with GDB.
Setting a breakpoint at 0xee36f1, GDB prints the source file and line number, allowing developers to locate the code responsible for the crash.
Additional analysis of the red‑boxed information in the error log shows an encoded function signature and an offset (+0x71). Decoding the signature with c++filt reveals the function generate_new_name , indicating that the bug occurs while generating a new binlog filename.
Tip: The “function start + offset” representation points to a memory location near the function entry, but the exact instruction may not belong to the function body.
Aikesheng Open Source Community
The Aikesheng Open Source Community provides stable, enterprise‑grade MySQL open‑source tools and services, releases a premium open‑source component each year (1024), and continuously operates and maintains them.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.