mariadb/mysql-test/r/not_embedded_server.result
Jorgen Loland 1945734c2d Bug#54812: assert in Diagnostics_area::set_ok_status
during EXPLAIN

Before the patch, send_eof() of some subclasses of 
select_result (e.g., select_send::send_eof()) could 
handle being called after an error had occured while others 
could not. The methods that were not well-behaved would trigger
an ASSERT on debug builds. Release builds were not affected.

Consider the following query as an example for how the ASSERT
could be triggered:

A user without execute privilege on f() does
   SELECT MAX(key1) INTO @dummy FROM t1 WHERE f() < 1;
resulting in "ERROR 42000: execute command denied to user..." 

The server would end the query by calling send_eof(). The 
fact that the error had occured would make the ASSERT trigger. 

select_dumpvar::send_eof() was the offending method in the
bug report, but the problem also applied to other 
subclasses of select_result. This patch uniforms send_eof() 
of all subclasses of select_result to handle being called 
after an error has occured. 

mysql-test/r/not_embedded_server.result:
  Added test for BUG#54812
mysql-test/t/not_embedded_server.test:
  Added test for BUG#54812
sql/sql_class.cc:
  send_eof() of all subclasses of select_result can now handle being
  called after an error has occured.
sql/sql_insert.cc:
  send_eof() of all subclasses of select_result can now handle being
  called after an error has occured.
  Also fix call to abort() in select_create::send_eof(), which was supposed to abort the result set, not terminate the server. This call to abort() should have been changed when the function was renamed from abort_result_set() but was forgotten. New test case added by BUG#54812 covered this line and terminated server.
sql/sql_prepare.cc:
  send_eof() of all subclasses of select_result can now handle being
  called after an error has occured.
sql/sql_update.cc:
  send_eof() of all subclasses of select_result can now handle being
  called after an error has occured.
2010-11-15 16:18:04 +01:00

45 lines
1.6 KiB
Text

call mtr.add_suppression("Can't open and lock privilege tables: Table 'host' was not locked with LOCK TABLES");
SHOW VARIABLES like 'slave_skip_errors';
Variable_name Value
slave_skip_errors OFF
#
# WL#4284: Transactional DDL locking
#
# FLUSH PRIVILEGES should not implicitly unlock locked tables.
#
drop table if exists t1;
create table t1 (c1 int);
lock tables t1 read;
flush privileges;
ERROR HY000: Table 'host' was not locked with LOCK TABLES
unlock tables;
drop table t1;
#
# Bug#54812: assert in Diagnostics_area::set_ok_status during EXPLAIN
#
CREATE USER nopriv_user@localhost;
connection: default
DROP TABLE IF EXISTS t1,t2,t3;
DROP FUNCTION IF EXISTS f;
CREATE TABLE t1 (key1 INT PRIMARY KEY);
CREATE TABLE t2 (key2 INT);
INSERT INTO t1 VALUES (1),(2);
CREATE FUNCTION f() RETURNS INT RETURN 1;
GRANT FILE ON *.* TO 'nopriv_user'@'localhost';
FLUSH PRIVILEGES;
connection: con1
SELECT MAX(key1) FROM t1 WHERE f() < 1 INTO OUTFILE 'mytest';
ERROR 42000: execute command denied to user 'nopriv_user'@'localhost' for routine 'test.f'
INSERT INTO t2 SELECT MAX(key1) FROM t1 WHERE f() < 1;
ERROR 42000: execute command denied to user 'nopriv_user'@'localhost' for routine 'test.f'
SELECT MAX(key1) INTO @dummy FROM t1 WHERE f() < 1;
ERROR 42000: execute command denied to user 'nopriv_user'@'localhost' for routine 'test.f'
CREATE TABLE t3 (i INT) AS SELECT MAX(key1) FROM t1 WHERE f() < 1;
ERROR 42000: execute command denied to user 'nopriv_user'@'localhost' for routine 'test.f'
connection: default
DROP TABLE t1,t2;
DROP FUNCTION f;
DROP USER nopriv_user@localhost;
#
# End Bug#54812
#