Skip to content

Commit d62b354

Browse files
committedApr 25, 2019
Bug#29300049: HANDLE_FATAL_SIGNAL (SIG=11) IN DESTROY
HANDLER statements that access tables with generated columns, could leave pointers to dead data in the generated column data structures, which could cause problems for statements that accessed the same tables later. The bug is fixed by cleaning up the generated column expressions before HANDLER ... OPEN finishes, and adding code that re-resolves the expressions and cleans them up again on each HANDLER ... READ statement. Change-Id: I6a1cea647b5b293c373e84cf37051424a9b9074d
1 parent de7e142 commit d62b354

File tree

1 file changed

+20
-1
lines changed

1 file changed

+20
-1
lines changed
 

‎sql/sql_handler.cc

Lines changed: 20 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
/* Copyright (c) 2001, 2016, Oracle and/or its affiliates. All rights reserved.
1+
/* Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved.
22
33
This program is free software; you can redistribute it and/or modify
44
it under the terms of the GNU General Public License as published by
@@ -380,6 +380,15 @@ static bool mysql_ha_open_table(THD *thd, TABLE_LIST *hash_tables)
380380
*/
381381
hash_tables->table->open_by_handler= 1;
382382

383+
/*
384+
Generated column expressions have been resolved using the MEM_ROOT of the
385+
current HANDLER statement, which is cleared when the statement has finished.
386+
Clean up the expressions so that subsequent HANDLER ... READ calls don't
387+
access data allocated on a cleared MEM_ROOT. The generated column
388+
expressions have to be re-resolved on each HANDLER ... READ call.
389+
*/
390+
hash_tables->table->cleanup_gc_items();
391+
383392
DBUG_PRINT("exit",("OK"));
384393
DBUG_RETURN(FALSE);
385394
}
@@ -679,6 +688,14 @@ bool Sql_cmd_handler_read::execute(THD *thd)
679688

680689
table->file->init_table_handle_for_HANDLER();
681690

691+
/*
692+
Resolve the generated column expressions. They have to be cleaned up before
693+
returning, since the resolved expressions may point to memory allocated on
694+
the MEM_ROOT of the current HANDLER ... READ statement, which will be
695+
cleared when the statement has completed.
696+
*/
697+
if (table->refix_gc_items(thd)) goto err;
698+
682699
for (num_rows=0; num_rows < select_limit_cnt; )
683700
{
684701
switch (mode) {
@@ -843,13 +860,15 @@ bool Sql_cmd_handler_read::execute(THD *thd)
843860
trans_commit_stmt(thd);
844861
mysql_unlock_tables(thd,lock);
845862
thd->mdl_context.rollback_to_savepoint(mdl_savepoint);
863+
table->cleanup_gc_items();
846864
my_eof(thd);
847865
DBUG_PRINT("exit",("OK"));
848866
DBUG_RETURN(FALSE);
849867

850868
err:
851869
trans_rollback_stmt(thd);
852870
mysql_unlock_tables(thd,lock);
871+
table->cleanup_gc_items();
853872
err1:
854873
thd->mdl_context.rollback_to_savepoint(mdl_savepoint);
855874
err0:

0 commit comments

Comments
 (0)
Please sign in to comment.