Bug #32499 BACKUP DATABASE crashes server if database has 600 tables (any engine)
Submitted: 19 Nov 2007 18:02 Modified: 18 Aug 2009 19:22
Reporter: Guilhem Bichot Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Backup Severity:S3 (Non-critical)
Version:5.2-bk OS:Linux
Assigned to: Chuck Bell CPU Architecture:Any

[19 Nov 2007 18:02] Guilhem Bichot
Description:
I'm using the 5.2-backup tree which is now dead since 2 weeks, but 6.0-backup probably has the same issue.
Build is BUILD/compile-pentium-valgrind-max.
If I create 300 ARCHIVE tables in database "test2", "BACKUP DATABASE test2 TO some_file" works ok. If I create 300 more tables in "test2" (so, 600 in total), it crashes. The places of crash are not constant; here's one:
mysqld: sql_base.cc:1264: bool close_thread_table(THD*, TABLE**): Assertion `!table->file || table->file->inited == handler::NONE' failed.
Using MyISAM tables gives same problem. Probably engine-independent.

How to repeat:
Write a simple script to create 600 ARCHIVE tables. Possible with a stored procedure (I don't remember how but PeterG is good at this); I used python:

import sys
assert (len(sys.argv) == 5), "need 4 args: engine, db, low, high"
eng=sys.argv[1]
db=sys.argv[2]
L=int(sys.argv[3])
H=int(sys.argv[4])
for i in range(L,H):
    print "create table "+ db +".t" + repr(i) + " (a int) engine=" + eng + ";"

then run it as "python the_prog_above.py archive test2 1 601"
Then start a mysqld (no particular option), and do "BACKUP DATABASE test2". It crashes for me.
Note that:
"lock tables  test2.t1 read , test2.t2 read, <all tables> ..., test2.t600 read;"
works ok.
[24 Jun 2009 13:06] Rafal Somla
In the current tree I can get default driver errors already for 65 tables with this test script:
------------------------------------------------------------------------------
CREATE DATABASE db1;
USE db1;

let $engine=archive;
let $tcount=65;

while ($tcount)
{
  eval CREATE TABLE t$tcount (a int) ENGINE=$engine;
  dec $tcount;
}

BACKUP DATABASE db1 TO 'db1.bkp';

RESTORE FROM 'db1.bkp' OVERWRITE;

SHOW TABLES IN db1;

DROP DATABASE db1;
--exit
------------------------------------------------------------------------------

However, the server does not crash now.
[24 Jun 2009 13:23] Rafal Somla
With the above script I got server crash for 500 myisam tables.

#4  <signal handler called>
#5  0x0873da42 in _db_enter_ (_func_=0x88e879f "sql_print_error", _file_=0x88e84ce "log.cc", _line_=6804, 
    _stack_frame_=0xb7352094) at dbug.c:1165
#6  0x083c37fb in sql_print_error (format=0x8997d34 "%s") at log.cc:6804
#7  0x0882bfa0 in backup::Logger::write_message (this=0xb7352ef8, level=backup::log_level::ERROR, error_code=1685, 
    msg=0xb7352324 "Error when sending data (for table #7) to MyISAM restore driver") at logger.cc:63
#8  0x0882c246 in backup::Logger::v_write_message (this=0xb7352ef8, level=backup::log_level::ERROR, error_code=1685, 
    format=0x994e1d3 "Error when sending data (for table #%d) to %-.64s restore driver", args=0xb7352598 "\a") at logger.cc:148
#9  0x0882c2c1 in backup::Logger::v_report_error (this=0xb7352ef8, level=backup::log_level::ERROR, error_code=1685, 
    args=0xb7352598 "\a") at logger.cc:132
#10 0x0881d919 in backup::Logger::report_error (this=0xb7352ef8, error_code=1685) at ../../sql/backup/logger.h:148
#11 0x0882005b in backup::restore_table_data (thd=0x9ac0390, info=@0x9b07900, s=@0xa10a470) at data_backup.cc:1674
#12 0x08818fb4 in Backup_restore_ctx::do_restore (this=0xb7352ef8, overwrite=true) at kernel.cc:1483

This looks wierd because crash is inside DBUG_ENTER. To many levels of DBUG nesting?

Note that the backup related problem is that MyISAM restore driver reports error in send_data() method.
[14 Aug 2009 1:22] Chuck Bell
It appears this problem has been solved. I have successfully created 32,000 tables and executed a backup and restore. Creating a formal test to prove/disprove the premise.
[18 Aug 2009 19:22] Chuck Bell
Ranger's performance testing routinely test 15000 tables. Clearly, this demonstrates this bug is not repeatable.