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

rocksdb.tbl_opt_data_index_dir fails, wrong error code

Details

    • 10.2.6-2

    Description

      Running 

      ./mtr  rocksdb.tbl_opt_data_index_dir

      produces this error:

      rocksdb.tbl_opt_data_index_dir           [ fail ]
      		 
              Test ended at 2017-03-16 11:11:07
      		 
       
      		 
      CURRENT_TEST: rocksdb.tbl_opt_data_index_dir
      		 
      mysqltest: At line 14: query 'CREATE TABLE t1 (a INT PRIMARY KEY, b CHAR(8)) ENGINE=rocksdb DATA DIRECTORY = '/foo/bar/data'' failed with wrong errno 1005: 'Can't create table `test`.`t1` (errno: 198 "Unknown error 198")', instead of 1296...
      		 
       
      		 
      The result from queries just before the failure was:
      		 
      DROP TABLE IF EXISTS t1;
      		 
      CREATE TABLE t1 (a INT PRIMARY KEY, b CHAR(8)) ENGINE=rocksdb DATA DIRECTORY = '/foo/bar/data';
      		 
       
      		 
       - saving '/home/psergey/dev-git/10.2-mariarocks/mysql-test/var/log/rocksdb.tbl_opt_data_index_dir/' to '/home/psergey/dev-git/10.2-mariarocks/mysql-test/var/log/rocksdb.tbl_opt_data_index_dir/'
      		 
      --------------------------------------------------------------------------
      		 
      The servers were restarted 0 times
      		 
      Spent 0.000 of 4 seconds executing testcases
      		 
       
      		 
      Failure: Failed 1/1 tests, 0.00% were successful.
      		 
       
      		 
      Failing test(s): rocksdb.tbl_opt_data_index_dir

      Attachments

        Issue Links

          is part of

          Task - A task that needs to be done. MDEV-9658 Make MyRocks in MariaDB stable

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            psergei Sergei Petrunia added a comment -

            Some investigation:
            Debugging this statement:

            MariaDB [test]>  CREATE TABLE t1 (a INT PRIMARY KEY, b CHAR(8)) ENGINE=rocksdb DATA DIRECTORY = '/foo/bar/data';


              Breakpoint 1, myrocks::ha_rocksdb::create (this=0x7fffe886f088, name=0x7ffff7eecf50 "./test/t1", 
              table_arg=0x7ffff7eea720, create_info=0x7ffff7eed550) at /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/ha_rocksdb.cc:5410
            		 
            (gdb) fini
            		 
              Run till exit from #0  myrocks::ha_rocksdb::create (this=0x7fffe886f088, name=0x7ffff7eecf50 "./test/t1", table_arg=0x7ffff7eea720, create_info=0x7ffff7eed550) at /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/ha_rocksdb.cc:5410
            		 
              0x0000555555d6bfdc in handler::ha_create (this=0x7fffe886f088, name=0x7ffff7eecf50 "./test/t1", form=0x7ffff7eea720, info_arg=0x7ffff7eed550) at /home/psergey/dev-git/10.2-mariarocks/sql/handler.cc:4368
            		 
              Value returned is $6 = 198

            The 198 value is HA_ERR_ROCKSDB_TABLE_DATA_DIRECTORY_NOT_SUPPORTED.

            Then, something odd happens.
            Execution reaches ha_rocksdb::get_error_message which provides the right error
            message

              Breakpoint 2, myrocks::ha_rocksdb::get_error_message (this=0x7fffe886f088, error=198, buf=0x7ffff7ee98d0) at 
              /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/ha_rocksdb.cc:4831
            		 
            (gdb) next
            		 
            (gdb) next
            		 
            (gdb) p buf->c_ptr()
            		 
              $13 = 0x7fffe888f1b0 "Specifying DATA DIRECTORY for an individual table is not supported."

            After which we end up in my_error:

              my_error (nr=1296, MyFlags=2048) at /home/psergey/dev-git/10.2-mariarocks/mysys/my_error.c:109
            		 
            (gdb) print ebuff
            		 
              $18 = "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB\000\..."

            ... but the error is not passed over to the client.
            Is this because there was another call before to my_error() made after ha_rocksdb::create but before ha_rocksdb::get_error_message() ?

            psergei Sergei Petrunia added a comment - Some investigation: Debugging this statement: MariaDB [test]> CREATE TABLE t1 (a INT PRIMARY KEY, b CHAR(8)) ENGINE=rocksdb DATA DIRECTORY = '/foo/bar/data'; Breakpoint 1, myrocks::ha_rocksdb::create (this=0x7fffe886f088, name=0x7ffff7eecf50 "./test/t1", table_arg=0x7ffff7eea720, create_info=0x7ffff7eed550) at /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/ha_rocksdb.cc:5410 (gdb) fini Run till exit from #0 myrocks::ha_rocksdb::create (this=0x7fffe886f088, name=0x7ffff7eecf50 "./test/t1", table_arg=0x7ffff7eea720, create_info=0x7ffff7eed550) at /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/ha_rocksdb.cc:5410 0x0000555555d6bfdc in handler::ha_create (this=0x7fffe886f088, name=0x7ffff7eecf50 "./test/t1", form=0x7ffff7eea720, info_arg=0x7ffff7eed550) at /home/psergey/dev-git/10.2-mariarocks/sql/handler.cc:4368 Value returned is $6 = 198 The 198 value is HA_ERR_ROCKSDB_TABLE_DATA_DIRECTORY_NOT_SUPPORTED. Then, something odd happens. Execution reaches ha_rocksdb::get_error_message which provides the right error message Breakpoint 2, myrocks::ha_rocksdb::get_error_message (this=0x7fffe886f088, error=198, buf=0x7ffff7ee98d0) at /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/ha_rocksdb.cc:4831 (gdb) next (gdb) next (gdb) p buf->c_ptr() $13 = 0x7fffe888f1b0 "Specifying DATA DIRECTORY for an individual table is not supported." After which we end up in my_error: my_error (nr=1296, MyFlags=2048) at /home/psergey/dev-git/10.2-mariarocks/mysys/my_error.c:109 (gdb) print ebuff $18 = "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB\000\..." ... but the error is not passed over to the client. Is this because there was another call before to my_error() made after ha_rocksdb::create but before ha_rocksdb::get_error_message() ?
            psergei Sergei Petrunia added a comment -

            Debugging the same query

            CREATE TABLE t1 (a INT PRIMARY KEY, b CHAR(8)) 
            ENGINE=rocksdb DATA DIRECTORY = '/foo/bar/data';

            query, stop in ha_create_table():

            ha_rocksdb::create() = 198.

            198 is MyRocks' internal HA_ERR_ROCKSDB_TABLE_DATA_DIRECTORY_NOT_SUPPORTED.

            then it calls:

              my_error(ER_CANT_CREATE_TABLE, MYF(0), db, table_name, error);

            ER_CANT_CREATE_TABLE is defined as:

               eng "Can't create table %`s.%`s (errno: %M)"

            for %M format my_error calls my_vsnprintf_ex, my_strerror.

            my_strerror() checks if the error is in [HA_ERR_FIRST, HA_ERR_LAST] range (no), and then calls strerror_r() which returns "Unknown error 198".

            Now, this already is weird.
            Is ha_rocksdb::create() allowed to return custom storage-engine error codes?
            It is apparent that error handling code doesn't expect that.

            psergei Sergei Petrunia added a comment - Debugging the same query CREATE TABLE t1 (a INT PRIMARY KEY, b CHAR(8)) ENGINE=rocksdb DATA DIRECTORY = '/foo/bar/data'; query, stop in ha_create_table(): ha_rocksdb::create() = 198. 198 is MyRocks' internal HA_ERR_ROCKSDB_TABLE_DATA_DIRECTORY_NOT_SUPPORTED. then it calls: my_error(ER_CANT_CREATE_TABLE, MYF(0), db, table_name, error); ER_CANT_CREATE_TABLE is defined as: eng "Can't create table %`s.%`s (errno: %M)" for %M format my_error calls my_vsnprintf_ex, my_strerror. my_strerror() checks if the error is in [HA_ERR_FIRST, HA_ERR_LAST] range (no), and then calls strerror_r() which returns "Unknown error 198". Now, this already is weird. Is ha_rocksdb::create() allowed to return custom storage-engine error codes? It is apparent that error handling code doesn't expect that.
            psergei Sergei Petrunia added a comment -

            ... But right after the my_error call, we have

                table.file->print_error(error, MYF(ME_JUST_WARNING));

            error here is ha_create() return code, so now it is assumed that the error
            is from storage-engine defined error codes after all?

            Ok I step in there, get to the get_error_message() call,
            see ha_rocksdb::get_error_message() produce the error message.

            Then things get weird. Execution arrives to line 3630:

            	else
            		 
                    {
            		 
            =>        SET_FATAL_ERROR;
            		 
            	  my_error(ER_GET_ERRMSG, errflag, error, str.c_ptr(), engine);
            		 
                    }
            		 
                  }
            		 
                  else
            		 
                    my_error(ER_GET_ERRNO, errflag, error, table_type());
            		 
                  DBUG_VOID_RETURN;
            		 
                }

            SET_FATAL_ERROR is defined as:

            #define SET_FATAL_ERROR fatal_error=1

            where fatal_error is a local variable.

            Question: what's the point of calling SET_FATAL_ERROR if we then proceed to the DBUG_VOID_RETURN ?

            psergei Sergei Petrunia added a comment - ... But right after the my_error call, we have table.file->print_error(error, MYF(ME_JUST_WARNING)); error here is ha_create() return code, so now it is assumed that the error is from storage-engine defined error codes after all? Ok I step in there, get to the get_error_message() call, see ha_rocksdb::get_error_message() produce the error message. Then things get weird. Execution arrives to line 3630: else { => SET_FATAL_ERROR; my_error(ER_GET_ERRMSG, errflag, error, str.c_ptr(), engine); } } else my_error(ER_GET_ERRNO, errflag, error, table_type()); DBUG_VOID_RETURN; } SET_FATAL_ERROR is defined as: #define SET_FATAL_ERROR fatal_error=1 where fatal_error is a local variable. Question: what's the point of calling SET_FATAL_ERROR if we then proceed to the DBUG_VOID_RETURN ?
            psergei Sergei Petrunia added a comment -

            ... anyway, we get into the 

               my_error(ER_GET_ERRMSG, errflag, error, str.c_ptr(), engine);

            call,
            which produces a 

             
            "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB\000

            The condition is eventually pushed into the list of statement' warnings:

             
            (gdb) wher
            		 
              #0  Warning_info::push_warning (this=0x7fffe881b288, thd=0x7fffe8816070, sql_errno=1296, sqlstate=0x5555565c67cd "HY000", level=Sql_condition::WARN_LEVEL_WARN, msg=0x7ffff7ee95a0 "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB") at /home/psergey/dev-git/10.2-mariarocks/sql/sql_error.cc:713
            		 
              #1  0x0000555555abdba1 in Diagnostics_area::push_warning (this=0x7fffe881b058, thd=0x7fffe8816070, sql_errno_arg=1296, sqlstate=0x5555565c67cd "HY000", level=Sql_condition::WARN_LEVEL_WARN, msg=0x7ffff7ee95a0 "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB") at /home/psergey/dev-git/10.2-mariarocks/sql/sql_error.h:849
            		 
              #2  0x0000555555aae103 in THD::raise_condition (this=0x7fffe8816070, sql_errno=1296, sqlstate=0x5555565c67cd "HY000", level=Sql_condition::WARN_LEVEL_WARN, msg=0x7ffff7ee95a0 "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB") at /home/psergey/dev-git/10.2-mariarocks/sql/sql_class.cc:1144
            		 
              #3  0x0000555555a1baed in my_message_sql (error=1296, str=0x7ffff7ee95a0 "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB", MyFlags=2048) at /home/psergey/dev-git/10.2-mariarocks/sql/mysqld.cc:3628
            		 
              #4  0x00005555564cdd9c in my_error (nr=1296, MyFlags=2048) at /home/psergey/dev-git/10.2-mariarocks/mysys/my_error.c:125
            		 
              #5  0x0000555555d6a72b in handler::print_error (this=0x7fffe8872088, error=198, errflag=2048) at /home/psergey/dev-git/10.2-mariarocks/sql/handler.cc:3631

            psergei Sergei Petrunia added a comment - ... anyway, we get into the my_error(ER_GET_ERRMSG, errflag, error, str.c_ptr(), engine); call, which produces a "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB\000 The condition is eventually pushed into the list of statement' warnings: (gdb) wher #0 Warning_info::push_warning (this=0x7fffe881b288, thd=0x7fffe8816070, sql_errno=1296, sqlstate=0x5555565c67cd "HY000", level=Sql_condition::WARN_LEVEL_WARN, msg=0x7ffff7ee95a0 "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB") at /home/psergey/dev-git/10.2-mariarocks/sql/sql_error.cc:713 #1 0x0000555555abdba1 in Diagnostics_area::push_warning (this=0x7fffe881b058, thd=0x7fffe8816070, sql_errno_arg=1296, sqlstate=0x5555565c67cd "HY000", level=Sql_condition::WARN_LEVEL_WARN, msg=0x7ffff7ee95a0 "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB") at /home/psergey/dev-git/10.2-mariarocks/sql/sql_error.h:849 #2 0x0000555555aae103 in THD::raise_condition (this=0x7fffe8816070, sql_errno=1296, sqlstate=0x5555565c67cd "HY000", level=Sql_condition::WARN_LEVEL_WARN, msg=0x7ffff7ee95a0 "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB") at /home/psergey/dev-git/10.2-mariarocks/sql/sql_class.cc:1144 #3 0x0000555555a1baed in my_message_sql (error=1296, str=0x7ffff7ee95a0 "Got error 198 'Specifying DATA DIRECTORY for an individual table is not supported.' from ROCKSDB", MyFlags=2048) at /home/psergey/dev-git/10.2-mariarocks/sql/mysqld.cc:3628 #4 0x00005555564cdd9c in my_error (nr=1296, MyFlags=2048) at /home/psergey/dev-git/10.2-mariarocks/mysys/my_error.c:125 #5 0x0000555555d6a72b in handler::print_error (this=0x7fffe8872088, error=198, errflag=2048) at /home/psergey/dev-git/10.2-mariarocks/sql/handler.cc:3631
            psergei Sergei Petrunia added a comment -

            Discussed with serg.

            Conclusions:

            • return HA_WRONG_CREATE_OPTION as error
            • also produce a warning with text
            psergei Sergei Petrunia added a comment - Discussed with serg . Conclusions: return HA_WRONG_CREATE_OPTION as error also produce a warning with text

            People

              psergei Sergei Petrunia
              psergei Sergei Petrunia
              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.