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

Server crashes in ha_innobase::store_lock upon concurrent ALTER and TRUNCATE

Details

    Description

      Note: The test case is non-deterministic. Run with --repeat=N, allow big enough N before giving up, as the probability is unclear. Also, try to adjust SELECT SLEEP in the test case one or another way. It currently fails for me within ~5-10 attempts with the SLEEP and within ~20-30 attempts without SLEEP, but I suppose it can vary a lot on different machines and builds.

      --source include/have_innodb.inc
      		 
       
      		 
      SET @stats= @@innodb_stats_persistent;
      		 
      SET GLOBAL innodb_stats_persistent= ON;
      		 
       
      		 
      CREATE TABLE t1 (a INT) ENGINE=InnoDB;
      		 
       
      		 
      --connect (con1,localhost,root,,test)
      		 
      CREATE TABLE t2 (b INT) ENGINE=InnoDB;
      		 
      HANDLER t2 OPEN;
      		 
      --send
      		 
        TRUNCATE TABLE t1;
      		 
       
      		 
      --connection default
      		 
      SELECT SLEEP(0.00001);
      		 
      SET lock_wait_timeout= 1;
      		 
      --error ER_LOCK_WAIT_TIMEOUT
      		 
      ALTER TABLE t2 ADD COLUMN c INT;
      		 
       
      		 
      # Cleanup
      		 
      --connection con1
      		 
      --reap
      		 
      --disconnect con1
      		 
      --connection default
      		 
      DROP TABLE t1, t2;
      		 
      SET GLOBAL innodb_stats_persistent= @stats;

      10.4 37570e84

      		 
      #3  <signal handler called>
      		 
      #4  0x000055c27d6e566a in ha_innobase::store_lock (this=0x7f77d0028328, thd=0x7f77cc000b00, to=0x7f77cc014728, lock_type=TL_IGNORE) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:16258
      		 
      #5  0x000055c27d5ca73b in get_lock_data (thd=0x7f77cc000b00, table_ptr=0x7f7828161a30, count=1, flags=2) at /data/src/10.4/sql/lock.cc:789
      		 
      #6  0x000055c27d5c9ea5 in mysql_lock_abort_for_thread (thd=0x7f77cc000b00, table=0x7f77d00274c0) at /data/src/10.4/sql/lock.cc:613
      		 
      #7  0x000055c27d0b4041 in THD::notify_shared_lock (this=0x7f77cc000b00, ctx_in_use=0x7f77d0000bd0, needs_thr_lock_abort=true) at /data/src/10.4/sql/sql_class.cc:2053
      		 
      #8  0x000055c27d2bc019 in MDL_lock::notify_conflicting_locks (this=0x7f77cc1487f0, ctx=0x7f77cc000c20) at /data/src/10.4/sql/mdl.cc:574
      		 
      #9  0x000055c27d2b91fe in MDL_context::acquire_lock (this=0x7f77cc000c20, mdl_request=0x7f7828161c90, lock_wait_timeout=1) at /data/src/10.4/sql/mdl.cc:2292
      		 
      #10 0x000055c27d2b9cec in MDL_context::upgrade_shared_lock (this=0x7f77cc000c20, mdl_ticket=0x7f77cc011930, new_type=MDL_EXCLUSIVE, lock_wait_timeout=1) at /data/src/10.4/sql/mdl.cc:2523
      		 
      #11 0x000055c27d2150b2 in mysql_inplace_alter_table (thd=0x7f77cc000b00, table_list=0x7f77cc013210, table=0x7f77cc150550, altered_table=0x7f7828162820, ha_alter_info=0x7f7828162790, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7f78281635f0, alter_ctx=0x7f7828164120) at /data/src/10.4/sql/sql_table.cc:7625
      		 
      #12 0x000055c27d21c24a in mysql_alter_table (thd=0x7f77cc000b00, new_db=0x7f77cc0052b8, new_name=0x7f77cc0056c0, create_info=0x7f7828164d10, table_list=0x7f77cc013210, alter_info=0x7f7828164c50, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10086
      		 
      #13 0x000055c27d2b38ab in Sql_cmd_alter_table::execute (this=0x7f77cc0139e8, thd=0x7f77cc000b00) at /data/src/10.4/sql/sql_alter.cc:508
      		 
      #14 0x000055c27d133b13 in mysql_execute_command (thd=0x7f77cc000b00) at /data/src/10.4/sql/sql_parse.cc:6094
      		 
      #15 0x000055c27d1391e7 in mysql_parse (thd=0x7f77cc000b00, rawbuf=0x7f77cc013128 "ALTER TABLE t2 ADD COLUMN c INT", length=31, parser_state=0x7f7828166170, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7912
      		 
      #16 0x000055c27d12447a in dispatch_command (command=COM_QUERY, thd=0x7f77cc000b00, packet=0x7f77cc19dbb1 "ALTER TABLE t2 ADD COLUMN c INT", packet_length=31, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1841
      		 
      #17 0x000055c27d122b07 in do_command (thd=0x7f77cc000b00) at /data/src/10.4/sql/sql_parse.cc:1359
      		 
      #18 0x000055c27d2aa1bb in do_handle_one_connection (connect=0x55c2810e6820) at /data/src/10.4/sql/sql_connect.cc:1412
      		 
      #19 0x000055c27d2a9f0a in handle_one_connection (arg=0x55c2810e6820) at /data/src/10.4/sql/sql_connect.cc:1316
      		 
      #20 0x000055c27dca9209 in pfs_spawn_thread (arg=0x55c281065180) at /data/src/10.4/storage/perfschema/pfs.cc:1862
      		 
      #21 0x00007f782fd0a4a4 in start_thread (arg=0x7f7828167700) at pthread_create.c:456
      		 
      #22 0x00007f782e251d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

      Reproducible on 10.2-10.5, on all of debug, non-debug and ASAN builds.
      Couldn't reproduce on 10.1.
      Couldn't reproduce without persistent statistics.

      ASAN builds also fail with SEGV on the test case above, but earlier heap-use-after-free was also observed during concurrent tests:

      10.4 78829a5780d

      		 
      ==24341==ERROR: AddressSanitizer: heap-use-after-free on address 0x621000287a38 at pc 0x55e1dd15574d bp 0x7f67792cce70 sp 0x7f67792cce60
      		 
      READ of size 8 at 0x621000287a38 thread T40
      		 
          #0 0x55e1dd15574c in ha_innobase::store_lock(THD*, st_thr_lock_data**, thr_lock_type) /home/travis/src/storage/innobase/handler/ha_innodb.cc:16339
      		 
          #1 0x55e1dcedc804 in get_lock_data(THD*, TABLE**, unsigned int, unsigned int) /home/travis/src/sql/lock.cc:794
      		 
          #2 0x55e1dcedaf2c in mysql_lock_abort_for_thread(THD*, TABLE*) /home/travis/src/sql/lock.cc:618
      		 
          #3 0x55e1dc3e4327 in THD::notify_shared_lock(MDL_context_owner*, bool) /home/travis/src/sql/sql_class.cc:2042
      		 
          #4 0x55e1dc84b65a in MDL_lock::notify_conflicting_locks(MDL_context*) /home/travis/src/sql/mdl.cc:574
      		 
          #5 0x55e1dc845cee in MDL_context::acquire_lock(MDL_request*, double) /home/travis/src/sql/mdl.cc:2292
      		 
          #6 0x55e1dc846f28 in MDL_context::upgrade_shared_lock(MDL_ticket*, enum_mdl_type, double) /home/travis/src/sql/mdl.cc:2523
      		 
          #7 0x55e1dc6eb6b1 in mysql_inplace_alter_table /home/travis/src/sql/sql_table.cc:7454
      		 
          #8 0x55e1dc6f8ad3 in mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool) /home/travis/src/sql/sql_table.cc:9692
      		 
          #9 0x55e1dc83ae60 in Sql_cmd_alter_table::execute(THD*) /home/travis/src/sql/sql_alter.cc:499
      		 
          #10 0x55e1dc4f02a1 in mysql_execute_command(THD*) /home/travis/src/sql/sql_parse.cc:6345
      		 
          #11 0x55e1dc4faae9 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /home/travis/src/sql/sql_parse.cc:8156
      		 
          #12 0x55e1dc4d376a in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /home/travis/src/sql/sql_parse.cc:1842
      		 
          #13 0x55e1dc4d094b in do_command(THD*) /home/travis/src/sql/sql_parse.cc:1395
      		 
          #14 0x55e1dc82becb in do_handle_one_connection(CONNECT*) /home/travis/src/sql/sql_connect.cc:1398
      		 
          #15 0x55e1dc82b89f in handle_one_connection /home/travis/src/sql/sql_connect.cc:1301
      		 
          #16 0x7f681d5106b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
      		 
          #17 0x7f681c7a141c in clone (/lib/x86_64-linux-gnu/libc.so.6+0x10741c)
      		 
      ASAN:SIGSEGV

      Attachments

        Issue Links

          is blocked by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-25919 InnoDB reports misleading lock wait timeout on DDL operations

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-15020 Server hangs due to InnoDB persistent statistics or innodb_stats_auto_recalc

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

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            I am terribly sorry for the delay. I accidentally found this ticket while searching for heap-use-after-free.

            On 10.6, I only got the following failure, after 22×88 attempts:

            10.6 4e1ca388381eea27a9275571744ad17ce317b273

            		 
            mysqltest: At line 15: query 'ALTER TABLE t2 ADD COLUMN c INT' succeeded - should have failed with error ER_LOCK_WAIT_TIMEOUT (1205)...

            On 10.5 fd6a464ae5a4a4db4950fb9c7606a40d6fc32256, I got the same after 22×46 attempts.

            Then, I revised the test to avoid instant ADD COLUMN and to allow that nondeterminism:

            --error 0,ER_LOCK_WAIT_TIMEOUT
            		 
            ALTER TABLE t2 ADD COLUMN c INT, FORCE;

            With this change, all 22×100 or 29×100 tests passed.

            Is this bug still repeatable in any major branch? I see that this was filed about a year after the TRUNCATE rewrite in MDEV-13564 had been implemented. On a quick search of bugs caused by MDEV-13564, the fix of MDEV-18836 might have fixed this. It is hard to say it for sure, because the included ASAN output omits the stack trace where the memory had been freed.

            marko Marko Mäkelä added a comment - I am terribly sorry for the delay. I accidentally found this ticket while searching for heap-use-after-free . On 10.6, I only got the following failure, after 22×88 attempts: 10.6 4e1ca388381eea27a9275571744ad17ce317b273 mysqltest: At line 15: query 'ALTER TABLE t2 ADD COLUMN c INT' succeeded - should have failed with error ER_LOCK_WAIT_TIMEOUT (1205)... On 10.5 fd6a464ae5a4a4db4950fb9c7606a40d6fc32256, I got the same after 22×46 attempts. Then, I revised the test to avoid instant ADD COLUMN and to allow that nondeterminism: --error 0,ER_LOCK_WAIT_TIMEOUT ALTER TABLE t2 ADD COLUMN c INT , FORCE ; With this change, all 22×100 or 29×100 tests passed. Is this bug still repeatable in any major branch? I see that this was filed about a year after the TRUNCATE rewrite in MDEV-13564 had been implemented. On a quick search of bugs caused by MDEV-13564 , the fix of MDEV-18836 might have fixed this. It is hard to say it for sure, because the included ASAN output omits the stack trace where the memory had been freed.
            elenst Elena Stepanova added a comment - - edited

            First, there was a flaw in the description. Notes in the text say "Couldn't reproduce without persistent statistics", but the test case itself didn't have innodb_stats_persistent, so it had to be provided on the command line and easy to miss. I have added it to the test case now.

            Secondly yes, it is still reproducible on current 10.2-10.4. However, at some point, apparently after this commit

            commit 14a18d7d7f6293ad0e106288eab4fdcb3a72ebd9 (HEAD)
            		 
            Author: Marko Mäkelä
            		 
            Date:   Sat Apr 24 09:37:46 2021 +0300
            		 
             
            		 
                MDEV-23026/MDEV-25474 fixup: Assertion ib_table->stat_initialized

            it became an extremely low-probability issue. Before the commit it happens on my machine approximately within 10 trials, while since the commit – within 200-300 trials.
            On current 10.5 and 10.6 I could not reproduce it at all, in 2x1000 trials each.

            Feel free to close the report or do whatever else you prefer.

            10.4 cbdf62ae

            		 
            #3  <signal handler called>
            		 
            #4  0x000055d84c37bce8 in ha_innobase::store_lock (this=0x7efcbc058228, thd=0x7efcb8000d90, to=0x7efcb8015e00, lock_type=TL_IGNORE) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:16481
            		 
            #5  0x000055d84c0d6da5 in get_lock_data (thd=0x7efcb8000d90, table_ptr=0x7efd14121040, count=1, flags=2) at /data/src/10.4/sql/lock.cc:791
            		 
            #6  0x000055d84c0d64fb in mysql_lock_abort_for_thread (thd=0x7efcb8000d90, table=0x7efcbc056f60) at /data/src/10.4/sql/lock.cc:614
            		 
            #7  0x000055d84bbdfa79 in THD::notify_shared_lock (this=0x7efcb8000d90, ctx_in_use=0x7efcbc000e60, needs_thr_lock_abort=true) at /data/src/10.4/sql/sql_class.cc:2048
            		 
            #8  0x000055d84bdf06b5 in MDL_lock::notify_conflicting_locks (this=0x7efcbc0b56a0, ctx=0x7efcb8000eb0) at /data/src/10.4/sql/mdl.cc:602
            		 
            #9  0x000055d84bded9ea in MDL_context::acquire_lock (this=0x7efcb8000eb0, mdl_request=0x7efd14121290, lock_wait_timeout=1) at /data/src/10.4/sql/mdl.cc:2321
            		 
            #10 0x000055d84bdee530 in MDL_context::upgrade_shared_lock (this=0x7efcb8000eb0, mdl_ticket=0x7efcb81ca270, new_type=MDL_EXCLUSIVE, lock_wait_timeout=1) at /data/src/10.4/sql/mdl.cc:2554
            		 
            #11 0x000055d84bd47099 in mysql_inplace_alter_table (thd=0x7efcb8000d90, table_list=0x7efcb8014888, table=0x7efcb81cd070, altered_table=0x7efd14121e20, ha_alter_info=0x7efd14121d80, target_mdl_request=0x7efd14122bf0, alter_ctx=0x7efd14123730) at /data/src/10.4/sql/sql_table.cc:7762
            		 
            #12 0x000055d84bd4ea6a in mysql_alter_table (thd=0x7efcb8000d90, new_db=0x7efcb8005568, new_name=0x7efcb8005990, create_info=0x7efd14124330, table_list=0x7efcb8014888, alter_info=0x7efd14124270, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10303
            		 
            #13 0x000055d84bde7e7c in Sql_cmd_alter_table::execute (this=0x7efcb8015078, thd=0x7efcb8000d90) at /data/src/10.4/sql/sql_alter.cc:520
            		 
            #14 0x000055d84bc5ffc0 in mysql_execute_command (thd=0x7efcb8000d90) at /data/src/10.4/sql/sql_parse.cc:6208
            		 
            #15 0x000055d84bc652cc in mysql_parse (thd=0x7efcb8000d90, rawbuf=0x7efcb80147a8 "ALTER TABLE t2 ADD COLUMN c INT", length=31, parser_state=0x7efd14125550, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8011
            		 
            #16 0x000055d84bc51745 in dispatch_command (command=COM_QUERY, thd=0x7efcb8000d90, packet=0x7efcb800ac01 "ALTER TABLE t2 ADD COLUMN c INT", packet_length=31, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1873
            		 
            #17 0x000055d84bc4ff37 in do_command (thd=0x7efcb8000d90) at /data/src/10.4/sql/sql_parse.cc:1378
            		 
            #18 0x000055d84bdde847 in do_handle_one_connection (connect=0x55d84ebda090) at /data/src/10.4/sql/sql_connect.cc:1420
            		 
            #19 0x000055d84bdde4ef in handle_one_connection (arg=0x55d84ebda090) at /data/src/10.4/sql/sql_connect.cc:1316
            		 
            #20 0x000055d84c2fa987 in pfs_spawn_thread (arg=0x55d84ebccf80) at /data/src/10.4/storage/perfschema/pfs.cc:1869
            		 
            #21 0x00007efd1b42dea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
            		 
            #22 0x00007efd1b02adef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

            elenst Elena Stepanova added a comment - - edited First, there was a flaw in the description. Notes in the text say "Couldn't reproduce without persistent statistics", but the test case itself didn't have innodb_stats_persistent , so it had to be provided on the command line and easy to miss. I have added it to the test case now. Secondly yes, it is still reproducible on current 10.2-10.4. However, at some point, apparently after this commit commit 14a18d7d7f6293ad0e106288eab4fdcb3a72ebd9 (HEAD) Author: Marko Mäkelä Date: Sat Apr 24 09:37:46 2021 +0300   MDEV-23026/MDEV-25474 fixup: Assertion ib_table->stat_initialized it became an extremely low-probability issue. Before the commit it happens on my machine approximately within 10 trials, while since the commit – within 200-300 trials. On current 10.5 and 10.6 I could not reproduce it at all, in 2x1000 trials each. Feel free to close the report or do whatever else you prefer. 10.4 cbdf62ae #3 <signal handler called> #4 0x000055d84c37bce8 in ha_innobase::store_lock (this=0x7efcbc058228, thd=0x7efcb8000d90, to=0x7efcb8015e00, lock_type=TL_IGNORE) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:16481 #5 0x000055d84c0d6da5 in get_lock_data (thd=0x7efcb8000d90, table_ptr=0x7efd14121040, count=1, flags=2) at /data/src/10.4/sql/lock.cc:791 #6 0x000055d84c0d64fb in mysql_lock_abort_for_thread (thd=0x7efcb8000d90, table=0x7efcbc056f60) at /data/src/10.4/sql/lock.cc:614 #7 0x000055d84bbdfa79 in THD::notify_shared_lock (this=0x7efcb8000d90, ctx_in_use=0x7efcbc000e60, needs_thr_lock_abort=true) at /data/src/10.4/sql/sql_class.cc:2048 #8 0x000055d84bdf06b5 in MDL_lock::notify_conflicting_locks (this=0x7efcbc0b56a0, ctx=0x7efcb8000eb0) at /data/src/10.4/sql/mdl.cc:602 #9 0x000055d84bded9ea in MDL_context::acquire_lock (this=0x7efcb8000eb0, mdl_request=0x7efd14121290, lock_wait_timeout=1) at /data/src/10.4/sql/mdl.cc:2321 #10 0x000055d84bdee530 in MDL_context::upgrade_shared_lock (this=0x7efcb8000eb0, mdl_ticket=0x7efcb81ca270, new_type=MDL_EXCLUSIVE, lock_wait_timeout=1) at /data/src/10.4/sql/mdl.cc:2554 #11 0x000055d84bd47099 in mysql_inplace_alter_table (thd=0x7efcb8000d90, table_list=0x7efcb8014888, table=0x7efcb81cd070, altered_table=0x7efd14121e20, ha_alter_info=0x7efd14121d80, target_mdl_request=0x7efd14122bf0, alter_ctx=0x7efd14123730) at /data/src/10.4/sql/sql_table.cc:7762 #12 0x000055d84bd4ea6a in mysql_alter_table (thd=0x7efcb8000d90, new_db=0x7efcb8005568, new_name=0x7efcb8005990, create_info=0x7efd14124330, table_list=0x7efcb8014888, alter_info=0x7efd14124270, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10303 #13 0x000055d84bde7e7c in Sql_cmd_alter_table::execute (this=0x7efcb8015078, thd=0x7efcb8000d90) at /data/src/10.4/sql/sql_alter.cc:520 #14 0x000055d84bc5ffc0 in mysql_execute_command (thd=0x7efcb8000d90) at /data/src/10.4/sql/sql_parse.cc:6208 #15 0x000055d84bc652cc in mysql_parse (thd=0x7efcb8000d90, rawbuf=0x7efcb80147a8 "ALTER TABLE t2 ADD COLUMN c INT", length=31, parser_state=0x7efd14125550, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8011 #16 0x000055d84bc51745 in dispatch_command (command=COM_QUERY, thd=0x7efcb8000d90, packet=0x7efcb800ac01 "ALTER TABLE t2 ADD COLUMN c INT", packet_length=31, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1873 #17 0x000055d84bc4ff37 in do_command (thd=0x7efcb8000d90) at /data/src/10.4/sql/sql_parse.cc:1378 #18 0x000055d84bdde847 in do_handle_one_connection (connect=0x55d84ebda090) at /data/src/10.4/sql/sql_connect.cc:1420 #19 0x000055d84bdde4ef in handle_one_connection (arg=0x55d84ebda090) at /data/src/10.4/sql/sql_connect.cc:1316 #20 0x000055d84c2fa987 in pfs_spawn_thread (arg=0x55d84ebccf80) at /data/src/10.4/storage/perfschema/pfs.cc:1869 #21 0x00007efd1b42dea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 #22 0x00007efd1b02adef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
            marko Marko Mäkelä added a comment -

            Thank you, elenst. For mtr tests in 10.6, InnoDB persistent statistics are no longer disabled by default (a change that was implemented in MDEV-4750), but instead enabled by default. That was something that I did to have better coverage for MDEV-25919, which should have finally fixed this.

            I tried the test on 10.5 once more, adding explicit STATS_PERSISTENT=1 to the CREATE TABLE statements (sorry for missing it yesterday), and it eventually did crash:

            10.5 6645b1d2c7fe58b4e78d597f234769e1742d2828

            		 
            main.mdev-18381 'innodb'                 w27 [ 25 fail ]
            		 
                    Test ended at 2022-04-08 08:12:15
            		 
             
            		 
            CURRENT_TEST: main.mdev-18381
            		 
            mysqltest: At line 15: query 'ALTER TABLE t2 ADD COLUMN c INT, FORCE' failed with wrong errno 2013: 'Lost connection to MySQL server during query', instead of 0...
            		 
            …
            		 
            handler/ha_innodb.cc:16493(ha_innobase::store_lock(THD*, st_thr_lock_data**, thr_lock_type))[0x56189efc3644]
            		 
            sql/lock.cc:809(get_lock_data(THD*, TABLE**, unsigned int, unsigned int))[0x56189efc3b39]
            		 
            sql/lock.cc:631(mysql_lock_abort_for_thread(THD*, TABLE*))[0x56189ec83079]
            		 
            /dev/shm/10.5m/sql/mariadbd(_ZN8MDL_lock24notify_conflicting_locksEP11MDL_context+0x87)[0x56189edddbe5]
            		 
            sql/sql_class.cc:2070(THD::notify_shared_lock(MDL_context_owner*, bool))[0x56189eddca1c]
            		 
            sql/mdl.cc:609(MDL_lock::notify_conflicting_locks(MDL_context*))[0x56189eddce74]
            		 
            sql/mdl.cc:2322(MDL_context::acquire_lock(MDL_request*, double))[0x56189ed63b7c]
            		 
            sql/sql_table.cc:8058(mysql_inplace_alter_table(THD*, TABLE_LIST*, TABLE*, TABLE*, Alter_inplace_info*, MDL_request*, Alter_table_ctx*))[0x56189ed74b68]

            I do not think that it is feasible to fix this in older versions than 10.6. Similar to the infamous MDEV-15020 (hangs related to InnoDB persistent statistics), the fix was MDEV-25919 and a number of other very extensive changes that were made in 10.6.

            marko Marko Mäkelä added a comment - Thank you, elenst . For mtr tests in 10.6, InnoDB persistent statistics are no longer disabled by default (a change that was implemented in MDEV-4750 ), but instead enabled by default. That was something that I did to have better coverage for MDEV-25919 , which should have finally fixed this. I tried the test on 10.5 once more, adding explicit STATS_PERSISTENT=1 to the CREATE TABLE statements (sorry for missing it yesterday), and it eventually did crash: 10.5 6645b1d2c7fe58b4e78d597f234769e1742d2828 main.mdev-18381 'innodb' w27 [ 25 fail ] Test ended at 2022-04-08 08:12:15   CURRENT_TEST: main.mdev-18381 mysqltest: At line 15: query 'ALTER TABLE t2 ADD COLUMN c INT, FORCE' failed with wrong errno 2013: 'Lost connection to MySQL server during query', instead of 0... … handler/ha_innodb.cc:16493(ha_innobase::store_lock(THD*, st_thr_lock_data**, thr_lock_type))[0x56189efc3644] sql/lock.cc:809(get_lock_data(THD*, TABLE**, unsigned int, unsigned int))[0x56189efc3b39] sql/lock.cc:631(mysql_lock_abort_for_thread(THD*, TABLE*))[0x56189ec83079] /dev/shm/10.5m/sql/mariadbd(_ZN8MDL_lock24notify_conflicting_locksEP11MDL_context+0x87)[0x56189edddbe5] sql/sql_class.cc:2070(THD::notify_shared_lock(MDL_context_owner*, bool))[0x56189eddca1c] sql/mdl.cc:609(MDL_lock::notify_conflicting_locks(MDL_context*))[0x56189eddce74] sql/mdl.cc:2322(MDL_context::acquire_lock(MDL_request*, double))[0x56189ed63b7c] sql/sql_table.cc:8058(mysql_inplace_alter_table(THD*, TABLE_LIST*, TABLE*, TABLE*, Alter_inplace_info*, MDL_request*, Alter_table_ctx*))[0x56189ed74b68] I do not think that it is feasible to fix this in older versions than 10.6. Similar to the infamous MDEV-15020 (hangs related to InnoDB persistent statistics), the fix was MDEV-25919 and a number of other very extensive changes that were made in 10.6.

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              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.