| Bug #26000 | SHOW SLAVE STATUS can crash mysqld during shutdown process | ||
|---|---|---|---|
| Submitted: | 1 Feb 2007 3:50 | Modified: | 28 Nov 2007 19:08 |
| Reporter: | Sean Pringle | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 4.0.27,5.0.36,5.1.14,4.1.21 | OS: | Any |
| Assigned to: | Andrei Elkin | CPU Architecture: | Any |
| Tags: | bfsm_2007_02_15 | ||
[1 Feb 2007 7:19]
MySQL Verification Team
5.0.36 crashed also. At the time of issuing 'mysqladmin shutdown', i was running 1500 'show slave status' per second.
Stack trace from mysql windows build shows that the st_master_info * mi=0x00000000 is NULL indeed. A crash happens here:
if (mi->host[0]) <-------- here
{
DBUG_PRINT("info",("host is set: '%s'", mi->host));
String *packet= &thd->packet;
protocol->prepare_for_resend();
[1 Feb 2007 7:21]
MySQL Verification Team
complete stack trace
Attachment: windows_5.0.36_debug_stack.txt (text/plain), 908 bytes.
[12 Sep 2007 9:13]
Bugs System
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/34078 ChangeSet@1.2571, 2007-09-12 12:13:00+03:00, aelkin@koti.dsl.inet.fi +1 -0 Bug #26000 SHOW SLAVE STATUS can crash mysqld during shutdown process active_mi has been reset at the time of quering with SHOW SLAVE STATUS. The handler reads members of the struct that segfaults. Fixed with ingoring show_master_info() execution if active_mi is reset. Notice, there are more analogical cases in the code which require a similar treatment (to be reported as a bug separately).
[26 Sep 2007 20:00]
Bugs System
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/34573 ChangeSet@1.2526, 2007-09-26 21:59:17+02:00, aelkin@koti.dsl.inet.fi +1 -0 Bug #26000 SHOW SLAVE STATUS can crash mysqld during shutdown process active_mi has been reset (shutdown) at the time of quering with SHOW SLAVE STATUS so that at handling of SHOW an attempt to read its members segfaults. Fixed with checking the value of active_mi before to call show_master_info() Merely send_ok() is invoked when active_mi does not exist. A test can not be easiely written. Notice, there are more analogical cases in the code which require a similar treatment (to be reported as a bug separately).
[26 Sep 2007 20:03]
Andrei Elkin
The latest patch is for 5.0.
[27 Nov 2007 10:49]
Bugs System
Pushed into 5.0.54
[27 Nov 2007 10:50]
Bugs System
Pushed into 5.1.23-rc
[27 Nov 2007 10:53]
Bugs System
Pushed into 6.0.4-alpha
[28 Nov 2007 19:08]
Jon Stephens
Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.
If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at
http://dev.mysql.com/doc/en/installing-source.html
Documented bugfix in 5.0.54, 5.1.23, 6.0.4 changelogs as:
Issuing SHOW SLAVE STATUS as was shutting down could cause a crash.
Description: A client may execute SHOW SLAVE STATUS during the mysqld shutdown process, resulting in show_master_info() being called after end_slave() has already executed and left a null "active_mi" object. show_master_status() does not check active_mi. This results in segfault signal 11. While this is an unlikely combination of events, automated monitoring tools for example, can trigger the crash. Tested on 4.0.27. Unable to reproduce as yet on 5.0.32 (although 5.0.32 show_master_info() also lacks a check on active_mi; perhaps something else prevents client queries earlier in the shutdown process?) How to repeat: - Start MySQL 4.0.27 and setup for replication. - Issue repeating SHOW SLAVE STATUS queries with a client script. - Use mysqladmin to shutdown mysqld as normal. - View error log. Suggested fix: Check active_mi status at the beginning of show_master_info(). if (active_mi) { ... }