From 1c1f0a62e1f68fd39ae7440042699faaffaaf7fe Mon Sep 17 00:00:00 2001 From: unknown Date: Tue, 22 Apr 2008 02:53:12 +0400 Subject: BUG#36139 "float, zerofill, crash with subquery" - Make convert_zerofill_number_to_string() take into account that the constant it is converting may evaluate to NULL. mysql-test/r/subselect.result: BUG#36139 "float, zerofill, crash with subquery" - Testcase mysql-test/t/subselect.test: BUG#36139 "float, zerofill, crash with subquery" - Testcase --- sql/item.cc | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) (limited to 'sql') diff --git a/sql/item.cc b/sql/item.cc index 553ba1b152c..9ff1f8c0084 100644 --- a/sql/item.cc +++ b/sql/item.cc @@ -4156,9 +4156,14 @@ static void convert_zerofill_number_to_string(Item **item, Field_num *field) String tmp(buff,sizeof(buff), field->charset()), *res; res= (*item)->val_str(&tmp); - field->prepend_zeros(res); - pos= (char *) sql_strmake (res->ptr(), res->length()); - *item= new Item_string(pos, res->length(), field->charset()); + if ((*item)->is_null()) + *item= new Item_null(); + else + { + field->prepend_zeros(res); + pos= (char *) sql_strmake (res->ptr(), res->length()); + *item= new Item_string(pos, res->length(), field->charset()); + } } -- cgit v1.2.1 From 73f7de59c2739a66dcf1a7d1d4c89a1e19fddcd1 Mon Sep 17 00:00:00 2001 From: unknown Date: Wed, 23 Apr 2008 02:27:23 +0500 Subject: Fixed bug#36005: server crashes inside NOT IN clause subquery with impossible WHERE/HAVING clause (subselect_single_select_engine::exec). Allocation and initialization of joined table list t1, t2... of subqueries like: NOT IN (SELECT ... FROM t1,t2,... WHERE 0) is optimized out, however server tries to traverse this list. mysql-test/r/subselect3.result: Added test case for bug#36005. mysql-test/t/subselect3.test: Added test case for bug#36005. sql/sql_select.cc: Fixed bug#36005. 1. JOIN::prepare initializes JOIN::table counter (actually a size of the JOIN::join_tab array) and sets it to a number of joined tables. 2. The make_join_statistics function (when called from JOIN::optimize) allocates and fills the JOIN::join_tab array. However, when optimizing subselect has impossible (definite false) WHERE or HAVING clause, optimizer skips call to make_join_statistics and leaves JOIN::join_tab == NULL. 3. subselect_single_select_engine::exec does traversal of the JOIN::join_tab array and the server dies because array is not allocated but array counter is greater than 0. The JOIN::optimize method has been modified to reset the JOIN::table counter to 0 in cause of impossible WHERE/HAVING clause. --- sql/sql_select.cc | 1 + 1 file changed, 1 insertion(+) (limited to 'sql') diff --git a/sql/sql_select.cc b/sql/sql_select.cc index 976d7322f56..11062998e6a 100644 --- a/sql/sql_select.cc +++ b/sql/sql_select.cc @@ -832,6 +832,7 @@ JOIN::optimize() "Impossible HAVING" : "Impossible WHERE")); zero_result_cause= having_value == Item::COND_FALSE ? "Impossible HAVING" : "Impossible WHERE"; + tables= 0; error= 0; DBUG_RETURN(0); } -- cgit v1.2.1 From 89b866e7bfc8965046626844ee22ecd5b4e5a774 Mon Sep 17 00:00:00 2001 From: unknown Date: Fri, 25 Apr 2008 00:39:37 +0400 Subject: Bug#36023: Incorrect handling of zero length caused an assertion to fail. When a zero length is provided to the my_decimal_length_to_precision function along with unsigned_flag set to false it returns a negative value. For queries that employs temporary tables may cause failed assertion or excessive memory consumption while temporary table creation. Now the my_decimal_length_to_precision and the my_decimal_precision_to_length functions take unsigned_flag into account only if the length/precision argument is non-zero. mysql-test/t/type_decimal.test: Added a test case for the bug#36023: Incorrect handling of zero length caused an assertion to fail. mysql-test/r/type_decimal.result: Added a test case for the bug#36023: Incorrect handling of zero length caused an assertion to fail. sql/my_decimal.h: Bug#36023: Incorrect handling of zero length caused an assertion to fail. Now the my_decimal_length_to_precision and the my_decimal_precision_to_length functions take unsigned_flag into account only if the length/precision argument is non-zero. --- sql/my_decimal.h | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) (limited to 'sql') diff --git a/sql/my_decimal.h b/sql/my_decimal.h index c661579ea66..6a0d05921ec 100644 --- a/sql/my_decimal.h +++ b/sql/my_decimal.h @@ -164,14 +164,23 @@ inline int check_result_and_overflow(uint mask, int result, my_decimal *val) inline uint my_decimal_length_to_precision(uint length, uint scale, bool unsigned_flag) { - return (uint) (length - (scale>0 ? 1:0) - (unsigned_flag ? 0:1)); + /* Precision can't be negative thus ignore unsigned_flag when length is 0. */ + DBUG_ASSERT(length || !scale); + return (uint) (length - (scale>0 ? 1:0) - + (unsigned_flag || !length ? 0:1)); } inline uint32 my_decimal_precision_to_length(uint precision, uint8 scale, bool unsigned_flag) { + /* + When precision is 0 it means that original length was also 0. Thus + unsigned_flag is ignored in this case. + */ + DBUG_ASSERT(precision || !scale); set_if_smaller(precision, DECIMAL_MAX_PRECISION); - return (uint32)(precision + (scale>0 ? 1:0) + (unsigned_flag ? 0:1)); + return (uint32)(precision + (scale>0 ? 1:0) + + (unsigned_flag || !precision ? 0:1)); } inline -- cgit v1.2.1