summaryrefslogtreecommitdiff
path: root/sql/item_sum.cc
diff options
context:
space:
mode:
authorAlexey Kopytov <Alexey.Kopytov@sun.com>2010-07-23 15:52:54 +0400
committerAlexey Kopytov <Alexey.Kopytov@sun.com>2010-07-23 15:52:54 +0400
commit1837dcfee747b697bce2023d94a8daff6e393039 (patch)
tree968035539cb4324405b5e70618b963a92ca66d7e /sql/item_sum.cc
parentcfb9ee98564e3536a0a3f1fa464a5f2a5eddd18f (diff)
downloadmariadb-git-1837dcfee747b697bce2023d94a8daff6e393039.tar.gz
Bug #54476: crash when group_concat and 'with rollup' in
prepared statements Using GROUP_CONCAT() together with the WITH ROLLUP modifier could crash the server. The reason was a combination of several facts: 1. The Item_func_group_concat class stores pointers to ORDER objects representing the columns in the ORDER BY clause of GROUP_CONCAT(). 2. find_order_in_list() called from Item_func_group_concat::setup() modifies the ORDER objects so that their 'item' member points to the arguments list allocated in the Item_func_group_concat constructor. 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of the original Item_func_group_concat object could be created by using the Item_func_group_concat::Item_func_group_concat(THD *thd, Item_func_group_concat *item) copy constructor. The latter essentially creates a shallow copy of the source object. Memory for the arguments array is allocated on thd->mem_root, but the pointers for arguments and ORDER are copied verbatim. What happens in the test case is that when executing the query for the first time, after a copy of the original Item_func_group_concat object has been created by JOIN::rollup_make_fields(), find_order_in_list() is called for this new object. It then resolves ORDER BY by modifying the ORDER objects so that they point to elements of the arguments array which is local to the cloned object. When thd->mem_root is freed upon completing the execution, pointers in the ORDER objects become invalid. Those ORDER objects, however, are also shared with the original Item_func_group_concat object which is preserved between executions of a prepared statement. So the first call to find_order_in_list() for the original object on the second execution tries to dereference an invalid pointer. The solution is to create copies of the ORDER objects when copying Item_func_group_concat to not leave any stale pointers in other instances with different lifecycles. mysql-test/r/func_gconcat.result: Test case for bug #54476. mysql-test/t/func_gconcat.test: Test case for bug #54476. sql/item_sum.cc: Copy the ORDER objects pointed to by the elements of the 'order' array in the copy constructor of Item_func_group_concat. sql/table.h: Removed the unused 'item_copy' member of the ORDER class.
Diffstat (limited to 'sql/item_sum.cc')
-rw-r--r--sql/item_sum.cc19
1 files changed, 18 insertions, 1 deletions
diff --git a/sql/item_sum.cc b/sql/item_sum.cc
index 228e36fc9f9..1048bd3d6ff 100644
--- a/sql/item_sum.cc
+++ b/sql/item_sum.cc
@@ -3034,7 +3034,6 @@ Item_func_group_concat::Item_func_group_concat(THD *thd,
tree(item->tree),
unique_filter(item->unique_filter),
table(item->table),
- order(item->order),
context(item->context),
arg_count_order(item->arg_count_order),
arg_count_field(item->arg_count_field),
@@ -3047,6 +3046,24 @@ Item_func_group_concat::Item_func_group_concat(THD *thd,
{
quick_group= item->quick_group;
result.set_charset(collation.collation);
+
+ /*
+ Since the ORDER structures pointed to by the elements of the 'order' array
+ may be modified in find_order_in_list() called from
+ Item_func_group_concat::setup(), create a copy of those structures so that
+ such modifications done in this object would not have any effect on the
+ object being copied.
+ */
+ ORDER *tmp;
+ if (!(order= (ORDER **) thd->alloc(sizeof(ORDER *) * arg_count_order +
+ sizeof(ORDER) * arg_count_order)))
+ return;
+ tmp= (ORDER *)(order + arg_count_order);
+ for (uint i= 0; i < arg_count_order; i++, tmp++)
+ {
+ memcpy(tmp, item->order[i], sizeof(ORDER));
+ order[i]= tmp;
+ }
}