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

SIGSEGV in ha_spider::update_create_info & SIGSEGV in my_hash_insert on ALTER

Details

    Description

      INSTALL PLUGIN Spider SONAME 'ha_spider.so';
      		 
      CREATE SERVER srv FOREIGN DATA WRAPPER MYSQL OPTIONS (SOCKET '../socket.sock',DATABASE'',USER'',PASSWORD'');
      		 
      CREATE TABLE t1 (c1 TIME) ENGINE=Spider PARTITION BY HASH(EXTRACT(HOUR_SECOND FROM c1));
      		 
      CREATE TABLE t2 (c1 INT) ENGINE=MyISAM;
      		 
      CREATE TABLE t3 (c1 INT,c2 INT) ENGINE=Spider COMMENT='WRAPPER "mysql",SRV "srv",TABLE "t1"';
      		 
      INSERT INTO t2 SELECT * FROM t3;
      		 
      SELECT * FROM t3;
      		 
      ALTER TABLE t1 CHANGE COLUMN c1 d1 INT;

      Leads to:

      11.2.5 03807c8449cdccbf5b8afc0dddabb1d8ec7ba85a (Debug)

      		 
      Core was generated by `/test/MD200724-mariadb-11.2.5-linux-x86_64-dbg/bin/mariadbd --no-defaults --max'.
      		 
      Program terminated with signal SIGSEGV, Segmentation fault.
      		 
      #0  ha_spider::update_create_info (this=0x153fe403ab30, create_info=0x1540280e3630)at /test/11.2_dbg/storage/spider/ha_spider.cc:8610
      		 
      Downloading source file /test/11.2_dbg/storage/spider/ha_spider.cc...
      		 
      [Current thread is 1 (LWP 1347742)]
      		 
      (gdb) bt
      		 
      #0  ha_spider::update_create_info (this=0x153fe403ab30, create_info=0x1540280e3630)at /test/11.2_dbg/storage/spider/ha_spider.cc:8610
      		 
      #1  0x000055e0629d05d8 in ha_partition::update_create_info (this=0x153fe403a250, create_info=<optimized out>)at /test/11.2_dbg/sql/ha_partition.cc:2372
      		 
      #2  0x000055e062504368 in mysql_prepare_alter_table (thd=thd@entry=0x153fe8000d58, table=table@entry=0x153fe40399e8, create_info=create_info@entry=0x1540280e6340, alter_info=alter_info@entry=0x1540280e61d0, alter_ctx=alter_ctx@entry=0x1540280e54b0)at /test/11.2_dbg/sql/sql_table.cc:9237
      		 
      #3  0x000055e062512cec in mysql_alter_table (thd=thd@entry=0x153fe8000d58, new_db=<optimized out>, new_name=new_name@entry=0x153fe8005fd8, create_info=create_info@entry=0x1540280e6340, table_list=<optimized out>, table_list@entry=0x153fe8013738, recreate_info=recreate_info@entry=0x1540280e6190, alter_info=<optimized out>, order_num=<optimized out>, order=<optimized out>, ignore=<optimized out>, if_exists=<optimized out>)at /test/11.2_dbg/sql/sql_table.cc:10878
      		 
      #4  0x000055e06259b609 in Sql_cmd_alter_table::execute (this=<optimized out>, thd=0x153fe8000d58) at /test/11.2_dbg/sql/sql_alter.cc:701
      		 
      #5  0x000055e062425db3 in mysql_execute_command (thd=thd@entry=0x153fe8000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false)at /test/11.2_dbg/sql/sql_parse.cc:5876
      		 
      #6  0x000055e062427753 in mysql_parse (thd=thd@entry=0x153fe8000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1540280e72e0)at /test/11.2_dbg/sql/sql_parse.cc:7920
      		 
      #7  0x000055e062429ada in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x153fe8000d58, packet=packet@entry=0x153fe800b309 "ALTER TABLE t1 CHANGE COLUMN c1 d1 INT", packet_length=packet_length@entry=38, blocking=blocking@entry=true)at /test/11.2_dbg/sql/sql_class.h:247
      		 
      #8  0x000055e06242bdff in do_command (thd=0x153fe8000d58, blocking=blocking@entry=true) at /test/11.2_dbg/sql/sql_parse.cc:1407
      		 
      #9  0x000055e062592e61 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55e064df09a8, put_in_cache=put_in_cache@entry=true)at /test/11.2_dbg/sql/sql_connect.cc:1439
      		 
      #10 0x000055e062593156 in handle_one_connection (arg=arg@entry=0x55e064df09a8)at /test/11.2_dbg/sql/sql_connect.cc:1341
      		 
      #11 0x000055e0629e4192 in pfs_spawn_thread (arg=0x55e064dbfb68)at /test/11.2_dbg/storage/perfschema/pfs.cc:2201
      		 
      #12 0x0000154031c97ada in start_thread (arg=<optimized out>)at ./nptl/pthread_create.c:444
      		 
      #13 0x0000154031d2847c in clone3 ()at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

      Bug confirmed present in:
      MariaDB: 10.6.19 (dbg), 10.6.19 (opt), 10.11.9 (dbg), 10.11.9 (opt), 11.1.6 (dbg), 11.1.6 (opt), 11.2.5 (dbg), 11.2.5 (opt), 11.4.3 (dbg), 11.4.3 (opt), 11.5.2 (dbg), 11.5.2 (opt), 11.6.0 (dbg), 11.6.0 (opt)

      Bug (or feature/syntax) confirmed not present in:
      MariaDB: 10.5.26 (dbg), 10.5.26 (opt)

      Attachments

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. MDEV-34588 Assertion `thd == _current_thd() || ((&(&thd->LOCK_thd_data)->m_mutex)->count > 0 && pthread_equal(pthread_self(), (&(&thd->LOCK_thd_data)->m_mutex)->thread))' failed in thd_get_ha_data and thread hangs

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33502 Slowdown when running nested statement with many partitions

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 7 older comments
            ycp Yuchen Pei added a comment -

            This issue actually could be the same problem as the assertion failure in MDEV-34588. The following is based on 10.6 216fdb155683e960297b089e024c439593bbe6a8.

            If we remove the implementation of ha_spider::extra() with the MERGE SE specific flags (see the diff block below), we get an assertion failure in spider/bugfix.mdev_29963 and it is the same assertion failure as reported in MDEV-34588. Upon inspection, it happens at the data node when running LOCK TABLES t2 WRITE;, and the data node query is "lock tables `test`.`t` write".

            modified   storage/spider/ha_spider.cc
            		 
            @@ -1376,7 +1376,6 @@ int ha_spider::reset()
            		 
             int ha_spider::extra(
            		 
               enum ha_extra_function operation
            		 
             ) {
            		 
            -  int error_num;
            		 
               DBUG_ENTER("ha_spider::extra");
            		 
               DBUG_PRINT("info",("spider this=%p", this));
            		 
               DBUG_PRINT("info",("spider operation=%d", (int) operation));
            		 
            @@ -1428,16 +1427,6 @@ int ha_spider::extra(
            		 
                   wide_handler->insert_with_update = TRUE;
            		 
                   break;
            		 
             #endif
            		 
            -    case HA_EXTRA_ATTACH_CHILDREN:
            		 
            -      DBUG_PRINT("info",("spider HA_EXTRA_ATTACH_CHILDREN"));
            		 
            -      if (!(wide_handler->trx = spider_get_trx(ha_thd(), TRUE, &error_num)))
            		 
            -        DBUG_RETURN(error_num);
            		 
            -      break;
            		 
            -    case HA_EXTRA_ADD_CHILDREN_LIST:
            		 
            -      DBUG_PRINT("info",("spider HA_EXTRA_ADD_CHILDREN_LIST"));
            		 
            -      if (!(wide_handler->trx = spider_get_trx(ha_thd(), TRUE, &error_num)))
            		 
            -        DBUG_RETURN(error_num);
            		 
            -      break;
            		 
             #if defined(HA_EXTRA_HAS_STARTING_ORDERED_INDEX_SCAN) || defined(HA_EXTRA_HAS_HA_EXTRA_USE_CMP_REF)
            		 
             #ifdef HA_EXTRA_HAS_STARTING_ORDERED_INDEX_SCAN
            		 
                 case HA_EXTRA_STARTING_ORDERED_INDEX_SCAN:

            The thd at ha_spider::store_lock is different from that retrieved from spider->wide_handler->trx->thd. Below is the stack trace at the assertion failure:

            __GI___assert_fail > thd_get_ha_data > spider_get_trx > spider_check_trx_and_get_conn > ha_spider::append_lock_tables_list > ha_spider::store_lock > get_lock_data > mysql_lock_tables > lock_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ...

            If we place a breakpoint at ha_spider::extra() and do rc in rr, it is hit in the same query at the data node with a MERGE specific flag. The stack looks like spider was relying on ha_spider::extra() to reset the trx, since ha_spider::open() is not always called from open_table() (called from open_and_process_table()):

            ha_spider::extra > open_and_process_table > open_tables > open_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ...

            The same happens in the MDEV-34588 case. There, the assertion failure happens at the statement LOCK TABLES t2 READ,t1 WRITE.

            __GI___assert_fail > thd_get_ha_data > spider_get_trx > spider_check_trx_and_get_conn > ha_spider::append_lock_tables_list > ha_spider::store_lock > ha_partition::store_lock > get_lock_data > mysql_lock_tables > lock_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ...

            However ha_spider::extra() was not called because the MDEV-33502 change mentioned below decided not to call ha_spider::extra() from ha_partition::extra() with the MERGE-specific flag.

            ha_partition::extra > open_and_process_table > open_tables > open_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ...

            Note the similarities in the stacks too.

            ycp Yuchen Pei added a comment - This issue actually could be the same problem as the assertion failure in MDEV-34588 . The following is based on 10.6 216fdb155683e960297b089e024c439593bbe6a8. If we remove the implementation of ha_spider::extra() with the MERGE SE specific flags (see the diff block below), we get an assertion failure in spider/bugfix.mdev_29963 and it is the same assertion failure as reported in MDEV-34588 . Upon inspection, it happens at the data node when running LOCK TABLES t2 WRITE; , and the data node query is "lock tables `test`.`t` write" . modified storage/spider/ha_spider.cc @@ -1376,7 +1376,6 @@ int ha_spider::reset() int ha_spider::extra( enum ha_extra_function operation ) { - int error_num; DBUG_ENTER("ha_spider::extra"); DBUG_PRINT("info",("spider this=%p", this)); DBUG_PRINT("info",("spider operation=%d", (int) operation)); @@ -1428,16 +1427,6 @@ int ha_spider::extra( wide_handler->insert_with_update = TRUE; break; #endif - case HA_EXTRA_ATTACH_CHILDREN: - DBUG_PRINT("info",("spider HA_EXTRA_ATTACH_CHILDREN")); - if (!(wide_handler->trx = spider_get_trx(ha_thd(), TRUE, &error_num))) - DBUG_RETURN(error_num); - break; - case HA_EXTRA_ADD_CHILDREN_LIST: - DBUG_PRINT("info",("spider HA_EXTRA_ADD_CHILDREN_LIST")); - if (!(wide_handler->trx = spider_get_trx(ha_thd(), TRUE, &error_num))) - DBUG_RETURN(error_num); - break; #if defined(HA_EXTRA_HAS_STARTING_ORDERED_INDEX_SCAN) || defined(HA_EXTRA_HAS_HA_EXTRA_USE_CMP_REF) #ifdef HA_EXTRA_HAS_STARTING_ORDERED_INDEX_SCAN case HA_EXTRA_STARTING_ORDERED_INDEX_SCAN: The thd at ha_spider::store_lock is different from that retrieved from spider->wide_handler->trx->thd . Below is the stack trace at the assertion failure: __GI___assert_fail > thd_get_ha_data > spider_get_trx > spider_check_trx_and_get_conn > ha_spider::append_lock_tables_list > ha_spider::store_lock > get_lock_data > mysql_lock_tables > lock_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ... If we place a breakpoint at ha_spider::extra() and do rc in rr, it is hit in the same query at the data node with a MERGE specific flag. The stack looks like spider was relying on ha_spider::extra() to reset the trx, since ha_spider::open() is not always called from open_table() (called from open_and_process_table()): ha_spider::extra > open_and_process_table > open_tables > open_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ... The same happens in the MDEV-34588 case. There, the assertion failure happens at the statement LOCK TABLES t2 READ,t1 WRITE . __GI___assert_fail > thd_get_ha_data > spider_get_trx > spider_check_trx_and_get_conn > ha_spider::append_lock_tables_list > ha_spider::store_lock > ha_partition::store_lock > get_lock_data > mysql_lock_tables > lock_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ... However ha_spider::extra() was not called because the MDEV-33502 change mentioned below decided not to call ha_spider::extra() from ha_partition::extra() with the MERGE-specific flag. ha_partition::extra > open_and_process_table > open_tables > open_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ... Note the similarities in the stacks too.
            Roel Roel Van de Paar added a comment -

            Also documenting 10.5 CLI output:

            10.5.26 b8f92ade57691a78cc97c5d79eae0a27a10cb8f2 (Debug)

            		 
            ...
            		 
            10.5.26-dbg>INSERT INTO t2 SELECT * FROM t3;
            		 
            ERROR 1136 (21S01): Column count doesn't match value count at row 1
            		 
            10.5.26-dbg>SELECT * FROM t3;
            		 
            ERROR 1429 (HY000): Unable to connect to foreign data source: localhost
            		 
            10.5.26-dbg>ALTER TABLE t1 CHANGE COLUMN c1 d1 INT;
            		 
            ERROR 1486 (HY000): Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed

            Roel Roel Van de Paar added a comment - Also documenting 10.5 CLI output: 10.5.26 b8f92ade57691a78cc97c5d79eae0a27a10cb8f2 (Debug) ... 10.5.26-dbg>INSERT INTO t2 SELECT * FROM t3; ERROR 1136 (21S01): Column count doesn't match value count at row 1 10.5.26-dbg>SELECT * FROM t3; ERROR 1429 (HY000): Unable to connect to foreign data source: localhost 10.5.26-dbg>ALTER TABLE t1 CHANGE COLUMN c1 d1 INT; ERROR 1486 (HY000): Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed
            ycp Yuchen Pei added a comment -

            Hi holyfoot, ptal thanks

            eaf360a48b0 upstream/bb-10.5-mdev-34636 MDEV-34636 Spider: reset wide_handler->trx in two occasions
            		 
            a28f4001065 MDEV-34636 Remove implementation of ha-spider::extra() with MERGE flags

            ycp Yuchen Pei added a comment - Hi holyfoot , ptal thanks eaf360a48b0 upstream/bb-10.5-mdev-34636 MDEV-34636 Spider: reset wide_handler->trx in two occasions a28f4001065 MDEV-34636 Remove implementation of ha-spider::extra() with MERGE flags
            holyfoot Alexey Botchkov added a comment -

            ok to push.

            holyfoot Alexey Botchkov added a comment - ok to push.
            ycp Yuchen Pei added a comment -

            thanks for the review - pushed the following to 10.5:

            42735c557e7 upstream/bb-10.5-mdev-34636 upstream/10.5 MDEV-34636 Spider: reset wide_handler->trx in two occasions
            		 
            f43ea935a12 MDEV-34636 Remove implementation of ha-spider::extra() with MERGE flags

            ycp Yuchen Pei added a comment - thanks for the review - pushed the following to 10.5: 42735c557e7 upstream/bb-10.5-mdev-34636 upstream/10.5 MDEV-34636 Spider: reset wide_handler->trx in two occasions f43ea935a12 MDEV-34636 Remove implementation of ha-spider::extra() with MERGE flags

            People

              ycp Yuchen Pei
              Roel Roel Van de Paar
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.