[MDEV-11930] Unexpected ER_ERROR_EVALUATING_EXPRESSION warning upon dropping database with a bad table Created: 2017-01-28  Updated: 2017-07-05  Resolved: 2017-07-05

Status: Closed
Project: MariaDB Server
Component/s: Tests, Virtual Columns
Affects Version/s: 10.2
Fix Version/s: 10.2.7

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None


 Description   

Here is the essential part of main.drop_debug test:

DROP DATABASE IF EXISTS db;
CREATE DATABASE db;
CREATE TABLE db.t1(a INT);
SET SESSION debug_dbug= "+d,bug43138";
DROP DATABASE db;
SHOW WARNINGS;
SET SESSION debug_dbug= "-d,bug43138";

It is expected to produce a warning ER_BAD_TABLE_ERROR, and so it does:

+-------+------+--------------------+
| Level | Code | Message            |
+-------+------+--------------------+
| Error | 1051 | Unknown table 't1' |
+-------+------+--------------------+
1 row in set (0.00 sec)

But if I add FLUSH TABLES, it starts producing an extra warning:

FLUSH TABLES;
DROP DATABASE IF EXISTS db;
CREATE DATABASE db;
CREATE TABLE db.t1(a INT);
SET SESSION debug_dbug= "+d,bug43138";
DROP DATABASE db;
SHOW WARNINGS;

+-------+------+---------------------------------------------------------------+
| Level | Code | Message                                                       |
+-------+------+---------------------------------------------------------------+
| Error | 1051 | Unknown table 't1'                                            |
| Error | 4027 | Got an error evaluating stored expression current_timestamp() |
+-------+------+---------------------------------------------------------------+
2 rows in set (0.00 sec)

Apparently it has something to do with virtual columns, although I don't know how they get involved here.

I can deal with the test if the result is expected, but it looks weird, so I need a confirmation.

Not reproducible on 10.0 and 10.1.



 Comments   
Comment by Sergei Golubchik [ 2017-04-03 ]

This happens, because Item_func::fix_fields() fails if thd->is_error() is set, assuming that it's the error during fix_fields() that caused it. But in this case thd->is_error() is set much earlier, before fix_fields() is called. One cannot rely on thd->is_error() in checks like that.

Comment by Sergei Golubchik [ 2017-06-23 ]

On the other hand, DBUG_EXECUTE_IF("bug43138", ...) issues an error, without setting the error variable — something that can never possibly happen otherwise. It's incorrect DBUG_EXECUTE_IF.

Generated at Thu Feb 08 07:53:45 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.