From 017307f2163a068520374b3083895e246b7a4a60 Mon Sep 17 00:00:00 2001 From: Davi Arnaut Date: Tue, 14 Oct 2008 11:04:36 -0300 Subject: Bug#38823: Invalid memory access when a SP statement does wildcard expansion The problem is that field names constructed due to wild-card expansion done inside a stored procedure could point to freed memory if the expansion was performed after the first call to the stored procedure. The problem was solved by patch for Bug#38691. The solution was to allocate the database, table and field names in the in the statement memory instead of table memory. mysql-test/r/sp.result: Add test case result for Bug#38823 mysql-test/t/sp.test: Add test case for Bug#38823 sql/item.cc: Remark that this also impacts wildcard expansion inside SPs. --- sql/item.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'sql') diff --git a/sql/item.cc b/sql/item.cc index e49de88cea7..182f4abdfe6 100644 --- a/sql/item.cc +++ b/sql/item.cc @@ -1759,7 +1759,8 @@ Item_field::Item_field(THD *thd, Name_resolution_context *context_arg, be allocated in the statement memory, not in table memory (the table structure can go away and pop up again between subsequent executions of a prepared statement or after the close_tables_for_reopen() call - in mysql_multi_update_prepare()). + in mysql_multi_update_prepare() or due to wildcard expansion in stored + procedures). */ { if (db_name) -- cgit v1.2.1