[MDEV-7935] CREATE TABLE ... AS SELECT ... can cause a Server crash (Assertion `0' in Protocol::end_statement) Created: 2015-04-08  Updated: 2017-03-28  Resolved: 2015-05-02

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table
Affects Version/s: 10.0.17
Fix Version/s: 10.0.18

Type: Bug Priority: Major
Reporter: Olivier Bertrand Assignee: Olivier Bertrand
Resolution: Fixed Votes: 0
Labels: verified

Issue Links:
PartOf
includes MDEV-12382 Query crashes CREATE TABLE XX AS SELE... Closed

 Description   

For instance:

create table t1 (a char(16)) engine=myisam;
 
insert into t1 values('Hello World!');
 
create table t2 engine=connect file_name='e:/truc/foo.txt' as select * from t1;

freezes the server (DEBUG version) with:

Open(a+b) error 2 on e:/truc/foo.txt: No such file or directory
 
Assertion failed: 0, file .\protocol.cc, line 522
 
 
 
This application has requested the Runtime to terminate it in an unusual way.

However, doing:

create table t2 (a char(16)) engine=connect file_name='e:/truc/foo.txt';
 
insert into t2 select * from t1;

Just issue the expected message "Open error on e:/truc/foo.txt..."
Indeed the directory 'truc' does not exist on the disk E.

This may not be specific to the CONNECT engine. It seems that when the storage engine function write_row returns in error with rc= HA_ERR_INTERNAL_ERROR, the error return is handled correctly by MariaDB but in and only in the case of "CREATE TABLE ... AS SELECT ..." at the very end of the process, when the function Protocol::end_statement is called, the thd->get_stmt_da()->status() call returns an invalid value.

Things are almost worst when using a RELEASE server because the DBUG_ASSERT not being executed, no error message is displayed but the table is silently not created.

 Comments   
Comment by Sergei Golubchik [ 2015-05-02 ]

It's a bug in the connect engine. That's what's happening:

  1. write_row fails
  2. the error status is recorded in thd->is_error()
  3. error is also propagated up the call stack
  4. because CREATE...SELECT failed, the new table is dropped
  5. ha_connect::delete_or_rename_table() invokes thd->get_stmt_da()->reset_diagnostics_area() and resets the error status in the thd!
  6. at the end of the statement the assert fires, because the status is neither OK nor ERROR.

better not to reset thd status in the engine.

Comment by Olivier Bertrand [ 2015-05-02 ]

Fixed by suppressing the resetting code.

However, the issue is that this code was added because without it an assertion was raised in some cases. Unfortunately I can't remember what were these cases. Therefore fixing it in this case will perhaps make a new crash happening on another cases.

Once more, this demonstrate the very bad use of assertion in case where a proper error message should be provided.

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