| Bug #47103 | RBR slave crash in table_def::type when modifying a merge table | ||
|---|---|---|---|
| Submitted: | 3 Sep 2009 15:57 | Modified: | 31 Oct 2009 17:05 |
| Reporter: | Matthias Leich | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Row Based Replication ( RBR ) | Severity: | S3 (Non-critical) |
| Version: | 5.4 | OS: | Any |
| Assigned to: | Luis Soares | CPU Architecture: | Any |
| Tags: | merge, RBR, regression | ||
[5 Sep 2009 10:10]
Philip Stoev
There is another test case, with DELETE:
--source include/master-slave.inc
CREATE TABLE `table0_int_autoinc` ( `int` int, pk integer auto_increment, `int_key` int, primary key (pk), key (`int_key` ));
CREATE TABLE `table10_int_autoinc` ( `int` int, pk integer auto_increment, `int_key` int, primary key (pk), key (`int_key` ));
INSERT IGNORE INTO table10_int_autoinc VALUES (NULL, NULL, '-474021888') , ('1', NULL, NULL) , ('1141047296', NULL, NULL) , (NULL, NULL, NULL) , (NULL, NULL, '1') , (NULL, NULL, '9') , ('0', NULL, '1225785344') , (NULL, NULL, '1574174720') , ('2', NULL, NULL) , ('6', NULL, '3');
CREATE TABLE IF NOT EXISTS t1_merge_1_A LIKE test . table0_int_autoinc;
ALTER TABLE t1_merge_1_A ENGINE = MERGE UNION ( table10_int_autoinc , table0_int_autoinc);
DELETE FROM t1_merge_1_A;
[21 Sep 2009 9:43]
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/83860 2824 Luis Soares 2009-09-21 BUG#47103: RBR slave crash in table_def::type when modifying a merge table When applying the table map event, a tables_to_lock list is updated on the rli internal state. This list extends the regular TABLE_LIST, by adding extra properties: a flag and a table definition reference. These fields are used later, when applying a rows event, to check whether the table definition on the slave is compatible with the one existing on the master. The problem is that when the slave thread opens the tables, defined on tables_to_lock, it passes the tables_to_lock as a parameter to the function that will actually perform the open tables (simple_open_n_lock_tables). Internally, this function appends to the list, references to the tables that are part of the merge table, whithout filling the table definition portion. Consequently, the slave crashes later when verifying the table compatibility because, it accesses the uninitialized table definition data. We fix this, by testing the flag m_tabledef_valid before actuallly checking whether tables are compatible or not. Tables that have valid table definitions (were filled when applying Table map events), will have this flag set. @ mysql-test/suite/rpl/t/rpl_row_merge_engine.test Test case. @ sql/log_event.cc Deployed a check to m_tabledef_valid before actually verifying table compatibility.
[30 Sep 2009 0:45]
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/85108 2824 Luis Soares 2009-09-30 BUG#47103: RBR slave crash in table_def::type when modifying a merge table When applying the table map event, a tables_to_lock list is updated on the rli internal state. This list extends the regular TABLE_LIST, by adding extra properties: a flag and a table definition reference. These fields are used later, when applying a rows event, to check whether the table definition on the slave is compatible with the one existing on the master. The problem is that when the slave thread opens the tables, defined on tables_to_lock, it passes the tables_to_lock as a parameter to the function that will actually perform the open tables (simple_open_n_lock_tables). Internally, this function appends to the list, references to the tables that are part of the merge table, whithout filling the table definition portion. Consequently, the slave crashes later when verifying the table compatibility because, it accesses the uninitialized table definition data. We fix this, by checking only the table definitions that were set when processing the table map event. We do this by iterating over the table list until we reach the tables_to_lock_count variable. Additionally, we also deploy an assertion so that every table that is eligible to for table definition comparison, is asserted to have m_tabledef_valid set. @ mysql-test/suite/rpl/t/rpl_row_merge_engine.test Test case. @ sql/log_event.cc Extended loop so that its stop condition now considers the number of tables got in the Table_map_event. Additionally, a DBUG_ASSERT was deployed so that every table selected to the comparison procedure is asserted to have the m_tabledef_valid set.
[1 Oct 2009 13:36]
Luis Soares
Checking, with a test case that combines both test from Matthias and Philip, against the development trees, I have found that: mysql-5.1-bugteam => Test SUCCEEDS mysql-next-mr => Test SUCCEEDS mysql-6.0-codebase-bugfixing => Test FAILS So, bug is only repeatable in mysql-6.0-codebase-bugfixing.
[1 Oct 2009 14:55]
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/85398 2824 Luis Soares 2009-10-01 BUG#47103: RBR slave crash in table_def::type when modifying a merge table When applying the table map event, a tables_to_lock list is updated on the rli internal state. This list extends the regular TABLE_LIST, by adding extra properties: a flag and a table definition reference. These fields are used later, when applying a rows event, to check whether the table definition on the slave is compatible with the one existing on the master. The problem is that when the slave thread opens the tables, defined on tables_to_lock, it passes the tables_to_lock as a parameter to the function that will actually perform the open tables (simple_open_n_lock_tables). Internally, this function appends to the list, references to the tables that are part of the merge table, whithout filling the table definition portion. Consequently, the slave crashes later when verifying the table compatibility because, it accesses the uninitialized table definition data. We fix this, by checking only the table definitions that were set when processing the table map event. We do this by iterating over the table list until we reach the tables_to_lock_count variable. Additionally, we also deploy an assertion so that every table that is eligible to for table definition comparison, is asserted to have m_tabledef_valid set. @ mysql-test/suite/rpl/t/rpl_row_merge_engine.test The two test cases from bug report as well as more robust test case. @ sql/log_event.cc Extended loop so that its stop condition now considers the number of tables got in the Table_map_event. Additionally, a DBUG_ASSERT was deployed so that every table selected to the comparison procedure is asserted to have the m_tabledef_valid set.
[9 Oct 2009 9:56]
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/86321 3651 Luis Soares 2009-10-09 [merge] BUG#47103: automerge 6.0-cb-bf local bug branch --> 6.0-cb-bf up to date.
[9 Oct 2009 10:01]
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/86325 3653 Luis Soares 2009-10-09 [merge] BUG#47103: automerge 6.0-cb-bf local bug branch --> 6.0-cb-bf up to date.
[9 Oct 2009 10:03]
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/86326 3654 Luis Soares 2009-10-09 [merge] BUG#47103: automerge 6.0-cb-bf local bug branch --> 6.0-cb-bf up to date.
[9 Oct 2009 10:04]
Luis Soares
Pushed to mysql-6.0-codebase-bugfixing.
[31 Oct 2009 8:17]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091031081410-qkxmjsdzjmj840aq) (version source revid:guilhem@mysql.com-20091010123356-qfouds7ucvkvbczt) (merge vers: 6.0.14-alpha) (pib:13)
[31 Oct 2009 17:05]
Jon Stephens
Documented bugfix in the 6.0.14 changelog as follows:
Updates to MERGE tables when using row-based replication could
cause the slave to crash.
Closed.
[8 Jun 2011 19:54]
Sveta Smirnova
Fix for this bug have not been backported to 5.5 series: see bug #61450 also
[21 Jul 2011 7:04]
MySQL Verification Team
see bug #61932
Description: My script: ---------- --source include/master-slave.inc --disable_warnings DROP TABLE IF EXISTS t1,t2,t3; --enable_warnings CREATE TABLE t1 ( f1 integer , f2 int, primary key (f1)) ENGINE = MyISAM; CREATE TABLE t2 ( f1 integer , f2 int, primary key (f1)) ENGINE = MyISAM; CREATE TABLE t3 ( f1 integer , f2 int, primary key (f1)) ENGINE = MERGE UNION (t1,t2); INSERT IGNORE INTO t2 VALUES (1, 1); # The UPDATE gets a crash with replication format mix and row UPDATE t3 SET `f2` = 7 LIMIT 1; SELECT * FROM t3; BTW: It looks like the PRIMARY KEY is not needed. My command line: ---------------- ./mysql-test-run --mem --mysqld=--binlog-format=row \ --no-check-testcases ml2301 or ./mysql-test-run --mem --mysqld=--binlog-format=mixed \ --no-check-testcases ml2301 Backtrace from mysql-next-bugfixing 2009-09-03: ----------------------------------------------- Thread 1 (process 1560): #0 0x00007fdd40e2ece6 in pthread_kill () from /lib64/libpthread.so.0 #1 0x0000000000b57f50 in my_write_core (sig=11) at stacktrace.c:309 #2 0x00000000006efa81 in handle_segfault (sig=11) at mysqld.cc:2738 #3 <signal handler called> #4 0x00000000008c48be in table_def::type (this=0x16e1c80, index=0) at rpl_utility.h:177 #5 0x00000000008c410f in table_def::compatible_with (this=0x16e1c80, rli_arg=0x15a2f40, table=0x169e478) at rpl_utility.cc:192 #6 0x000000000080e1ec in Rows_log_event::do_apply_event (this=0x16b2f38, rli=0x15a2f40) at log_event.cc:7323 #7 0x00000000008bcd2c in Log_event::apply_event (this=0x16b2f38, rli=0x15a2f40) at log_event.h:1080 #8 0x00000000008b45f3 in apply_event_and_update_pos (ev=0x16b2f38, thd=0x16d1ec8, rli=0x15a2f40, skip=true) at slave.cc:2339 #9 0x00000000008bb91b in exec_relay_log_event (thd=0x16d1ec8, rli=0x15a2f40) at slave.cc:2503 #10 0x00000000008bc411 in handle_slave_sql (arg=0x1538760) at slave.cc:3275 #11 0x00007fdd40e2a040 in start_thread () from /lib64/libpthread.so.0 #12 0x00007fdd3fdcb08d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () System reaction in mysql-5.1-bugteam late August 2009 ----------------------------------------------------- UPDATE t3 SET `f2` = 7 LIMIT 1; +Warnings: +Note 1592 Statement may not be safe to log in statement format. I assume that the 5.4 server wants to give me the same warning, but fails somehow during this. How to repeat: See above