maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

丁奇 <dingqi.lxb@xxxxxxxxxx> writes:

> 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.