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

Server crashes in mach_read_from_n_little_endian upon UPDATE after upgrade from 10.1

    Details

      Description

      See also MDEV-18084, MDEV-18085, MDEV-18086.

      10.2 734029fa7

      #3  <signal handler called>
      #4  0x000055e3fa5d2512 in mach_read_from_n_little_endian (buf=0x7fa5fc00a47d "", buf_size=18446744073709551612) at /data/src/10.2/storage/innobase/include/mach0data.ic:701
      #5  0x000055e3fa5d6c5f in row_mysql_read_blob_ref (len=0x7fa6682b09a0, ref=0x7fa5fc00a47d "", col_len=4) at /data/src/10.2/storage/innobase/row/row0mysql.cc:273
      #6  0x000055e3fa49f3ce in calc_row_difference (uvect=0x7fa5fc0213f0, old_row=0x7fa5fc00a478 "\377\001", new_row=0x7fa5fc00a450 "\377\002", table=0x7fa5fc01e330, upd_buff=0x7fa5fc022fe0 "\200", buff_len=134, prebuilt=0x7fa5fc020aa8, auto_inc=@0x7fa6682b0c58: 2) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:8524
      #7  0x000055e3fa4a0704 in ha_innobase::update_row (this=0x7fa5fc00c168, old_row=0x7fa5fc00a478 "\377\001", new_row=0x7fa5fc00a450 "\377\002") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:8981
      #8  0x000055e3fa194a17 in handler::ha_update_row (this=0x7fa5fc00c168, old_data=0x7fa5fc00a478 "\377\001", new_data=0x7fa5fc00a450 "\377\002") at /data/src/10.2/sql/handler.cc:5993
      #9  0x000055e3f9ffb458 in mysql_update (thd=0x7fa5fc000b00, table_list=0x7fa5fc0111b8, fields=..., values=..., conds=0x7fa5fc011d00, order_num=0, order=0x0, limit=18446744073709551615, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7fa6682b18b0, updated_return=0x7fa6682b1960) at /data/src/10.2/sql/sql_update.cc:809
      #10 0x000055e3f9f0ecab in mysql_execute_command (thd=0x7fa5fc000b00) at /data/src/10.2/sql/sql_parse.cc:4292
      #11 0x000055e3f9f1a7f7 in mysql_parse (thd=0x7fa5fc000b00, rawbuf=0x7fa5fc0110c0 "UPDATE t1 SET pk = pk + 1 WHERE pk = 1", length=38, parser_state=0x7fa6682b2250, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8014
      #12 0x000055e3f9f0812f in dispatch_command (command=COM_QUERY, thd=0x7fa5fc000b00, packet=0x7fa5fc0191a1 "UPDATE t1 SET pk = pk + 1 WHERE pk = 1", packet_length=38, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1825
      #13 0x000055e3f9f06a92 in do_command (thd=0x7fa5fc000b00) at /data/src/10.2/sql/sql_parse.cc:1379
      #14 0x000055e3fa059569 in do_handle_one_connection (connect=0x55e3fbec8580) at /data/src/10.2/sql/sql_connect.cc:1335
      #15 0x000055e3fa0592f6 in handle_one_connection (arg=0x55e3fbec8580) at /data/src/10.2/sql/sql_connect.cc:1241
      #16 0x00007fa66a913494 in start_thread (arg=0x7fa6682b3700) at pthread_create.c:333
      #17 0x00007fa668f1493f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      Non-debug build crashes in the same way.

      On 10.3 and 10.4 the assertion failure is the same as in MDEV-18084.

      To reproduce:

      • start 10.1 server with all defaults (current 10.1 9ad1663f78 or 10.1.37 will do, I didn't check other versions);
      • run

        CREATE TABLE t1 (pk INT AUTO_INCREMENT, vd DATE AS (d) VIRTUAL, i INT, b TINYTEXT, vb TINYTEXT AS (b) VIRTUAL, d DATE, PRIMARY KEY(pk));
        INSERT INTO t1 () VALUES ();
        

      • shutdown server normally;
      • start 10.2+ server with all defaults on the same datadir;
      • run mysql_upgrade (optionally, it doesn't affect the outcome);
      • run

        UPDATE t1 SET pk = pk + 1 WHERE pk = 1
        

      The datadir pre-created on current 10.1 as described is attached.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                marko Marko Mäkelä
                Reporter:
                elenst Elena Stepanova
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: