SET STATEMENT ... FOR <statement> crashes server if <statement> needs to commit implicitly and fails

SET STATEMENT ... FOR <statement> crashes server if <statement> needs to commit implicitly and fails

For example:

CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
SET SESSION lock_wait_timeout=1;

BEGIN;
INSERT INTO t1 VALUES (5);

--connect(con1,localhost,root,,)
--connection con1
FLUSH TABLES WITH READ LOCK;

--connection default
SET STATEMENT max_join_size=0 FOR DROP TABLE t1;

The cause is thd->variables becoming a dangling pointer:

int
mysql_execute_command(THD *thd)
{
...
  struct system_variables *per_query_variables_backup;
...
  if (stmt_causes_implicit_commit(thd, CF_IMPLICIT_COMMIT_BEGIN))
...
    if (trans_commit_implicit(thd)) {
      goto error;
    }
...
  if (lex->set_statement && !lex->var_list.is_empty()) {
    per_query_variables_backup= copy_system_variables(&thd->variables,
                                                      thd->m_enable_plugins);
...
error:
...
  if (lex->set_statement && !lex->var_list.is_empty()) {
...
    free_system_variables(&thd->variables, thd->m_enable_plugins);
    thd->variables= *per_query_variables_backup;
    my_free(per_query_variables_backup);
...
}

This bug is a sibling of bug 1387951 and bug 1412423. These three bugs represent three different error paths in mysql_execute_command that result in dangling thd->variables pointer.