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

my_seek: Assertion `pos != (~(my_off_t) 0)' failed while using a corrupt system table

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.2, 10.3, 10.4, 10.5
    • 10.4, 10.5
    • Server
    • None

    Description

      10.2 08d0a2a8cf

      mysqld: /data/src/10.2/mysys/my_seek.c:53: my_seek: Assertion `pos != (~(my_off_t) 0)' failed.
      180904 23:25:35 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f99e9045ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x00005638218aeb9d in my_seek (fd=451, pos=18446744073709551615, whence=0, MyFlags=0) at /data/src/10.2/mysys/my_seek.c:53
      #9  0x000056382181a598 in inline_mysql_file_seek (src_file=0x563821c17030 "/data/src/10.2/storage/myisam/mi_dynrec.c", src_line=1911, file=451, pos=18446744073709551615, whence=0, flags=0) at /data/src/10.2/include/mysql/psi/mysql_file.h:1229
      #10 0x000056382181fb00 in _mi_get_block_info (info=0x7f99e80ffd60, file=451, filepos=18446744073709551615) at /data/src/10.2/storage/myisam/mi_dynrec.c:1911
      #11 0x000056382181b423 in unlink_deleted_block (info=0x7f996cfe37d0, block_info=0x7f99e80ffff0) at /data/src/10.2/storage/myisam/mi_dynrec.c:461
      #12 0x000056382181c93b in _mi_write_part_record (info=0x7f996cfe37d0, filepos=1156, length=115, next_filepos=388, record=0x7f99e8100090, reclength=0x7f99e8100088, flag=0x7f99e81000ac) at /data/src/10.2/storage/myisam/mi_dynrec.c:732
      #13 0x000056382181b007 in write_dynamic_record (info=0x7f996cfe37d0, record=0x7f996d031af8 "_<\360\004test\002sp\002\002sp\001\001\002\002\t", reclength=111) at /data/src/10.2/storage/myisam/mi_dynrec.c:371
      #14 0x000056382181ada0 in _mi_write_blob_record (info=0x7f996cfe37d0, record=0x7f996cfec6a8 "\360test", ' ' <repeats 188 times>, "sp     "...) at /data/src/10.2/storage/myisam/mi_dynrec.c:295
      #15 0x000056382183f165 in mi_write (info=0x7f996cfe37d0, record=0x7f996cfec6a8 "\360test", ' ' <repeats 188 times>, "sp     "...) at /data/src/10.2/storage/myisam/mi_write.c:146
      #16 0x00005638217fb69d in ha_myisam::write_row (this=0x7f996cfebf28, buf=0x7f996cfec6a8 "\360test", ' ' <repeats 188 times>, "sp     "...) at /data/src/10.2/storage/myisam/ha_myisam.cc:922
      #17 0x0000563821164671 in handler::ha_write_row (this=0x7f996cfebf28, buf=0x7f996cfec6a8 "\360test", ' ' <repeats 188 times>, "sp     "...) at /data/src/10.2/sql/handler.cc:5959
      #18 0x00005638212ccbdd in sp_create_routine (thd=0x7f996c000b00, type=TYPE_ENUM_PROCEDURE, sp=0x7f996cfde388) at /data/src/10.2/sql/sp.cc:1262
      #19 0x0000563820ee81ca in mysql_execute_command (thd=0x7f996c000b00) at /data/src/10.2/sql/sql_parse.cc:5711
      #20 0x0000563820eeeb4c in mysql_parse (thd=0x7f996c000b00, rawbuf=0x7f996c010fb8 "CREATE PROCEDURE sp() BEGIN END", length=31, parser_state=0x7f99e8101250, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8009
      #21 0x0000563820edc5ca in dispatch_command (command=COM_QUERY, thd=0x7f996c000b00, packet=0x7f996c0191e1 "CREATE PROCEDURE sp() BEGIN END", packet_length=31, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
      #22 0x0000563820edaf2d in do_command (thd=0x7f996c000b00) at /data/src/10.2/sql/sql_parse.cc:1378
      #23 0x000056382102c7c8 in do_handle_one_connection (connect=0x5638250e5580) at /data/src/10.2/sql/sql_connect.cc:1335
      #24 0x000056382102c555 in handle_one_connection (arg=0x5638250e5580) at /data/src/10.2/sql/sql_connect.cc:1241
      #25 0x00007f99ead1c494 in start_thread (arg=0x7f99e8102700) at pthread_create.c:333
      #26 0x00007f99e910293f in clone () from /lib/x86_64-linux-gnu/libc.so.6
       
      Query (0x7f996c010fb8): CREATE PROCEDURE sp() BEGIN END
      Connection ID (thread ID): 9
      Status: NOT_KILLED
      

      The failure happens after a crash recovery, when the system table (in this case mysql.proc) is corrupted. Apparently it's a debug assertion only. A non-debug build produces an error instead:

      MariaDB [test]> CREATE PROCEDURE sp() BEGIN END;
      ERROR 126 (HY000): Index for table './mysql/proc.MYI' is corrupt; try to repair it
      MariaDB [test]> show warnings;
      +-------+------+------------------------------------------------------------------+
      | Level | Code | Message                                                          |
      +-------+------+------------------------------------------------------------------+
      | Error |  145 | Table './mysql/proc' is marked as crashed and should be repaired |
      | Error | 1194 | Table 'proc' is marked as crashed and should be repaired         |
      | Error | 1034 | 1 client is using or hasn't closed the table properly            |
      | Error | 1034 | Found 1156 deleted space in delete link chain. Should be 1440    |
      | Error | 1034 | Found 4 deleted rows in delete link chain. Should be 5           |
      | Error | 1034 | record delete-link-chain corrupted                               |
      | Error | 1034 | Number of rows changed from 3 to 2                               |
      | Error |  126 | Index for table './mysql/proc.MYI' is corrupt; try to repair it  |
      | Error | 1304 | PROCEDURE sp already exists                                      |
      +-------+------+------------------------------------------------------------------+
      9 rows in set (0.00 sec)
      

      REPAIR TABLE helps, both for non-debug error and debug failure.

      To reproduce, unpack the attached data.tar.gz, start a 10.2 server on it (all default options will do), and run

      CREATE PROCEDURE sp() BEGIN END;
      

      or alike.

      Note:
      It would be helpful for testing purposes if the assertion failure got fixed, as it affects various crash-recovery scenarios, but I understand that it's not a high-priority task, since 10.4 switches system tables to Aria, and whatever failures we get out of it are going to be different.

      Attachments

        Activity

          People

            serg Sergei Golubchik
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

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