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

Server crash in find_field_in_table

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 10.11.1
    • N/A
    • Server
    • None
    • 18.04.1-Ubuntu x86_64 GNU/Linux

    Description

      How to trigger:

      CREATE TABLE t0 ( c0 INT ( 0 ) UNSIGNED AUTO_INCREMENT PRIMARY KEY ) DEFAULT CHARSET = utf8mb3;
      CREATE VIEW v0 AS SELECT ra6 . c0 ca3 , ra6 . c0 AS ca4 FROM t0 ra5 CROSS JOIN t0 ra6 WHERE CAST( ra6 . c0 AS FLOAT ) = 0.005000 LIMIT 1 ;
      SELECT ra7 . c0 ca5 FROM t0 ra7 WINDOW v AS ( ORDER BY ( SELECT ra8 . ca4 ca1 FROM v0 ra8 GROUP BY ra8 . ca4 WINDOW v AS ( PARTITION BY ra8 . ca3 ) ) ) ;
      

      Sever error log

      Server version: 10.11.1-MariaDB
      key_buffer_size=134217728
      read_buffer_size=131072
      max_used_connections=3
      max_threads=153
      thread_count=23
      It is possible that mysqld could use up to
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 468018 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
       
      Thread pointer: 0x7f5aec000c18
      Attempting backtrace. You can use the following information to find out
      where mysqld died. If you see no messages after this, something went
      terribly wrong...
      stack_bottom = 0x7f5b88156df0 thread_stack 0x49000
      mysys/stacktrace.c:212(my_print_stacktrace)[0x557009264d98]
      sql/signal_handler.cc:236(handle_fatal_signal)[0x557008aef1fc]
      ??:0(__restore_rt)[0x7f5b9e976980]
      sql/sql_base.cc:6293(find_field_in_table(THD*, TABLE*, char const*, unsigned long, bool, unsigned short*))[0x5570086ae897]
      sql/sql_base.cc:6455(find_field_in_table_ref(THD*, TABLE_LIST*, char const*, unsigned long, char const*, char const*, char const*, List<TABLE_LIST>*, Item**, bool, bool, unsigned short*, bool, TABLE_LIST**))[0x5570086af3b3]
      sql/sql_base.cc:6765(find_field_in_tables(THD*, Item_ident*, TABLE_LIST*, TABLE_LIST*, List<TABLE_LIST>*, Item**, find_item_error_report_type, bool, bool))[0x5570086b054b]
      sql/item.cc:6024(Item_field::fix_fields(THD*, Item**))[0x557008b1fe4a]
      sql/item.h:1147(Item::fix_fields_if_needed_for_scalar(THD*, Item**))[0x55700862f480]
      sql/sql_select.cc:25730(find_order_in_list(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, st_order*, List<Item>&, List<Item>&, bool, bool, bool))[0x5570087b6a42]
      sql/sql_select.cc:25854(setup_group(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, List<Item>&, List<Item>&, st_order*, bool*, bool))[0x5570087fd2bd]
      sql/sql_select.cc:904(setup_without_group(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, List<TABLE_LIST>&, List<Item>&, List<Item>&, Item**, st_order*, st_order*, List<Window_spec>&, List<Item_window_func>&, bool*, unsigned int*))[0x5570087b498f]
      sql/sql_select.cc:5056(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x5570087b0423]
      sql/sql_select.cc:581(handle_select(THD*, LEX*, select_result*, unsigned long long))[0x5570087b01c4]
      sql/sql_parse.cc:6263(execute_sqlcom_select(THD*, TABLE_LIST*))[0x55700876340a]
      sql/sql_parse.cc:3947(mysql_execute_command(THD*, bool))[0x5570087607b3]
      sql/sql_parse.cc:8015(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x557008751037]
      sql/sql_parse.cc:1896(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x55700874e114]
      sql/sql_parse.cc:1407(do_command(THD*, bool))[0x55700875161e]
      sql/sql_connect.cc:1416(do_handle_one_connection(CONNECT*, bool))[0x557008913063]
      sql/sql_connect.cc:1322(handle_one_connection)[0x557008912ce7]
      perfschema/pfs.cc:2203(pfs_spawn_thread)[0x557008debc10]
      nptl/pthread_create.c:463(start_thread)[0x7f5b9e96b6db]
      x86_64/clone.S:97(clone)[0x7f5b9de6b61f]
       
      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x7f5aec012070): SELECT ra7 . c0 ca5 FROM t0 ra7 WINDOW v AS ( ORDER BY ( SELECT ra8 . ca4 ca1 FROM v0 ra8 GROUP BY ra8 . ca4 WINDOW v AS ( PARTITION BY ra8 . ca3 ) ) )
       
      Connection ID (thread ID): 3611
      Status: NOT_KILLED
       
      Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
      

      Attachments

        Issue Links

          Activity

            alice Alice Sherepa added a comment -

            I could not repeat the bug on recent 10.4-11.2, works as expected. Could you please check if it is repeatable on your side with 10.11.5? And if yes - what non-default options were used?

            alice Alice Sherepa added a comment - I could not repeat the bug on recent 10.4-11.2, works as expected. Could you please check if it is repeatable on your side with 10.11.5? And if yes - what non-default options were used?
            wulian jiaqi added a comment - - edited

            I can reproduce it successfully with default options on 10.11.1 but can not reproduce it on 10.11.5.
            The MariaDB server is built from the source code with committed ID 2437674291f31c91869a74eb6ebd9f03dc52bd43.

            commit 2437674291f31c91869a74eb6ebd9f03dc52bd43 (grafted, HEAD, tag: mariadb-10.11.1)
            Author: Oleksandr Byelkin <sanja@mariadb.com>
            Date:   Mon Nov 14 19:10:21 2022 +0100
             
                Merge branch '10.10' into 10.11
            

            To avoid interference with the old database state, I perform the PoC on a new initialized database.
            Specifically, I use `./scripts/mariadb-install-db --datadir=./data2` to initial a new database, and start the server with command `./bin/mariadbd --datadir=./data2`, then use the `./bin/mariadb` to connect the server and execute the PoC.
            It leads to:

            Welcome to the MariaDB monitor.  Commands end with ; or \g.
            Your MariaDB connection id is 3
            Server version: 10.11.1-MariaDB Source distribution
             
            Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
             
            Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
             
            MariaDB [(none)]> show databases;
            +--------------------+
            | Database           |
            +--------------------+
            | information_schema |
            | mysql              |
            | performance_schema |
            | sys                |
            | test               |
            +--------------------+
            5 rows in set (0.000 sec)
             
            MariaDB [(none)]> use test;
            Database changed
            MariaDB [test]> show tables;
            Empty set (0.000 sec)
             
            MariaDB [test]> CREATE TABLE t0 ( c0 INT ( 0 ) UNSIGNED AUTO_INCREMENT PRIMARY KEY ) DEFAULT CHARSET = utf8 ;
            Query OK, 0 rows affected (0.044 sec)
             
            MariaDB [test]> CREATE VIEW v0 AS SELECT ra6 . c0 ca3 , ra6 . c0 AS ca4 FROM t0 ra5 CROSS JOIN t0 ra6 WHERE CAST( ra6 . c0 AS FLOAT ) = 0.005000 LIMIT 1 ;
            Query OK, 0 rows affected (0.020 sec)
             
            MariaDB [test]> SELECT ra7 . c0 ca5 FROM t0 ra7 WINDOW v AS ( ORDER BY ( SELECT ra8 . ca4 ca1 FROM v0 ra8 GROUP BY ra8 . ca4 WINDOW v AS ( PARTITION BY ra8 . ca3 ) ) ) ;
            ERROR 2013 (HY000): Lost connection to server during query
            

            The optimizer switch is "index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off".

            wulian jiaqi added a comment - - edited I can reproduce it successfully with default options on 10.11.1 but can not reproduce it on 10.11.5. The MariaDB server is built from the source code with committed ID 2437674291f31c91869a74eb6ebd9f03dc52bd43. commit 2437674291f31c91869a74eb6ebd9f03dc52bd43 (grafted, HEAD, tag: mariadb-10.11.1) Author: Oleksandr Byelkin <sanja@mariadb.com> Date: Mon Nov 14 19:10:21 2022 +0100   Merge branch '10.10' into 10.11 To avoid interference with the old database state, I perform the PoC on a new initialized database. Specifically, I use `./scripts/mariadb-install-db --datadir=./data2` to initial a new database, and start the server with command `./bin/mariadbd --datadir=./data2`, then use the `./bin/mariadb` to connect the server and execute the PoC. It leads to: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 3 Server version: 10.11.1-MariaDB Source distribution   Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.   Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.   MariaDB [(none)]> show databases; + --------------------+ | Database | + --------------------+ | information_schema | | mysql | | performance_schema | | sys | | test | + --------------------+ 5 rows in set (0.000 sec)   MariaDB [(none)]> use test; Database changed MariaDB [test]> show tables; Empty set (0.000 sec)   MariaDB [test]> CREATE TABLE t0 ( c0 INT ( 0 ) UNSIGNED AUTO_INCREMENT PRIMARY KEY ) DEFAULT CHARSET = utf8 ; Query OK, 0 rows affected (0.044 sec)   MariaDB [test]> CREATE VIEW v0 AS SELECT ra6 . c0 ca3 , ra6 . c0 AS ca4 FROM t0 ra5 CROSS JOIN t0 ra6 WHERE CAST ( ra6 . c0 AS FLOAT ) = 0.005000 LIMIT 1 ; Query OK, 0 rows affected (0.020 sec)   MariaDB [test]> SELECT ra7 . c0 ca5 FROM t0 ra7 WINDOW v AS ( ORDER BY ( SELECT ra8 . ca4 ca1 FROM v0 ra8 GROUP BY ra8 . ca4 WINDOW v AS ( PARTITION BY ra8 . ca3 ) ) ) ; ERROR 2013 (HY000): Lost connection to server during query The optimizer switch is "index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off".
            wulian jiaqi added a comment - - edited

            I found an inconsistent behavior with both 10.11.5 and 10.11.1, which may be with the build environment.
            When using gcc/g++(version 8.4.0), the client shows `utf8mb3` csname replace warning message while logging into the server.

            ./bin/mariadb: Warning: Charset id '33' csname 'utf8' trying to replace existing csname 'utf8mb3'
            ./bin/mariadb: Warning: Charset id '83' csname 'utf8' trying to replace existing csname 'utf8mb3'
            

            In addition, the first statements will lead to an error.

            MariaDB [test]> CREATE TABLE t0 ( c0 INT ( 0 ) UNSIGNED AUTO_INCREMENT PRIMARY KEY ) DEFAULT CHARSET = utf8 ;
            ERROR 1115 (42000): Unknown character set: 'utf8'
            

            To trigger a bug on 10.11.1 compiled by gcc needs to replace "utf8" with "utf8mb3".

            wulian jiaqi added a comment - - edited I found an inconsistent behavior with both 10.11.5 and 10.11.1, which may be with the build environment. When using gcc/g++(version 8.4.0), the client shows `utf8mb3` csname replace warning message while logging into the server. ./bin/mariadb: Warning: Charset id '33' csname 'utf8' trying to replace existing csname 'utf8mb3' ./bin/mariadb: Warning: Charset id '83' csname 'utf8' trying to replace existing csname 'utf8mb3' In addition, the first statements will lead to an error. MariaDB [test]> CREATE TABLE t0 ( c0 INT ( 0 ) UNSIGNED AUTO_INCREMENT PRIMARY KEY ) DEFAULT CHARSET = utf8 ; ERROR 1115 ( 42000 ): Unknown character set: 'utf8' To trigger a bug on 10.11.1 compiled by gcc needs to replace "utf8" with "utf8mb3".
            alice Alice Sherepa added a comment -

            I repeated on 10.11.1
            The bug was fixed by ea270178b09bb1e2e commit (MDEV-30052)

            alice Alice Sherepa added a comment - I repeated on 10.11.1 The bug was fixed by ea270178b09bb1e2e commit ( MDEV-30052 )

            People

              Unassigned Unassigned
              wulian jiaqi
              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.