mariadb/mysql-test/main/error_simulation.result

131 lines
4.1 KiB
Text
Raw Normal View History

CREATE TABLE t1 (
a varchar(32) character set utf8 collate utf8_bin NOT NULL,
b varchar(32) character set utf8 collate utf8_bin NOT NULL )
ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO t1 VALUES
('AAAAAAAAAA','AAAAAAAAAA'), ('AAAAAAAAAB','AAAAAAAAAB '),
('AAAAAAAAAB','AAAAAAAAAB'), ('AAAAAAAAAC','AAAAAAAAAC'),
('AAAAAAAAAD','AAAAAAAAAD'), ('AAAAAAAAAE','AAAAAAAAAE'),
('AAAAAAAAAF','AAAAAAAAAF'), ('AAAAAAAAAG','AAAAAAAAAG'),
('AAAAAAAAAH','AAAAAAAAAH'), ('AAAAAAAAAI','AAAAAAAAAI'),
('AAAAAAAAAJ','AAAAAAAAAJ'), ('AAAAAAAAAK','AAAAAAAAAK');
set tmp_table_size=1024;
SET @saved_dbug = @@SESSION.debug_dbug;
set session debug_dbug="+d,raise_error";
SELECT MAX(a) FROM t1 GROUP BY a,b;
ERROR 23000: Can't write; duplicate key in table '(temporary)'
set tmp_table_size=default;
DROP TABLE t1;
#
# Bug #50946: fast index creation still seems to copy the table
#
CREATE TABLE t1 (a INT(100) NOT NULL);
INSERT INTO t1 VALUES (1), (0), (2);
SET SESSION debug_dbug='+d,alter_table_only_index_change';
ALTER TABLE t1 ADD INDEX a(a);
SET debug_dbug= @saved_dbug;
SHOW CREATE TABLE t1;
Table Create Table
t1 CREATE TABLE `t1` (
`a` int(100) NOT NULL,
KEY `a` (`a`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
SELECT * FROM t1;
a
0
1
2
DROP TABLE t1;
#
Bug #42064: low memory crash when importing hex strings, in Item_hex_string::Item_hex_string The status of memory allocation in the Lex_input_stream (called from the Parser_state constructor) was not checked which led to a parser crash in case of the out-of-memory error. The solution is to introduce new init() member function in Parser_state and Lex_input_stream so that status of memory allocation can be returned to the caller. mysql-test/r/error_simulation.result: Added a test case for bug #42064. mysql-test/t/error_simulation.test: Added a test case for bug #42064. mysys/my_alloc.c: Added error injection code for the regression test. mysys/my_malloc.c: Added error injection code for the regression test. mysys/safemalloc.c: Added error injection code for the regression test. sql/event_data_objects.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/mysqld.cc: Added error injection code for the regression test. sql/sp.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_lex.cc: Moved memory allocation from constructor to the separate init() member function. Added error injection code for the regression test. sql/sql_lex.h: Moved memory allocation from constructor to the separate init() member function. sql/sql_parse.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_partition.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_prepare.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_trigger.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_view.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures.. sql/thr_malloc.cc: Added error injection code for the regression test.
2010-05-21 13:23:48 +02:00
# Bug#42064: low memory crash when importing hex strings, in Item_hex_string::Item_hex_string
#
CREATE TABLE t1(a BLOB);
SET SESSION debug_dbug="+d,bug42064_simulate_oom";
Bug #42064: low memory crash when importing hex strings, in Item_hex_string::Item_hex_string The status of memory allocation in the Lex_input_stream (called from the Parser_state constructor) was not checked which led to a parser crash in case of the out-of-memory error. The solution is to introduce new init() member function in Parser_state and Lex_input_stream so that status of memory allocation can be returned to the caller. mysql-test/r/error_simulation.result: Added a test case for bug #42064. mysql-test/t/error_simulation.test: Added a test case for bug #42064. mysys/my_alloc.c: Added error injection code for the regression test. mysys/my_malloc.c: Added error injection code for the regression test. mysys/safemalloc.c: Added error injection code for the regression test. sql/event_data_objects.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/mysqld.cc: Added error injection code for the regression test. sql/sp.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_lex.cc: Moved memory allocation from constructor to the separate init() member function. Added error injection code for the regression test. sql/sql_lex.h: Moved memory allocation from constructor to the separate init() member function. sql/sql_parse.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_partition.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_prepare.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_trigger.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_view.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures.. sql/thr_malloc.cc: Added error injection code for the regression test.
2010-05-21 13:23:48 +02:00
INSERT INTO t1 VALUES("");
Got one of the listed errors
SET debug_dbug= @saved_dbug;
Bug #42064: low memory crash when importing hex strings, in Item_hex_string::Item_hex_string The status of memory allocation in the Lex_input_stream (called from the Parser_state constructor) was not checked which led to a parser crash in case of the out-of-memory error. The solution is to introduce new init() member function in Parser_state and Lex_input_stream so that status of memory allocation can be returned to the caller. mysql-test/r/error_simulation.result: Added a test case for bug #42064. mysql-test/t/error_simulation.test: Added a test case for bug #42064. mysys/my_alloc.c: Added error injection code for the regression test. mysys/my_malloc.c: Added error injection code for the regression test. mysys/safemalloc.c: Added error injection code for the regression test. sql/event_data_objects.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/mysqld.cc: Added error injection code for the regression test. sql/sp.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_lex.cc: Moved memory allocation from constructor to the separate init() member function. Added error injection code for the regression test. sql/sql_lex.h: Moved memory allocation from constructor to the separate init() member function. sql/sql_parse.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_partition.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_prepare.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_trigger.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures. sql/sql_view.cc: Use the new init() member function of Parser_state and check its return value to handle memory allocation failures.. sql/thr_malloc.cc: Added error injection code for the regression test.
2010-05-21 13:23:48 +02:00
DROP TABLE t1;
#
# Bug#41660: Sort-index_merge for non-first join table may require
# O(#scans) memory
#
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (0), (1), (2), (3), (4), (5), (6), (7), (8), (9);
CREATE TABLE t2 (a INT, b INT, filler CHAR(100), KEY(a), KEY(b));
INSERT INTO t2 SELECT 1000, 1000, 'filler' FROM t1 A, t1 B, t1 C;
INSERT INTO t2 VALUES (1, 1, 'data');
# the example query uses LEFT JOIN only for the sake of being able to
# demonstrate the issue with a very small dataset. (left outer join
# disables the use of join buffering, so we get the second table
# re-scanned for every record in the outer table. if we used inner join,
# we would need to have thousands of records and/or more columns in both
# tables so that the join buffer is filled and re-scans are triggered).
SET @save_optimizer_switch=@@optimizer_switch;
SET optimizer_switch='outer_join_with_cache=off';
SET SESSION debug_dbug= '+d,only_one_Unique_may_be_created';
EXPLAIN
SELECT * FROM t1 LEFT JOIN t2 ON ( t2.a < 10 OR t2.b < 10 );
id select_type table type possible_keys key key_len ref rows Extra
x x x x x x x x x
x x x x x x x x x Using sort_union(a,b); Using where
SELECT * FROM t1 LEFT JOIN t2 ON ( t2.a < 10 OR t2.b < 10 );
a a b filler
0 1 1 data
1 1 1 data
2 1 1 data
3 1 1 data
4 1 1 data
5 1 1 data
6 1 1 data
7 1 1 data
8 1 1 data
9 1 1 data
SET debug_dbug= @saved_dbug;
SET optimizer_switch=@save_optimizer_switch;
DROP TABLE t1, t2;
#
Bug#11747970 34660: CRASH WHEN FEDERATED TABLE LOSES CONNECTION DURING INSERT ... SELECT Problematic query: insert ignore into `t1_federated` (`c1`) select `c1` from `t1_local` a where not exists (select 1 from `t1_federated` b where a.c1 = b.c1); When this query is killed in another connection it could lead to crash. The problem is follwing: An attempt to obtain table statistics for subselect table in killed query fails with an error. So JOIN::optimize() for subquery is failed but it does not prevent further subquery evaluation. At the first subquery execution JOIN::optimize() is called (see subselect_single_select_engine::exec()) and fails with an error. 'executed' flag is set to TRUE and it prevents further subquery evaluation. At the second call JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE and in case of uncacheable subquery the 'executed' flag is set to FALSE before subquery evaluation. So we loose 'optimize stage' error indication (see subselect_single_select_engine::exec()). In other words 'executed' flag is used for two purposes, for error indication at JOIN::optimize() stage and for an indication of subquery execution. And it seems it's wrong as the flag could be reset. mysql-test/r/error_simulation.result: test case mysql-test/t/error_simulation.test: test case sql/item_subselect.cc: added new flag subselect_single_select_engine::optimize_error which is used for error detection which could happen at optimize stage. sql/item_subselect.h: added new flag subselect_single_select_engine::optimize_error sql/sql_select.cc: test case
2011-10-05 11:28:20 +02:00
# Bug#11747970 34660: CRASH WHEN FEDERATED TABLE LOSES CONNECTION DURING INSERT ... SELECT
#
CREATE TABLE t1(f1 INT, KEY(f1));
CREATE TABLE t2(f1 INT);
INSERT INTO t1 VALUES (1),(2);
INSERT INTO t2 VALUES (1),(2);
2012-01-13 15:50:02 +01:00
SET SESSION debug_dbug="+d,bug11747970_raise_error";
Bug#11747970 34660: CRASH WHEN FEDERATED TABLE LOSES CONNECTION DURING INSERT ... SELECT Problematic query: insert ignore into `t1_federated` (`c1`) select `c1` from `t1_local` a where not exists (select 1 from `t1_federated` b where a.c1 = b.c1); When this query is killed in another connection it could lead to crash. The problem is follwing: An attempt to obtain table statistics for subselect table in killed query fails with an error. So JOIN::optimize() for subquery is failed but it does not prevent further subquery evaluation. At the first subquery execution JOIN::optimize() is called (see subselect_single_select_engine::exec()) and fails with an error. 'executed' flag is set to TRUE and it prevents further subquery evaluation. At the second call JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE and in case of uncacheable subquery the 'executed' flag is set to FALSE before subquery evaluation. So we loose 'optimize stage' error indication (see subselect_single_select_engine::exec()). In other words 'executed' flag is used for two purposes, for error indication at JOIN::optimize() stage and for an indication of subquery execution. And it seems it's wrong as the flag could be reset. mysql-test/r/error_simulation.result: test case mysql-test/t/error_simulation.test: test case sql/item_subselect.cc: added new flag subselect_single_select_engine::optimize_error which is used for error detection which could happen at optimize stage. sql/item_subselect.h: added new flag subselect_single_select_engine::optimize_error sql/sql_select.cc: test case
2011-10-05 11:28:20 +02:00
INSERT IGNORE INTO t2 SELECT f1 FROM t1 a WHERE NOT EXISTS (SELECT 1 FROM t2 b WHERE a.f1 = b.f1);
ERROR 70100: Query execution was interrupted
SET debug_dbug= @saved_dbug;
Bug#11747970 34660: CRASH WHEN FEDERATED TABLE LOSES CONNECTION DURING INSERT ... SELECT Problematic query: insert ignore into `t1_federated` (`c1`) select `c1` from `t1_local` a where not exists (select 1 from `t1_federated` b where a.c1 = b.c1); When this query is killed in another connection it could lead to crash. The problem is follwing: An attempt to obtain table statistics for subselect table in killed query fails with an error. So JOIN::optimize() for subquery is failed but it does not prevent further subquery evaluation. At the first subquery execution JOIN::optimize() is called (see subselect_single_select_engine::exec()) and fails with an error. 'executed' flag is set to TRUE and it prevents further subquery evaluation. At the second call JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE and in case of uncacheable subquery the 'executed' flag is set to FALSE before subquery evaluation. So we loose 'optimize stage' error indication (see subselect_single_select_engine::exec()). In other words 'executed' flag is used for two purposes, for error indication at JOIN::optimize() stage and for an indication of subquery execution. And it seems it's wrong as the flag could be reset. mysql-test/r/error_simulation.result: test case mysql-test/t/error_simulation.test: test case sql/item_subselect.cc: added new flag subselect_single_select_engine::optimize_error which is used for error detection which could happen at optimize stage. sql/item_subselect.h: added new flag subselect_single_select_engine::optimize_error sql/sql_select.cc: test case
2011-10-05 11:28:20 +02:00
DROP TABLE t1,t2;
#
# End of 5.1 tests
#
BUG#11747548: DETECT ORPHAN TEMP-POOL FILES, AND HANDLE GRACEFULLY Analysis: -------- Certain queries using intrinsic temporary tables may fail due to name clashes in the file name for the temporary table when the 'temp-pool' enabled. 'temp-pool' tries to reduce the number of different filenames used for temp tables by allocating them from small pool in order to avoid problems in the Linux kernel by using a three part filename: <tmp_file_prefix>_<pid>_<temp_pool_slot_num>. The bit corresponding to the temp_pool_slot_num is set in the bit map maintained for the temp-pool when it used for the file name. It is cleared after the temp table is deleted for re-use. The 'create_tmp_table()' function call under error condition tries to clear the same bit twice by calling 'free_tmp_table()' and 'bitmap_lock_clear_bit()'. 'free_tmp_table()' does a delete of the table/file and clears the bit by calling the same function 'bitmap_lock_clear_bit()'. The issue reported can be triggered under the timing window mentioned below for an error condition while creating the temp table: a) THD1: Due to an error clears the temp pool slot number used by it by calling 'free_tmp_table'. b) THD2: In the process of creating the temp table by using an unused slot number in the bit map. c) THD1: Clears the slot number used THD2 by calling 'bitmap_lock_clear_bit()' after completing the call 'free_tmp_table'. d) THD3: Uses the slot number used the THD2 since it is freed by THD1. When it tries to create the temp file using that slot number, an error is reported since it is currently in use by THD2. [The error: Error 'Can't create/write to file '/tmp/#sql_277e_0.MYD' (Errcode: 17)'] Another issue which may occur in 5.6 and trunk is that: When the open temporary table fails after its creation(due to ulimit or OOM error), the file is not deleted. Thus further attempts to use the same slot number in the 'temp-pool' results in failure. Fix: --- a) Under the error condition calling the 'bitmap_lock_clear_bit()' function to clear the bit is unnecessary since 'free_tmp_table()' deletes the table/file and clears the bit. Hence removed the redundant call 'bitmap_lock_clear_bit()' in 'create_tmp_table()' This prevents the timing window under which the issue reported can be seen. b) If open of the temporary table fails, then the file is deleted thus allowing the temp-pool slot number to be utilized for the subsequent temporary table creation. c) Also if the attempt to create temp table fails since it already exists, the temp-pool slot for it is marked as used, to avoid the problem from re-appearing.
2014-11-24 15:54:18 +01:00
#
# BUG#11747548:DETECT ORPHAN TEMP-POOL FILES, AND HANDLE GRACEFULLY.
#
#Set up.
CREATE TABLE pid_table(pid_no INT);
CREATE TABLE t1 (a BLOB);
INSERT INTO t1 VALUES (1), (2);
#Create MYD and MYI files for intrinsic temp table.
LOAD DATA LOCAL INFILE 'pid_file' INTO TABLE pid_table;
#Reports an error since the temp file already exists.
SELECT a FROM t1 ORDER BY rand(1);
a
1
2
BUG#11747548: DETECT ORPHAN TEMP-POOL FILES, AND HANDLE GRACEFULLY Analysis: -------- Certain queries using intrinsic temporary tables may fail due to name clashes in the file name for the temporary table when the 'temp-pool' enabled. 'temp-pool' tries to reduce the number of different filenames used for temp tables by allocating them from small pool in order to avoid problems in the Linux kernel by using a three part filename: <tmp_file_prefix>_<pid>_<temp_pool_slot_num>. The bit corresponding to the temp_pool_slot_num is set in the bit map maintained for the temp-pool when it used for the file name. It is cleared after the temp table is deleted for re-use. The 'create_tmp_table()' function call under error condition tries to clear the same bit twice by calling 'free_tmp_table()' and 'bitmap_lock_clear_bit()'. 'free_tmp_table()' does a delete of the table/file and clears the bit by calling the same function 'bitmap_lock_clear_bit()'. The issue reported can be triggered under the timing window mentioned below for an error condition while creating the temp table: a) THD1: Due to an error clears the temp pool slot number used by it by calling 'free_tmp_table'. b) THD2: In the process of creating the temp table by using an unused slot number in the bit map. c) THD1: Clears the slot number used THD2 by calling 'bitmap_lock_clear_bit()' after completing the call 'free_tmp_table'. d) THD3: Uses the slot number used the THD2 since it is freed by THD1. When it tries to create the temp file using that slot number, an error is reported since it is currently in use by THD2. [The error: Error 'Can't create/write to file '/tmp/#sql_277e_0.MYD' (Errcode: 17)'] Another issue which may occur in 5.6 and trunk is that: When the open temporary table fails after its creation(due to ulimit or OOM error), the file is not deleted. Thus further attempts to use the same slot number in the 'temp-pool' results in failure. Fix: --- a) Under the error condition calling the 'bitmap_lock_clear_bit()' function to clear the bit is unnecessary since 'free_tmp_table()' deletes the table/file and clears the bit. Hence removed the redundant call 'bitmap_lock_clear_bit()' in 'create_tmp_table()' This prevents the timing window under which the issue reported can be seen. b) If open of the temporary table fails, then the file is deleted thus allowing the temp-pool slot number to be utilized for the subsequent temporary table creation. c) Also if the attempt to create temp table fails since it already exists, the temp-pool slot for it is marked as used, to avoid the problem from re-appearing.
2014-11-24 15:54:18 +01:00
#With patch, the query executes successfully.
SELECT a FROM t1 ORDER BY rand(1);
a
1
2
#cleanup
DROP TABLE t1, pid_table;
#
# MDEV-12416 OOM in create_virtual_tmp_table() makes the server crash
#
CREATE FUNCTION f1(a INT) RETURNS INT RETURN a;
SET SESSION debug_dbug="+d,simulate_create_virtual_tmp_table_out_of_memory";
SELECT f1(1);
Got one of the listed errors
DROP FUNCTION f1;
SET debug_dbug= @saved_dbug;