丁奇
Finally, there are some test-cases that are too complex and need your help. rpl.rpl_deadlock_innodb
I debugged this one. When I run the test, it crashes inside sql_plugin.cc. The reason is this code in Transfer_worker::run(): thd= new THD; ... thd->variables= rli->sql_thd->variables; I assume the intention is that slave workers should have the same session variables as the "normal" sql thread. However, it does not work to copy thd->variables like this. The reason it crashes here is that it copies thd->variables.table_plugin without using plugin_lock(). And debug builds have some extra code to help catch missing lock() / incorrect refcounting (it is turned into a double free). There may be other problems with copying thd->variables directly that I'm not aware of. But maybe it would be better if we did not try to copy thd->variables from the sql thread? I tried the following patch, and then rpl_deadlock_innodb no longer crashes: === modified file 'sql/slave.cc' --- sql/slave.cc 2012-12-05 14:05:37 +0000 +++ sql/slave.cc 2012-12-05 14:13:29 +0000 @@ -2889,13 +2889,11 @@ int Transfer_worker::run() thd= new THD; pthread_detach_this_thread(); thd->thread_stack= (char*) &i; - thd->variables= rli->sql_thd->variables; + init_slave_thread(thd, SLAVE_THD_SQL); thd->variables.option_bits|= OPTION_NO_FOREIGN_KEY_CHECKS; thd->variables.dynamic_variables_ptr= NULL; - thd->security_ctx= rli->sql_thd->security_ctx; thd->lex->thd= thd; thd->lex->derived_tables= 0; - thd->system_thread = SYSTEM_THREAD_SLAVE_SQL; dummy_rli= new Relay_log_info(FALSE); dummy_rli->no_storage= TRUE; Basically, initialise thd->variables from scratch like sql thread does, not copy from the thd of the sql thread. What do you think? BTW, the rpl_deadlock_innodb test fails differently with my patch, it times out waiting for error 1205. I did not investigate yet, maybe it is now similar to some of the other errors in other tests that you already explained. I will continue looking at the other questions in your mail. BTW, are you keeping the code in revision control somewhere (bzr, git, whatever)? It might be easier to work together on some tree where we can commit changes, rather than mail patches back and forth? Later, - Kristian.