Bug #19366 | consistent_snapshot.test fails | ||
---|---|---|---|
Submitted: | 26 Apr 2006 9:44 | Modified: | 4 May 2006 8:45 |
Reporter: | Ingo Strüwing | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
Version: | 4.1.19-BK | OS: | Linux (Debian Linux kernel 2.6.16) |
Assigned to: | Osku Salerma | CPU Architecture: | Any |
[26 Apr 2006 9:44]
Ingo Strüwing
[26 Apr 2006 11:57]
Valeriy Kravchuk
Thank you for a bug report. Verified just as described with 4.1.19-BK-debug (ChangeSet@1.2458.10.2, 2006-04-26 11:15:09+04:00) on SuSE 9.3: Starting Tests TEST RESULT ------------------------------------------------------- consistent_snapshot [ fail ] Errors are (from /home/openxs/dbs/4.1/mysql-test/var/log/mysqltest-time) : mysqltest: At line 15: query 'create table t1 (a int) engine=innodb' failed: 201 3: Lost connection to MySQL server during query (the last lines may be the most important ones) Aborting: consistent_snapshot failed in default mode. To continue, re-run with '--force'. Ending Tests Shutting-down MySQL daemon Non-debug version of server passes this test OK.
[27 Apr 2006 14:19]
Elliot Murphy
Reproduced with current BK source on AMD64 Ubuntu. Ran consistent_snapshot, got crash. Here is the backtrace: (gdb) bt #0 0x00002aaaab2a3807 in pthread_kill () from /lib/libpthread.so.0 #1 0x00000000006ae030 in write_core (sig=11) at stacktrace.c:220 #2 0x000000000058039b in handle_segfault (sig=11) at mysqld.cc:2006 #3 <signal handler called> #4 0x000000000078d72d in dict_table_get_n_user_cols (table=0x2aaaacb7e4b8) at dict0dict.ic:96 #5 0x00000000007bccb3 in row_create_table_for_mysql (table=0x2aaaacb7e4b8, trx=0x2aaaacb828b8) at row0mysql.c:1515 #6 0x000000000064e800 in create_table_def (trx=0x2aaaacb828b8, form=0x4391ba90, table_name=0x439189d0 "test/t1", path_of_temp_table=0x0) at ha_innodb.cc:3738 #7 0x000000000064ee53 in ha_innobase::create (this=0x17550d8, name=0x4391d3c0 "./test/t1.frm", form=0x4391ba90, create_info=0x2aaaadb4b3c8) at ha_innodb.cc:3961 #8 0x0000000000636b48 in ha_create_table (name=0x4391d3c0 "./test/t1.frm", create_info=0x2aaaadb4b3c8, update_create_info=false) at handler.cc:1331 #9 0x00000000006211d7 in rea_create_table (thd=0x2aaaadb4aca8, file_name=0x4391d3c0 "./test/t1.frm", db=0x171d9f8 "test", table=0x173a370 "t1", create_info=0x2aaaadb4b3c8, create_fields=@0x2aaaadb4b250, keys=0, key_info=0x173a690) at unireg.cc:246 #10 0x000000000066be16 in mysql_create_table (thd=0x2aaaadb4aca8, db=0x171d9f8 "test", table_name=0x173a370 "t1", create_info=0x2aaaadb4b3c8, fields=@0x2aaaadb4b250, keys=@0x2aaaadb4b238, tmp_table=false, select_field_count=0) at sql_table.cc:1469 #11 0x000000000059bd78 in mysql_execute_command (thd=0x2aaaadb4aca8) at sql_parse.cc:2559 #12 0x00000000005a00f2 in mysql_parse (thd=0x2aaaadb4aca8, inBuf=0x173a308 "create table t1 (a int) engine=innodb", length=37) at sql_parse.cc:4351 #13 0x00000000005a0b24 in dispatch_command (command=COM_QUERY, thd=0x2aaaadb4aca8, packet=0x2aaaadb55319 "create table t1 (a int) engine=innodb", packet_length=38) at sql_parse.cc:1519 ---Type <return> to continue, or q <return> to quit--- #14 0x00000000005a2158 in do_command (thd=0x2aaaadb4aca8) at sql_parse.cc:1322 #15 0x00000000005a2519 in handle_one_connection (arg=0x2aaaadb4aca8) at sql_parse.cc:1054 #16 0x00002aaaab2a00fa in start_thread () from /lib/libpthread.so.0 #17 0x00002aaaab845ce2 in clone () from /lib/libc.so.6 #18 0x0000000000000000 in ?? ()
[29 Apr 2006 16:07]
Ingo Strüwing
Made it a showstopper as it hinders me to push the fix for showstopper Bug#10405. I tried to disable consistent_snapshot.test, but then create_select_tmp.test crashes the server. This happens also in InnoDB code: dict_table_get_n_user_cols(). A vague guess is that the problem might have to do with: ChangeSet@1.2453.40.1, 2006-04-20 23:09:49+04:00, aivanov@mysql.com Applied innodb-4.1-ss22 snapshot.
[2 May 2006 2:08]
Heikki Tuuri
Marko, please look at this. Heikki
[2 May 2006 8:51]
Marko Mäkelä
Could you please attach the relevant snip of the error log? It should contain the failing InnoDB assertion.
[2 May 2006 9:13]
Ingo Strüwing
060429 18:48:36InnoDB: Assertion failure in thread 2992851888 in file ../include/dict0dict.ic line 96 InnoDB: Failing assertion: table->cached
[2 May 2006 9:35]
Ingo Strüwing
Ooops, accidentally changed status to open.
[2 May 2006 9:36]
Marko Mäkelä
./mysql-test-run consistent_snapshot Logging: ./mysql-test-run consistent_snapshot Installing Test Databases Removing Stale Files Installing Master Databases running ../sql/mysqld --no-defaults --bootstrap --skip-grant-tables --basedir=. --datadir=./var/master-data --skip-innodb --skip-ndbcluster --skip-bdb --language=../sql/share/english/ --character-sets-dir=../sql/share/charsets/ Installing Master Databases 1 running ../sql/mysqld --no-defaults --bootstrap --skip-grant-tables --basedir=. --datadir=./var/master-data1 --skip-innodb --skip-ndbcluster --skip-bdb --language=../sql/share/english/ --character-sets-dir=../sql/share/charsets/ Installing Slave Databases running ../sql/mysqld --no-defaults --bootstrap --skip-grant-tables --basedir=. --datadir=./var/slave-data --skip-innodb --skip-ndbcluster --skip-bdb --language=../sql/share/english/ --character-sets-dir=../sql/share/charsets/ Manager disabled, skipping manager start. Starting ndbcluster Starting ndbd Starting ndbd Waiting for started... NDBT_ProgramExit: 0 - OK Connected to Management Server at: localhost:9350 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=1 @127.0.0.1 (Version: 4.1.20, Nodegroup: 0, Master) id=2 @127.0.0.1 (Version: 4.1.20, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=3 @127.0.0.1 (Version: 4.1.20) [mysqld(API)] 4 node(s) id=4 (not connected, accepting connect from any host) id=5 (not connected, accepting connect from any host) id=6 (not connected, accepting connect from any host) id=7 (not connected, accepting connect from any host) Loading Standard Test Databases Starting Tests TEST RESULT ------------------------------------------------------- consistent_snapshot [ pass ] ------------------------------------------------------- Ending Tests Shutting-down MySQL daemon Master shutdown finished Slave shutdown finished All 1 tests were successful.
[2 May 2006 15:11]
Heikki Tuuri
The bug is that Osku's new code from April 20, 2006 calls the following before the table has been added to the dictionary cache. Fix: remove the debug assertion ut_ad(table->cached); This bug is probably in 5.0 and 5.1, too. /************************************************************************ Gets the number of system columns in a table in the dictionary cache. */ UNIV_INLINE ulint dict_table_get_n_sys_cols( /*======================*/ /* out: number of system (e.g., ROW_ID) columns of a table */ dict_table_t* table __attribute__((unused))) /* in: table */ { ut_ad(table); ut_ad(table->magic_n == DICT_TABLE_MAGIC_N); ut_ad(table->cached); return(DATA_N_SYS_COLS); } Regards, Heikki
[2 May 2006 15:12]
Heikki Tuuri
Assign this to Osku.
[2 May 2006 15:16]
Heikki Tuuri
The bug has been fixed in 5.1 already. But it is present in the latest svn version of 5.0.
[3 May 2006 6:27]
Osku Salerma
Fixed in InnoDB's 4.1 and 5.0 repositories, new snapshots sent to MySQL.
[3 May 2006 11: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/5867
[3 May 2006 11:25]
Heikki Tuuri
I approve Osku's patches.
[3 May 2006 12:24]
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/5879
[3 May 2006 14:30]
Alexander Ivanov
Pushed into 4.1.20 and 5.0.22.
[4 May 2006 8:45]
MC Brown
Noted in 4.1 and 5.0 changelogs.
[5 May 2006 20:28]
Paul DuBois
This was a test-case-only problem. No changelog entries needed.