| Bug #42478 | Falcon crash in Database::updateSequence | ||
|---|---|---|---|
| Submitted: | 30 Jan 2009 13:55 | Modified: | 26 May 2010 17:47 |
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Unsupported | Impact on me: | |
| Category: | MySQL Server: Falcon storage engine | Severity: | S1 (Critical) |
| Version: | 6.0-falcon-team | OS: | Any |
| Assigned to: | Vladislav Vaintroub | CPU Architecture: | Any |
| Tags: | F_DDL, pb2 | ||
[23 Feb 2009 16:22]
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/67227 3030 Vladislav Vaintroub 2009-02-23 Bug#42478 : Falcon crash in Database::updateSequence The problem: when a Falcon table with autoincrement column is created ,Falcon will assign a sequence to table name /schema name combination. and use it to generate autoincrement values. When table is renamed, sequence is modified (table name changed). However, schema name changes are not taken into account when renaming. This is be a problem, because a) Falcon data dictionary (sequences table) is now corrupt. b) hash table sequences will have duplicate entries if there is a table with the same name and different schema. drop table may drop a wrong sequence. The fix is to take schema name into account when renaming a sequence. @ mysql-test/suite/falcon/r/falcon_bug_42478.result new test @ mysql-test/suite/falcon/t/falcon_bug_42478.test new test @ storage/falcon/Sequence.cpp when renaming sequence, take schema name into account @ storage/falcon/Sequence.h when renaming sequence, take schema name into account @ storage/falcon/SequenceManager.cpp when renaming sequence, take schema name into account @ storage/falcon/SequenceManager.h when renaming sequence, take schema name into account @ storage/falcon/StorageDatabase.cpp when renaming sequence, take schema name into account
Description: When executing the falcon_ddl RQG test, Falcon crashed as follows: #3 <signal handler called> #4 0x00680184 in Database::updateSequence (this=0xeeeeeeee, sequenceId=-286331154, delta=0, transaction=0x0) at Database.cpp:1957 #5 0x007299a4 in Sequence::update (this=0x8306da8, delta=0, transaction=0x0) at Sequence.cpp:46 #6 0x00630488 in StorageTableShare::getSequenceValue (this=0x1f94958, delta=0) at StorageTableShare.cpp:579 #7 0x00606e9c in StorageInterface::info (this=0x7a0a550, what=84) at ha_falcon.cpp:697 #8 0x004a9784 in get_schema_tables_record (thd=0x72f18c0, tables=0x7d28908, table=0x7d258d8, res=false, db_name=0xfd7b05e0, table_name=0xfd7b05e8) at sql_show.cc:3722 #9 0x004a8244 in get_all_tables (thd=0x72f18c0, tables=0x7508738, cond=0x0) at sql_show.cc:3480 #10 0x004b8024 in get_schema_tables_result (join=0x7e078b0, executed_place=PROCESSED_BY_JOIN_EXEC) at sql_show.cc:6427 #11 0x00386a00 in JOIN::exec (this=0x7e078b0) at sql_select.cc:2388 #12 0x003898f0 in mysql_select (thd=0x72f18c0, rref_pointer_array=0x72f2cc8, tables=0x7508738, wild_num=0, fields=@0x72f2c58, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2686208512, result=0x75095f0, unit=0x72f2920, select_lex=0x72f2bc0) at sql_select.cc:3052 #13 0x00389d04 in handle_select (thd=0x72f18c0, lex=0x72f28c0, result=0x75095f0, setup_tables_done_option=0) at sql_select.cc:314 #14 0x002b7f30 in execute_sqlcom_select (thd=0x72f18c0, all_tables=0x7508738) at sql_parse.cc:4747 #15 0x002bfb38 in mysql_execute_command (thd=0x72f18c0) at sql_parse.cc:2062 #16 0x002c9f4c in mysql_parse (thd=0x72f18c0, inBuf=0x75078b0 "SHOW TABLE STATUS", length=17, found_semicolon=0xfd7b1dc8) at sql_parse.cc:5735 #17 0x002caa70 in dispatch_command (command=COM_QUERY, thd=0x72f18c0, packet=0x72fd8a1 "SHOW TABLE STATUS", packet_length=17) at sql_parse.cc:1008 #18 0x002cc200 in do_command (thd=0x72f18c0) at sql_parse.cc:691 #19 0x002b4058 in handle_one_connection (arg=0x72f18c0) at sql_connect.cc:1145 #20 0xfef3fff8 in _lwp_start () from /lib/libc.so.1 #21 0xfef3fff8 in _lwp_start () from /lib/libc.so.1 Note that in frame #4, this=0xeeeeeeee . This crash was probably not seen before because the falcon_ddl previously did not contain auto_increment. auto_increment was added because code coverage showed that Falcon sequences, that, is auto_increment is not being exercised by the RQG. The crash is due to SHOW TABLE STATUS, however very likely Falcon's internal structures were corrupted from some other DDL statement. How to repeat: $ perl pb2gentest.pl /path/to/6.0-falcon-team /tmp zz falcon_ddl