Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-7935

CREATE TABLE ... AS SELECT ... can cause a Server crash (Assertion `0' in Protocol::end_statement)

Details

    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.

      Attachments

        Issue Links

          includes

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12382 Query crashes CREATE TABLE XX AS SELECT * FROM YY

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik added a comment -

            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.

            serg Sergei Golubchik added a comment - It's a bug in the connect engine. That's what's happening: write_row fails the error status is recorded in thd->is_error() error is also propagated up the call stack because CREATE...SELECT failed, the new table is dropped ha_connect::delete_or_rename_table() invokes thd->get_stmt_da()->reset_diagnostics_area() and resets the error status in the thd! 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.
            bertrandop Olivier Bertrand added a comment -

            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.

            bertrandop Olivier Bertrand added a comment - 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.

            People

              bertrandop Olivier Bertrand
              bertrandop Olivier Bertrand
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.