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:
None 
Category:MySQL Server: Replication Severity:S2 (Serious)
Version:6.0 OS:Any
Assigned to: Andrei Elkin CPU Architecture:Any

[6 Jan 2009 20:06] Andrei Elkin
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.
[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.