From 251fa88afacbd03a00894c04037d987b62f3ca58 Mon Sep 17 00:00:00 2001 From: Tatjana Azundris Nuernberg Date: Mon, 2 Jan 2012 06:25:48 +0000 Subject: BUG#11755281/47032: ERROR 2006 / ERROR 2013 INSTEAD OF PROPER ERROR MESSAGE If init_command was incorrect, we couldn't let users execute queries, but we couldn't report the issue to the client either as it does not expect error messages before even sending a command. Thus, we simply disconnected them without throwing a clear error. We now go through the proper sequence once (without executing any user statements) so we can report back what the problem is. Only then do we disconnect the user. As always, root remains unaffected by this as init_command is (still) not executed for them. mysql-test/r/init_connect.result: We now report a proper error if init_command fails. Expect as much. mysql-test/t/init_connect.test: We now report a proper error if init_command fails. Expect as much. sql/sql_connect.cc: If init_command fails, throw an error explaining this to the user. --- mysql-test/t/init_connect.test | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/init_connect.test b/mysql-test/t/init_connect.test index b6bac5f65fa..e96d02fe0d1 100644 --- a/mysql-test/t/init_connect.test +++ b/mysql-test/t/init_connect.test @@ -36,6 +36,14 @@ connection con0; set GLOBAL init_connect="adsfsdfsdfs"; connect (con5,localhost,user_1,,); connection con5; +# BUG#11755281/47032: ERROR 2006 / ERROR 2013 INSTEAD OF PROPER ERROR MESSAGE +# We now throw a proper error message here: +--replace_regex /connection .* to/connection to/ +--error ER_NEW_ABORTING_CONNECTION +select @a; +# We got disconnected after receiving the above error message; any further +# requests should fail with a notice that no one's listening to us. +# --error CR_SERVER_GONE_ERROR,CR_SERVER_LOST --error 2013,2006 select @a; connection con0; -- cgit v1.2.1 From b8291e2b60b311b621b15aff1dfec817da1bbf4c Mon Sep 17 00:00:00 2001 From: Jon Olav Hauglid Date: Mon, 9 Jan 2012 11:28:02 +0100 Subject: Backport from mysql-trunk of: ------------------------------------------------------------ revno: 3258 committer: Jon Olav Hauglid branch nick: mysql-trunk-bug12663165 timestamp: Thu 2011-07-14 10:05:12 +0200 message: Bug#12663165 SP DEAD CODE REMOVAL DOESN'T UNDERSTAND CONTINUE HANDLERS When stored routines are loaded, a simple optimizer tries to locate and remove dead code. The problem was that this dead code removal did not work correctly with CONTINUE handlers. If a statement triggers a CONTINUE handler, the following statement will be executed after the handler statement has completed. This means that the following statement is not dead code even if the previous statement unconditionally alters control flow. This fact was lost on the dead code removal routine, which ended up with removing instructions that could have been executed. This could then lead to assertions, crashes and generally bad behavior when the stored routine was executed. This patch fixes the problem by marking as live code all stored routine instructions that are in the same scope as a CONTINUE handler. Test case added to sp.test. --- mysql-test/t/sp.test | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/sp.test b/mysql-test/t/sp.test index 141d1604065..ae4e1dd588e 100644 --- a/mysql-test/t/sp.test +++ b/mysql-test/t/sp.test @@ -8397,6 +8397,35 @@ DROP FUNCTION f1; DROP TABLE t1, t2; +--echo # +--echo # Bug#12663165 SP DEAD CODE REMOVAL DOESN'T UNDERSTAND CONTINUE HANDLERS +--echo # + +--disable_warnings +DROP FUNCTION IF EXISTS f1; +--enable_warnings + +delimiter $; +CREATE FUNCTION f1() RETURNS INT +BEGIN + DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN END; + BEGIN + DECLARE CONTINUE HANDLER FOR SQLEXCEPTION RETURN f1(); + BEGIN + DECLARE CONTINUE HANDLER FOR SQLEXCEPTION RETURN f1(); + RETURN f1(); + END; + END; +RETURN 1; +END $ +delimiter ;$ + +# This used to cause an assertion. +SELECT f1(); + +DROP FUNCTION f1; + + --echo # ------------------------------------------------------------------ --echo # -- End of 5.1 tests --echo # ------------------------------------------------------------------ -- cgit v1.2.1 From 99e462ab0b308e629f4604adc3a33e2cf817be82 Mon Sep 17 00:00:00 2001 From: Nirbhay Choubey Date: Tue, 10 Jan 2012 13:33:45 +0530 Subject: BUG#11760384 - 52792: mysqldump in XML mode does not dump routines. mysqldump in xml mode did not dump routines, events or triggers. This patch fixes this issue by fixing the if conditions that disallowed the dump of above mentioned objects in xml mode, and added the required code to enable dump in xml format. client/mysqldump.c: BUG#11760384 - 52792: mysqldump in XML mode does not dump routines. Fixed some if conditions to allow execution of dump methods for xml and further added the relevant code at places to produce the dump in xml format. mysql-test/r/mysqldump.result: Added a test case for Bug#11760384. mysql-test/t/mysqldump.test: Added a test case for Bug#11760384. --- mysql-test/t/mysqldump.test | 112 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/mysqldump.test b/mysql-test/t/mysqldump.test index 8ecf8187ff9..20c788e3b9a 100644 --- a/mysql-test/t/mysqldump.test +++ b/mysql-test/t/mysqldump.test @@ -2196,6 +2196,118 @@ DROP DATABASE `test-database`; # Switching back to test database. USE `test`; +--echo # +--echo # BUG#11760384 : 52792: mysqldump in XML mode does not dump routines. +--echo # +CREATE DATABASE BUG52792; +USE BUG52792; +CREATE TABLE t1 (c1 INT, c2 VARCHAR(20)); +CREATE TABLE t2 (c1 INT); +INSERT INTO t1 VALUES (1, 'aaa'), (2, 'bbb'), (3, 'ccc'); +INSERT INTO t2 VALUES (1),(2),(3); + +--echo # Stored Procedures. + +DELIMITER //; +CREATE PROCEDURE simpleproc1 (OUT param1 INT) +BEGIN + SELECT COUNT(*) INTO param1 FROM t1; +END// +DELIMITER ;// + +DELIMITER //; +CREATE PROCEDURE simpleproc2 (OUT param1 INT) +BEGIN + SELECT COUNT(*) INTO param1 FROM t2; +END// +DELIMITER ;// + +--echo # Events. + +CREATE EVENT e1 ON SCHEDULE EVERY 1 SECOND DO DROP DATABASE BUG52792; +CREATE EVENT e2 ON SCHEDULE EVERY 1 SECOND DO DROP DATABASE BUG52792; + +--echo # Functions. + +CREATE FUNCTION `hello1` (s CHAR(20)) + RETURNS CHAR(50) DETERMINISTIC +RETURN CONCAT('Hello, ' ,s ,'!'); + +CREATE FUNCTION `hello2` (s CHAR(20)) + RETURNS CHAR(50) DETERMINISTIC +RETURN CONCAT(']]>, ' , s ,'!'); + +--echo # Triggers. + +DELIMITER |; +CREATE TRIGGER trig1 BEFORE INSERT ON t2 + FOR EACH ROW BEGIN + INSERT INTO t2 VALUES(1); +END; +| +DELIMITER ;| + +DELIMITER |; +CREATE TRIGGER trig2 AFTER INSERT ON t2 + FOR EACH ROW BEGIN + INSERT INTO t2 VALUES(1, ']]>'); + INSERT INTO t2 VALUES(2, ''); + INSERT INTO t2 VALUES(3, ' & \ " _'); +END; +| +DELIMITER ;| + +--echo # Views + +CREATE VIEW v1 AS SELECT * FROM t1; +CREATE VIEW v2 AS SELECT * FROM t2; +--echo +--echo # Dumping BUG52792 database in xml format. +--echo +--echo # Running 'replace_regex on timestamp' +--replace_regex /[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}/--TIME--/ +--exec $MYSQL_DUMP --user=root --compact -R -E --triggers -X BUG52792 +--echo +--echo # Dumping BUG52792 database in xml format with comments. +--echo +--echo # Running 'replace_regex on timestamp' +--replace_regex /[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}/--TIME--/ +--exec $MYSQL_DUMP --comments --user=root -R -E --triggers -X BUG52792 + +--echo +--echo # Test to check 'Insufficient privileges' error. +--echo + +GRANT ALL PRIVILEGES ON BUG52792.* TO user1; + +connect (conn_1, localhost, user1, , BUG52792, $MASTER_MYPORT, $MASTER_MYSOCK); +connection conn_1; + +--echo # Running 'replace_regex on timestamp' +--replace_regex /[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}/--TIME--/ +--error 2 +--exec $MYSQL_DUMP --user=user1 -R -E --triggers -X BUG52792 + +connection default; +disconnect conn_1; + +DROP USER user1; +DROP DATABASE BUG52792; +--echo # UTF-8 +CREATE DATABASE BUG52792; +USE BUG52792; +SET NAMES utf8; +CREATE FUNCTION `straße` ( c1 CHAR(20)) + RETURNS CHAR(50) DETERMINISTIC +RETURN CONCAT(']]>, ', s, '!'); + +--exec $MYSQL_DUMP --character-sets-dir=$CHARSETSDIR --skip-comments --default-character-set=utf8 --compatible=mysql323 -R -X BUG52792 + +DROP DATABASE BUG52792; + +USE test; + --echo # --echo # End of 5.1 tests --echo # -- cgit v1.2.1 From e449cf48afc34705b601113fd73bce84338c2e37 Mon Sep 17 00:00:00 2001 From: Alexander Barkov Date: Mon, 23 Jan 2012 13:07:10 +0400 Subject: Bug#11752408 - 43593: DUMP/BACKUP/RESTORE/UPGRADE TOOLS FAILS BECAUSE OF UTF8_GENERAL_CI Introducing new collations: utf8_general_mysql500_ci and ucs2_general_mysql500_ci, to reproduce behaviour of utf8_general_ci and ucs2_general_ci from mysql-5.1.23 (and earlier). The collations are added to simplify upgrade from mysql-5.1.23 and earlier. Note: The patch does not make new server start over old data automatically. Some manual upgrade procedures are assumed. Paul: please get in touch with me to discuss upgrade procedures when documenting this bug. modified: include/m_ctype.h mysql-test/r/ctype_utf8.result mysql-test/t/ctype_utf8.test mysys/charset-def.c strings/ctype-ucs2.c strings/ctype-utf8.c --- mysql-test/t/ctype_utf8.test | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/ctype_utf8.test b/mysql-test/t/ctype_utf8.test index 8e9f09d1e56..545afbbcf6c 100644 --- a/mysql-test/t/ctype_utf8.test +++ b/mysql-test/t/ctype_utf8.test @@ -1484,5 +1484,13 @@ SELECT HEX(LPAD(_utf8 0xD18F, 3, 0x20)); SELECT HEX(INSERT(_utf8 0xD18F, 2, 1, 0x20)); SELECT HEX(INSERT(_utf8 0xD18FD18E, 2, 1, 0x20)); +--echo # +--echo # Bug#11752408 - 43593: DUMP/BACKUP/RESTORE/UPGRADE TOOLS FAILS BECAUSE OF UTF8_GENERAL_CI +--echo # +CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci); +INSERT INTO t1 VALUES ('a'),('r'),('s'),(_latin1 0xDF),(_latin1 0xF7),('t'),('z'); +SELECT * FROM t1 ORDER BY a; +SELECT a, COUNT(*) FROM t1 GROUP BY a; +DROP TABLE t1; --echo End of 5.1 tests -- cgit v1.2.1 From f8e924b467d099b5d99248c160a2aba59a6ea3ce Mon Sep 17 00:00:00 2001 From: Alexander Barkov Date: Tue, 24 Jan 2012 13:00:13 +0400 Subject: BUG#13458237 - INCONSISTENT HANDLING OF INVALIDE DATES WITH ZERO DAY. SIMILAR TO '2009-10-00' - Reverting the patch for Bug # 12584302 The patch will be reverted in 5.1 and 5.5. The patch will not be reverted in 5.6, the change will be properly documented in 5.6. - Backporting DBUG_ASSERT not to crash on '0000-01-00' (already fixed in mysql-trunk (5.6)) --- mysql-test/t/func_time.test | 61 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/func_time.test b/mysql-test/t/func_time.test index 2dcac0d5796..3ea79a7fc94 100644 --- a/mysql-test/t/func_time.test +++ b/mysql-test/t/func_time.test @@ -934,4 +934,65 @@ SELECT WEEK(DATE_ADD(FROM_DAYS(1),INTERVAL 1 MONTH), 1); DO WEEK((DATE_ADD((CAST(0 AS DATE)), INTERVAL 1 YEAR_MONTH)), 5); +--echo # +--echo # BUG#13458237 INCONSISTENT HANDLING OF INVALIDE DATES WITH ZERO DAY +--echo # SIMILAR TO '2009-10-00' +--echo # + +query_vertical SELECT + DATE('20091000'), + STR_TO_DATE('200910','%Y%m'), + LAST_DAY('2009-10-00'), + LAST_DAY(DATE('2009-10-00')), + LAST_DAY(DATE'2009-10-00'), + LAST_DAY(STR_TO_DATE('200910','%Y%m')), + WEEK('2009-10-00'), + WEEK(DATE('2009-10-00')), + WEEK(DATE'2009-10-00'), + WEEK(STR_TO_DATE('200910','%Y%m')), + WEEKOFYEAR('2009-10-00'), + WEEKOFYEAR(DATE('2009-10-00')), + WEEKOFYEAR(DATE'2009-10-00'), + WEEKOFYEAR(STR_TO_DATE('200910','%Y%m')), + DAYOFYEAR('2009-10-00'), + DAYOFYEAR(DATE('2009-10-00')), + DAYOFYEAR(DATE'2009-10-00'), + DAYOFYEAR(STR_TO_DATE('200910','%Y%m')), + WEEKDAY('2009-10-00'), + WEEKDAY(DATE('2009-10-00')), + WEEKDAY(DATE'2009-10-00'), + WEEKDAY(STR_TO_DATE('200910','%Y%m')), + TO_DAYs('2009-10-00'), + TO_DAYs(DATE('2009-10-00')), + TO_DAYs(DATE'2009-10-00'), + TO_DAYs(STR_TO_DATE('200910','%Y%m')); + +query_vertical SELECT + DATE('00000100'), + STR_TO_DATE('000001','%Y%m'), + LAST_DAY('0000-01-00'), + LAST_DAY(DATE('0000-01-00')), + LAST_DAY(DATE'0000-01-00'), + LAST_DAY(STR_TO_DATE('000001','%Y%m')), + WEEK('0000-01-00'), + WEEK(DATE('0000-01-00')), + WEEK(DATE'0000-01-00'), + WEEK(STR_TO_DATE('000001','%Y%m')), + WEEKOFYEAR('0000-01-00'), + WEEKOFYEAR(DATE('0000-01-00')), + WEEKOFYEAR(DATE'0000-01-00'), + WEEKOFYEAR(STR_TO_DATE('000001','%Y%m')), + DAYOFYEAR('0000-01-00'), + DAYOFYEAR(DATE('0000-01-00')), + DAYOFYEAR(DATE'0000-01-00'), + DAYOFYEAR(STR_TO_DATE('000001','%Y%m')), + WEEKDAY('0000-01-00'), + WEEKDAY(DATE('0000-01-00')), + WEEKDAY(DATE'0000-01-00'), + WEEKDAY(STR_TO_DATE('000001','%Y%m')), + TO_DAYs('0000-01-00'), + TO_DAYs(DATE('0000-01-00')), + TO_DAYs(DATE'0000-01-00'), + TO_DAYs(STR_TO_DATE('000001','%Y%m')); + --echo End of 5.1 tests -- cgit v1.2.1 From 9e0b69c0b7122d2973aa61a4efd9e8d80ad4a970 Mon Sep 17 00:00:00 2001 From: Guilhem Bichot Date: Thu, 26 Jan 2012 10:25:23 +0100 Subject: Fixes for: BUG#13519696 - 62940: SELECT RESULTS VARY WITH VERSION AND WITH/WITHOUT INDEX RANGE SCAN BUG#13453382 - REGRESSION SINCE 5.1.39, RANGE OPTIMIZER WRONG RESULTS WITH DECIMAL CONVERSION BUG#13463488 - 63437: CHAR & BETWEEN WITH INDEX RETURNS WRONG RESULT AFTER MYSQL 5.1. Those are all cases where the range optimizer got it wrong with > and >=. mysql-test/r/range.result: Without the code fix for DECIMAL, "select count(val) from t2 where val > 0.1155" (which uses a range scan) returned 127 instead of 128); Moreover, both select * from t1 force index (primary) where a=1 and c>= 2.9; and select * from t1 force index (primary) where a=1 and c> 2.9; would miss "1 1 3". Without the code fix for strings, both SELECT * FROM t1 WHERE F1 >= 'A '; and SELECT * FROM t1 WHERE F1 BETWEEN 'A ' AND 'AAAAA'; would miss "A A A". sql/item.cc: Preamble to the explanations below: opt_range.cc:get_mm_leaf() does this (this is not changed by the patch): changes column > value to column OP V where: * V is what is in "column" after we stored "value" in it (such store operation may have done rounding...) * OP is > or >=, depending on what's correct. For example, if c is an INT column, c > 2.9 is changed to c OP 3 where OP is >= ('>' would not be correct). The bugs below are cases where we chose OP wrongly. Note that such transformations are visible in the optimizer trace. 1) Fix for STRING. In the scenario with CHAR(5) in range.test, this happens, in get_mm_tree(), for the condition F1>='A ': * value->save_in_field_no_warnings(field, 1) wants to store the right argument (named 'item') into the CHAR(5) field; this stores 'A ' (the item's value) padded with spaces (which changes nothing: still 'A ') * we come to case Item_func::GE_FUNC: /* Don't use open ranges for partial key_segments */ if ((!(key_part->flag & HA_PART_KEY_SEG)) && (stored_field_cmp_to_item(param->thd, field, value) < 0)) tree->min_flag= NEAR_MIN; tree->max_flag=NO_MAX_RANGE; What this wants to do is: if the field's value is strictly smaller than the item's, then ">=" can be changed to ">" (this is an optimization, it can help pruning one useless partition). * stored_field_cmp_to_item() is called; it compares the field's and item's values: the item's value (Item_string::val_str()) is 'A ') and the field's value (Field_string::val_str()) is 'A' (yes val_str() removes end spaces unless sql_mode='PAD_CHAR_TO_FULL_LENGTH'); and the comparison is done with stringcmp() which considers end spaces as relevant; as end spaces differ, function returns a negative number, and ">='A '" becomes ">'A'" (i.e. the NEAR_MIN flag is turned on). During execution the index range scan code will search for "A", find a match, but exclude it (because of ">"), wrongly. The badness is the string comparison done by stored_field_cmp_to_item(): we use the reply of this function to determine where the index search should start, so it should do comparison like index search does comparisons; index search comparisons are ha_key_cmp() which uses a collation-aware comparison (in our case, my_strnncollsp_simple(), which ignores end spaces); so stored_field_cmp_to_item() needs to do the same. When this is fixed, condition becomes ">='A '". 2) Fix for DECIMAL: just like in other comparisons in stored_field_cmp_to_item(), we must first pass the field and then the item; otherwise expectations on what <0 and >0 mean (inferiority, superiority) get violated. In the test in range.test about c>2.9: c is an INT column, so 2.9 gets stored as 3, then stored_field_cmp_to_item() compares 3 and 2.9; because of the wrong order of arguments passed to my_decimal_cmp(), range optimizer thinks that 3 is < 2.9 and thus changes "c> 2.9" to "c> 3". After fixing the order, it changes to the correct "c>= 3". In the test in range.inc for val > 0.1155, it was changed to val > 0.116, now it is changed to val >= 0.116. --- mysql-test/t/range.test | 76 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/range.test b/mysql-test/t/range.test index 6c9320b708a..30d15798336 100644 --- a/mysql-test/t/range.test +++ b/mysql-test/t/range.test @@ -1392,4 +1392,80 @@ SELECT * FROM t1, t1 as t2 WHERE t1.i4 BETWEEN t2.pk AND t2.pk; DROP TABLE t1; +--echo # +--echo # BUG#13519696 - 62940: SELECT RESULTS VARY WITH VERSION AND +--echo # WITH/WITHOUT INDEX RANGE SCAN +--echo # + +create table t1 (id int unsigned not null auto_increment primary key); +insert into t1 values (null); +insert into t1 select null from t1; +insert into t1 select null from t1; +insert into t1 select null from t1; +insert into t1 select null from t1; +insert into t1 select null from t1; +insert into t1 select null from t1; +insert into t1 select null from t1; +insert into t1 select null from t1; +create table t2 ( + id int unsigned not null auto_increment, + val decimal(5,3) not null, + primary key (id,val), + unique key (val,id), + unique key (id)); +--disable_warnings +insert into t2 select null,id*0.0009 from t1; +--enable_warnings + +select count(val) from t2 ignore index (val) where val > 0.1155; +select count(val) from t2 force index (val) where val > 0.1155; + +drop table t2, t1; + +--echo # +--echo # BUG#13453382 - REGRESSION SINCE 5.1.39, RANGE OPTIMIZER WRONG +--echo # RESULTS WITH DECIMAL CONVERSION +--echo # + +create table t1 (a int,b int,c int,primary key (a,c)); +insert into t1 values (1,1,2),(1,1,3),(1,1,4); +# show that the integer 3 is bigger than the decimal 2.9, +# which should also apply to comparing "c" with 2.9 +# when c is 3. +select convert(3, signed integer) > 2.9; +select * from t1 force index (primary) where a=1 and c>= 2.9; +select * from t1 ignore index (primary) where a=1 and c>= 2.9; +select * from t1 force index (primary) where a=1 and c> 2.9; +select * from t1 ignore index (primary) where a=1 and c> 2.9; +drop table t1; + +--echo # +--echo # BUG#13463488 - 63437: CHAR & BETWEEN WITH INDEX RETURNS WRONG +--echo # RESULT AFTER MYSQL 5.1. +--echo # + +CREATE TABLE t1( + F1 CHAR(5) NOT NULL, + F2 CHAR(5) NOT NULL, + F3 CHAR(5) NOT NULL, + PRIMARY KEY(F1), + INDEX IDX_F2(F2) +); + +INSERT INTO t1 VALUES +('A','A','A'),('AA','AA','AA'),('AAA','AAA','AAA'), +('AAAA','AAAA','AAAA'),('AAAAA','AAAAA','AAAAA'); + +SELECT * FROM t1 WHERE F1 = 'A '; +SELECT * FROM t1 IGNORE INDEX(PRIMARY) WHERE F1 = 'A '; +SELECT * FROM t1 WHERE F1 >= 'A '; +SELECT * FROM t1 WHERE F1 > 'A '; +SELECT * FROM t1 WHERE F1 BETWEEN 'A ' AND 'AAAAA'; +SELECT * FROM t1 WHERE F2 BETWEEN 'A ' AND 'AAAAA'; +SELECT * FROM t1 WHERE F3 BETWEEN 'A ' AND 'AAAAA'; +SELECT * FROM t1 IGNORE INDEX(PRIMARY) WHERE F1 BETWEEN 'A ' AND +'AAAAA'; + +DROP TABLE t1; + --echo End of 5.1 tests -- cgit v1.2.1 From 26c52659c9fb2ddbdabb661f0a089705d16a46c1 Mon Sep 17 00:00:00 2001 From: Tor Didriksen Date: Fri, 27 Jan 2012 11:13:13 +0100 Subject: Bug#13580775 ASSERTION FAILED: RECORD_LENGTH == M_RECORD_LENGTH Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP The assert in 13580775 is visible in 5.6 only, but shows that all versions are vulnerable. 13011410 crashes in all versions. filesort tries to re-use the sort buffer between invocations in order to save malloc/free overhead. The fix for Bug 11748783 - 37359: FILESORT CAN BE MORE EFFICIENT. added an assert that buffer properties (num_records, record_length) are consistent between invocations. Indeed, they are not necessarily consistent. Fix: re-allocate the sort buffer if properties change. mysql-test/r/partition.result: New tests. mysql-test/t/partition.test: New tests. sql/filesort.cc: If we already have allocated a sort buffer in a previous execution, then verify that it is big enough for the current one. sql/table.h: Add sort_keys_size; Number of bytes allocated for the sort_keys buffer. --- mysql-test/t/partition.test | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/partition.test b/mysql-test/t/partition.test index 341e8780b2b..134bbd0527d 100644 --- a/mysql-test/t/partition.test +++ b/mysql-test/t/partition.test @@ -2218,4 +2218,49 @@ INSERT INTO t1 VALUES(0); DROP TABLE t1; SET GLOBAL myisam_use_mmap=default; +--echo # +--echo # Bug#13580775 ASSERTION FAILED: RECORD_LENGTH == M_RECORD_LENGTH, +--echo # FILE FILESORT_UTILS.CC +--echo # + +CREATE TABLE t1 ( + a INT PRIMARY KEY, + b INT, + c CHAR(1), + d INT, + KEY (c,d) +) PARTITION BY KEY () PARTITIONS 1; + +INSERT INTO t1 VALUES (1,1,'a',1), (2,2,'a',1); + +SELECT 1 FROM t1 WHERE 1 IN +(SELECT group_concat(b) + FROM t1 + WHERE c > geomfromtext('point(1 1)') + GROUP BY b +); + +DROP TABLE t1; + +--echo # +--echo # Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP +--echo # + +CREATE TABLE t1 ( + a INT, + b MEDIUMINT, + c VARCHAR(300) CHARACTER SET hp8 COLLATE hp8_bin, + PRIMARY KEY (a,c(299))) +ENGINE=myisam +PARTITION BY LINEAR KEY () PARTITIONS 2; + +INSERT INTO t1 VALUES (1,2,'test'), (2,3,'hi'), (4,5,'bye'); +SELECT 1 FROM t1 WHERE b < SOME +( SELECT 1 FROM t1 WHERE a >= 1 + GROUP BY b WITH ROLLUP + HAVING b > geomfromtext("") +); + +DROP TABLE t1; + --echo End of 5.1 tests -- cgit v1.2.1 From 7f0f18cd6ecd5a40f45393bfcc678350855f1513 Mon Sep 17 00:00:00 2001 From: Gopal Shankar Date: Mon, 30 Jan 2012 11:57:33 +0530 Subject: Bug#13105873 :Valgrind Warning: CRASH IN FOREIGN KEY HANDLING ON SUBSEQUENT CREATE TABLE IF NOT EXISTS PROBLEM: -------- Consider a SP routine which does CREATE TABLE with REFERENCES clause. The first call to this routine invokes parser and the parsed items are cached, so as to avoid parsing for the second execution of the routine. It is obsevered that valgrind reports a warning upon read of thd->lex->alter_info->key_list->Foreign_key object, which seem to be pointing to a invalid memory address during second time execution of the routine. Accessing this object theoretically could cause a crash. ANALYSIS: --------- The problem stems from the fact that for some reason elements of ref_columns list in thd->lex->alter_info-> key_list->Foreign_key object are changed to point to objects allocated on runtime memory root. During the first execution of routine we create a copy of thd->lex->alter_info object. As part of this process we create a clones of objects in Alter_info::key_list and of Foreign_key object in particular. Then Foreign_key object is cloned for some reason we perform shallow copies of both Foreign_key::ref_columns and Foreign_key::columns list. So new instance of Foreign_key object starts to SHARE contents of ref_columns and columns list with the original instance. After that as part of cloning process we call list_copy_and_replace_each_value() for elements of ref_columns list. As result ref_columns lists in both original and cloned Foreign_key object start to contain pointers to Key_part_spec objects allocated on runtime memory root because of shallow copy. So when we start copying of thd->lex->alter_info object during the second execution of stored routine we indeed encounter pointer to the Key_part_spec object allocated on runtime mem-root which was cleared during at the end of previous execution. This is done in sp_head::execute(), by a call to free_root(&execute_mem_root,MYF(0)); As result we get valgrind warnings about accessing unreferenced memory. FIX: ---- The safest solution to this problem is to fix Foreign_key(Foreign_key, MEM_ROOT) constructor to do a deep copy of columns lists, similar to Key(Key, MEM_ROOT) constructor. --- mysql-test/t/sp-bugs.test | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/sp-bugs.test b/mysql-test/t/sp-bugs.test index fe52632c784..a23ccea8189 100644 --- a/mysql-test/t/sp-bugs.test +++ b/mysql-test/t/sp-bugs.test @@ -138,4 +138,28 @@ DROP FUNCTION db1.f1; DROP TABLE db1.t1; DROP DATABASE db1; DROP DATABASE db2; + +--echo # +--echo # Bug#13105873:valgrind warning:possible crash in foreign +--echo # key handling on subsequent create table if not exists +--echo # + +--disable_warnings +DROP DATABASE IF EXISTS testdb; +--enable_warnings +CREATE DATABASE testdb; +USE testdb; +CREATE TABLE t1 (id1 INT PRIMARY KEY); +DELIMITER $; +CREATE PROCEDURE `p1`() +BEGIN + CREATE TABLE IF NOT EXISTS t2(id INT PRIMARY KEY, + CONSTRAINT FK FOREIGN KEY (id) REFERENCES t1( id1 )); +END$ +DELIMITER ;$ +CALL p1(); +--echo # below stmt should not return valgrind warnings +CALL p1(); +DROP DATABASE testdb; + --echo End of 5.1 tests -- cgit v1.2.1 From 52357198d0296e4c98551932ccf52ecb29adb85c Mon Sep 17 00:00:00 2001 From: Ashish Agarwal Date: Wed, 1 Feb 2012 11:19:53 +0530 Subject: BUG#11756869 - 48848: MYISAMCHK DOING SORT RECOVER IN CERTAIN CASES RESETS DATA POINTER TO SMAL ISSUE: Myisamchk doing sort recover on a table reduces data_file_length. Maximum size of data file decreases, lesser number of rows are stored. SOLUTION: Size of data_file_length is fixed to the original length. --- mysql-test/t/myisam.test | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/myisam.test b/mysql-test/t/myisam.test index 4abd7dd2b1b..9c79669c999 100644 --- a/mysql-test/t/myisam.test +++ b/mysql-test/t/myisam.test @@ -1645,4 +1645,20 @@ DROP TABLE t1; SET myisam_sort_buffer_size=@@global.myisam_sort_buffer_size; SET myisam_repair_threads=@@global.myisam_repair_threads; +--echo # +--echo # BUG 11756869 - 48848: MYISAMCHK DOING SORT RECOVER IN CERTAIN +--echo # CASES RESETS DATA POINTER TO SMAL +--echo # + +CREATE TABLE t1(a INT, KEY(a)); +ALTER TABLE t1 DISABLE KEYS; +let $MYSQLD_DATADIR= `select @@datadir`; +SET @before:= (SELECT MAX_DATA_LENGTH FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='t1' AND TABLE_SCHEMA='test'); +FLUSH TABLES; +--replace_result $MYSQLD_DATADIR MYSQLD_DATADIR +--exec $MYISAMCHK -sn $MYSQLD_DATADIR/test/t1 +SET @after:= (SELECT MAX_DATA_LENGTH FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='t1' AND TABLE_SCHEMA='test'); +SELECT @before=@after; +DROP TABLE t1; + --echo End of 5.1 tests -- cgit v1.2.1 From 9ada2f8ec5d29c036bcd185a411f64eea17d8132 Mon Sep 17 00:00:00 2001 From: Martin Hansson Date: Tue, 7 Feb 2012 14:16:09 +0100 Subject: Bug #11765810 58813: SERVER THREAD HANGS WHEN JOIN + WHERE + GROUP BY IS EXECUTED TWICE FROM P This bug is a duplicate of bug 12567331, which was pushed to the optimizer backporting tree on 2011-06-11. This is just a back-port of the fix. Both test cases are included as they differ somewhat. --- mysql-test/t/join_outer.test | 58 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) (limited to 'mysql-test/t') diff --git a/mysql-test/t/join_outer.test b/mysql-test/t/join_outer.test index 3251ff292b6..1ba29fdd4cf 100644 --- a/mysql-test/t/join_outer.test +++ b/mysql-test/t/join_outer.test @@ -1010,4 +1010,62 @@ GROUP BY t2.f1, t2.f2; DROP TABLE t1,t2; + +--echo +--echo # BUG#12567331 - INFINITE LOOP WHEN RESOLVING AN ALIASED COLUMN +--echo # USED IN GROUP BY +--echo +CREATE TABLE t1 ( + col_varchar_1024_latin1_key varchar(1024), + col_varchar_10_latin1 varchar(10), + col_int int(11), + pk int(11) +); +CREATE TABLE t2 ( + col_int_key int(11), + col_int int(11), + pk int(11) +); + +PREPARE prep_stmt_9846 FROM ' +SELECT alias1.pk AS field1 FROM +t1 AS alias1 +LEFT JOIN +( + t2 AS alias2 + RIGHT JOIN + ( + t2 AS alias3 + JOIN t1 AS alias4 + ON 1 + ) + ON 1 +) +ON 1 +GROUP BY field1'; +execute prep_stmt_9846; +execute prep_stmt_9846; +drop table t1,t2; + +--echo # +--echo # Bug #11765810 58813: SERVER THREAD HANGS WHEN JOIN + WHERE + GROUP BY +--echo # IS EXECUTED TWICE FROM P +--echo # +CREATE TABLE t1 ( a INT ) ENGINE = MYISAM; +INSERT INTO t1 VALUES (1); +PREPARE prep_stmt FROM ' + SELECT 1 AS f FROM t1 + LEFT JOIN t1 t2 + RIGHT JOIN t1 t3 + JOIN t1 t4 + ON 1 + ON 1 + ON 1 + GROUP BY f'; +EXECUTE prep_stmt; +EXECUTE prep_stmt; + +DROP TABLE t1; + + --echo End of 5.1 tests -- cgit v1.2.1