Analyzing a MySQL Crash Bug via Error Logs and GDB to Locate the Fixed Issue in MySQL 8.0.20

1. Viewing the Current Error Log

In production, most runtime problems can be diagnosed by inspecting the MySQL error log; many issues are resolvable this way. When the server crashes and the log contains a message like "This could be because you hit a bug" followed by an unreadable stack trace, you must gather evidence: locate the bug, see how the vendor fixed it, and identify the version where the fix was applied.

2. Using gdb to Locate the Faulty File

Run gdb mysqld (or the relevant plugin binary) and set a breakpoint at the function name shown in the stack trace. After breaking, add the appropriate offset and set another breakpoint to pinpoint the exact source line.

The second breakpoint points to a file inside the MySQL source tree; download the matching version source package, extract it, and open pipeline_stats.h at line 410, which defines the function Pipeline_member_stats() .

3. Checking Function Changes

Navigate to the official MySQL GitHub repository ( https://github.com/mysql/mysql-server ) and search for the function name. Compare the latest 8.0 branch with the 8.0.18 release to see the modifications.

4. Reviewing Change History

Using the repository’s “Blame” view reveals that most modifications around this function are linked to Bug #30049349. The bug description explains that during group‑replication member changes, a read‑write lock was missing on certain performance‑schema tables, causing crashes. The fix was merged in MySQL 8.0.20, as confirmed by the Release Notes.

5. Conclusion

The article shows that by analyzing the error log and stack trace, you can often locate a bug that has already been fixed upstream. When encountering similar crash logs, first examine pre‑crash errors, then use gdb and source‑code comparison to verify the fix; if the bug is not yet patched, further code analysis is required.