| Bug #41902 | MYSQL_BIN_LOG::reset_logs() doesn't call my_error() in face of an error | ||
|---|---|---|---|
| Submitted: | 6 Jan 2009 20:06 | Modified: | 19 May 2009 11:26 |
| Reporter: | Andrei Elkin | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S2 (Serious) |
| Version: | 6.0 | OS: | Any |
| Assigned to: | Andrei Elkin | CPU Architecture: | Any |
[6 Apr 2009 10:44]
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/71436 2840 Andrei Elkin 2009-04-06 Bug#41902 MYSQL_BIN_LOG::reset_logs() doesn't call my_error() in face of an error The assert could happen because thd->stmt_da->status() did not know on the fact of an error happened. Fixed with deploying purge_error_message() in the reported error branch of reset_logs().
[9 Apr 2009 9:53]
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/71751 2840 Andrei Elkin 2009-04-09 Bug#41902 MYSQL_BIN_LOG::reset_logs() doesn't call my_error() in face of an error The assert happened because thd->stmt_da->status() reacted on the fact of a gainer error which was not prepared and sent. Fixed with deploying a part the former purge_error_message() in the reported error branch of reset_logs(). A user level error gets prepared for reporting via my_message(). Side effects: Bug#44179 appears be fixed with the current patch, at least in 6.0.
[20 Apr 2009 12:17]
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/72499 2840 Andrei Elkin 2009-04-20 Bug#41902 MYSQL_BIN_LOG::reset_logs() doesn't call my_error() in face of an error The assert happened because thd->stmt_da->status() reacted on the fact of a gained error in reset_logs() which was not prepared and therefore sent but still the fact of the error was propagated upwards to callers. Fixed with deploying a part the former purge_error_message() in the reported error branch of reset_logs(). A user level error gets prepared for reporting via my_message(). Side effects: Bug#44179 appears be fixed with the current patch, at least in 6.0.
[13 May 2009 3:31]
Bugs System
Pushed into 6.0.12-alpha (revid:alik@sun.com-20090513032549-rxa73jbxd1qv09xc) (version source revid:aelkin@mysql.com-20090429125820-vu261kl1z4z5f0iv) (merge vers: 6.0.12-alpha) (pib:6)
[13 May 2009 13:35]
Jon Stephens
Not sure I understand what the user-facing issue is in this bug, or if there is one. Can you please tell me how users would encounter this problem? Thanks!
[19 May 2009 11:26]
Jon Stephens
Documented bugfix in the 6.0.12 changelog as follows:
Executing the sequence of statements RESET SLAVE, RESET MASTER,
and FLUSH LOGS when binary log or relay log files listed in the
index file could not be located could cause the server to crash.
This could happen, for example, when these files had been
manually removed.
[3 Dec 2009 13:53]
Jon Stephens
Also documented in the 5.6.0 changelog. See BUG#48463.
[7 Mar 2010 1:50]
Paul DuBois
Moved 5.6.0 changelog entry to 5.5.3.
Description: Therefore the following execution can meet an assert in Protocol::end_statement() called at terminating stage of the query execution in dispatch_command(). The assert becomes possible because some error branches involving MYSQL_BIN_LOG::reset_logs() do not call my_ok() nor change thd->stmt_da->m_status accordingly. How to repeat: emulate an error in MYSQL_BIN_LOG::reset_logs() at the first invocation of find_log_pos(). Existing lines: if (find_log_pos(&linfo, NullS, 0)) { error=1; goto err; } will throw execution back to the caller but in the following there will be #3 0xb7c5210e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x08342822 in Protocol::end_statement (this=0x989ebbc) at protocol.cc:471 #5 0x0836eb7f in dispatch_command (command=COM_QUERY, thd=0x989e8b8, packet=0x997e7e9 "reset master", packet_length=12) at sql_parse.cc:1403 Suggested fix: call my_error() in the then-block of the if-statement of How-to-repeat code sample.