Bug #49765 Assertion in Diagnostics_area::set_eof_status on RESTORE
Submitted: 17 Dec 2009 10:21 Modified: 7 Jan 2010 8:34
Reporter: Philip Stoev Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Backup Severity:S2 (Serious)
Version:6.0-backup OS:Any
Assigned to: Andrei Elkin CPU Architecture:Any

[17 Dec 2009 10:21] Philip Stoev
Description:
When executing a non-concurrent BACKUP/RESTORE with concurrent DDL (and KILL), restore asserted as follows:

mysqld: sql_error.cc:388: void Diagnostics_area::set_eof_status(THD*): Assertion `! is_set()' failed.

# 12:15:37 #6  0x000000315a42bec9 in __assert_fail () from /lib64/libc.so.6
# 12:15:37 #7  0x0000000000746ad9 in Diagnostics_area::set_eof_status (this=0x7f0bf01b1a10, thd=0x7f0bf01aee78) at sql_error.cc:388
# 12:15:37 #8  0x0000000000581d7a in my_eof (thd=0x7f0bf01aee78) at ../sql_class.h:2657
# 12:15:37 #9  0x0000000000ada03c in send_reply (context=@0x7f0bf7611210) at kernel.cc:433
# 12:15:37 #10 0x0000000000ada947 in execute_backup_command (thd=0x7f0bf01aee78, lex=0x7f0bf01b0758, backupdir=0x7f0bf7612190, overwrite=true, skip_gap_event=false)
# 12:15:37     at kernel.cc:329
# 12:15:37 #11 0x0000000000685b57 in mysql_execute_command (thd=0x7f0bf01aee78) at sql_parse.cc:2482
# 12:15:37 #12 0x000000000068d787 in mysql_parse (thd=0x7f0bf01aee78, inBuf=0x302f660 "RESTORE FROM '/tmp/backup32750-36' OVERWRITE", length=44,
# 12:15:37     found_semicolon=0x7f0bf7612f00) at sql_parse.cc:5985
# 12:15:37 #13 0x000000000068e320 in dispatch_command (command=COM_QUERY, thd=0x7f0bf01aee78, packet=0x7f0bf01b99f9 "", packet_length=45) at sql_parse.cc:1078
# 12:15:37 #14 0x000000000068f892 in do_command (thd=0x7f0bf01aee78) at sql_parse.cc:760
# 12:15:37 #15 0x000000000067c6b0 in handle_one_connection (arg=0x7f0bf01aee78) at sql_connect.cc:1164
# 12:15:37 #16 0x000000315b0073da in start_thread () from /lib64/libpthread.so.0
# 12:15:37 #17 0x000000315a4e627d in clone () from /lib64/libc.so.6

Kostja has previously mentioned that Diagnostics_area assertions are triggered when there is a situation of mismatch between errors and OKs, e.g. if an error is generated followed by an OK . If a release binary is used, the assertion will not be triggered, but the client and the server will lose synchronization at the protocol level.

How to repeat:
This has only been observed once over many hundreds of RESTORE-s. If the issue is repeatable, a test case will be provided. In the meantime, the core and the binary will be made available.
[17 Dec 2009 10:25] Philip Stoev
Core and binary :

http://mysql-systemqa.s3.amazonaws.com/var-bug49765.zip

Source:

revision-id: charles.bell@sun.com-20091214143531-eurme91wrjgcjwcw
date: 2009-12-14 09:35:31 -0500
build-date: 2009-12-17 12:22:26 +0200
revno: 2908
branch-nick: mysql-6.0-backup