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

server crashes in Bitmap<64u>::merge

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.4(EOL)
    • 10.4.0
    • Optimizer
    • None

    Description

      Reproducible on 10.4, with MyIsam/Innodb

      CREATE TABLE t1 (i1 int, i2 int);
      		 
      CREATE TABLE t2 (i1 int, i2 int);
      		 
      CREATE TABLE t3 (i1 int, i2 int);
      		 
      CREATE TABLE t4 (i1 int, i2 int);
      		 
      CREATE TABLE t5 (i1 int, i2 int);
      		 
       
      		 
      SELECT 1 FROM ((SELECT DISTINCT t2.*
      		 
                FROM (t2 LEFT JOIN (t1 RIGHT JOIN t3 ON (t3.i1 = t1.i1)) ON (t3.i1 = t1.i2))) AS tbl,t4,t3)
      		 
       WHERE tbl.i1 IN (SELECT COUNT(t5.i2) FROM t5);


      Thread 1 (Thread 0x7f38ce4fb700 (LWP 31353)):
      		 
      #0  __pthread_kill (threadid=<optimized out>, signo=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:62
      		 
      #1  0x00005598c89c2761 in my_write_core (sig=11) at /home/alice/git/10.4/mysys/stacktrace.c:481
      		 
      #2  0x00005598c82050d1 in handle_fatal_signal (sig=11) at /home/alice/git/10.4/sql/signal_handler.cc:305
      		 
      #3  <signal handler called>
      		 
      #4  0x00005598c7f9fb48 in Bitmap<64u>::merge (this=0x1b0, map2=...) at /home/alice/git/10.4/sql/sql_bitmap.h:196
      		 
      #5  0x00005598c7f66c05 in add_key_field (join=0x7f38bc14f920, key_fields=0x7f38ce4f9078, and_level=0, cond=0x7f38bc05f118, field=0x7f38bc0620f8, eq_func=true, value=0x7f38bc05f1a8, num_values=1, usable_tables=18446744073709551609, sargables=0x7f38ce4f91f8, row_col_no=0) at /home/alice/git/10.4/sql/sql_select.cc:5391
      		 
      #6  0x00005598c7f6704f in add_key_equal_fields (join=0x7f38bc14f920, key_fields=0x7f38ce4f9078, and_level=0, cond=0x7f38bc05f118, field_item=0x7f38bc05f398, eq_func=true, val=0x7f38bc05f1a8, num_values=1, usable_tables=18446744073709551609, sargables=0x7f38ce4f91f8, row_col_no=0) at /home/alice/git/10.4/sql/sql_select.cc:5512
      		 
      #7  0x00005598c7f67e43 in Item_bool_func2::add_key_fields_optimize_op (this=0x7f38bc05f118, join=0x7f38bc14f920, key_fields=0x7f38ce4f9078, and_level=0x7f38ce4f9068, usable_tables=18446744073709551609, sargables=0x7f38ce4f91f8, equal_func=true) at /home/alice/git/10.4/sql/sql_select.cc:5795
      		 
      #8  0x00005598c825dc7e in Item_func_eq::add_key_fields (this=0x7f38bc05f118, join=0x7f38bc14f920, key_fields=0x7f38ce4f9078, and_level=0x7f38ce4f9068, usable_tables=18446744073709551609, sargables=0x7f38ce4f91f8) at /home/alice/git/10.4/sql/item_cmpfunc.h:715
      		 
      #9  0x00005598c7f694a2 in update_ref_and_keys (thd=0x7f38bc000b00, keyuse=0x7f38bc14fc10, join_tab=0x7f38bc063778, tables=3, cond=0x7f38bc05f118, normal_tables=18446744073709551609, select_lex=0x7f38bc015520, sargables=0x7f38ce4f91f8) at /home/alice/git/10.4/sql/sql_select.cc:6266
      		 
      #10 0x00005598c7f63e9c in make_join_statistics (join=0x7f38bc14f920, tables_list=..., keyuse_array=0x7f38bc14fc10) at /home/alice/git/10.4/sql/sql_select.cc:4568
      		 
      #11 0x00005598c7f5aad3 in JOIN::optimize_inner (this=0x7f38bc14f920) at /home/alice/git/10.4/sql/sql_select.cc:1926
      		 
      #12 0x00005598c7f58f33 in JOIN::optimize (this=0x7f38bc14f920) at /home/alice/git/10.4/sql/sql_select.cc:1448
      		 
      #13 0x00005598c7ec8257 in mysql_derived_optimize (thd=0x7f38bc000b00, lex=0x7f38bc0048e0, derived=0x7f38bc018c08) at /home/alice/git/10.4/sql/sql_derived.cc:936
      		 
      #14 0x00005598c7ec681f in mysql_handle_single_derived (lex=0x7f38bc0048e0, derived=0x7f38bc018c08, phases=4) at /home/alice/git/10.4/sql/sql_derived.cc:198
      		 
      #15 0x00005598c7f5a026 in JOIN::optimize_inner (this=0x7f38bc14f2c8) at /home/alice/git/10.4/sql/sql_select.cc:1743
      		 
      #16 0x00005598c7f58f33 in JOIN::optimize (this=0x7f38bc14f2c8) at /home/alice/git/10.4/sql/sql_select.cc:1448
      		 
      #17 0x00005598c7f62e43 in mysql_select (thd=0x7f38bc000b00, tables=0x7f38bc018c08, wild_num=0, fields=..., conds=0x7f38bc14e748, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f38bc14f2a8, unit=0x7f38bc0049a8, select_lex=0x7f38bc015048) at /home/alice/git/10.4/sql/sql_select.cc:4261
      		 
      #18 0x00005598c7f549d6 in handle_select (thd=0x7f38bc000b00, lex=0x7f38bc0048e0, result=0x7f38bc14f2a8, setup_tables_done_option=0) at /home/alice/git/10.4/sql/sql_select.cc:382
      		 
      #19 0x00005598c7f1f315 in execute_sqlcom_select (thd=0x7f38bc000b00, all_tables=0x7f38bc018c08) at /home/alice/git/10.4/sql/sql_parse.cc:6545
      		 
      #20 0x00005598c7f1576e in mysql_execute_command (thd=0x7f38bc000b00) at /home/alice/git/10.4/sql/sql_parse.cc:3768
      		 
      #21 0x00005598c7f2304d in mysql_parse (thd=0x7f38bc000b00, rawbuf=0x7f38bc014e88 "SELECT 1 FROM ((SELECT DISTINCT t2.*\nFROM (t2 LEFT JOIN (t1 RIGHT JOIN t3 ON (t3.i1 = t1.i1)) ON (t3.i1 = t1.i2))) AS tbl,t4,t3)\nWHERE tbl.i1 IN (SELECT COUNT(t5.i2) FROM t5)", length=174, parser_state=0x7f38ce4fa5f0, is_com_multi=false, is_next_command=false) at /home/alice/git/10.4/sql/sql_parse.cc:8063
      		 
      #22 0x00005598c7f101d0 in dispatch_command (command=COM_QUERY, thd=0x7f38bc000b00, packet=0x7f38bc00b441 "SELECT 1 FROM ((SELECT DISTINCT t2.*\nFROM (t2 LEFT JOIN (t1 RIGHT JOIN t3 ON (t3.i1 = t1.i1)) ON (t3.i1 = t1.i2))) AS tbl,t4,t3)\nWHERE tbl.i1 IN (SELECT COUNT(t5.i2) FROM t5)", packet_length=174, is_com_multi=false, is_next_command=false) at /home/alice/git/10.4/sql/sql_parse.cc:1847
      		 
      #23 0x00005598c7f0ebed in do_command (thd=0x7f38bc000b00) at /home/alice/git/10.4/sql/sql_parse.cc:1392
      		 
      #24 0x00005598c8075613 in do_handle_one_connection (connect=0x5598ca88ab20) at /home/alice/git/10.4/sql/sql_connect.cc:1402
      		 
      #25 0x00005598c8075364 in handle_one_connection (arg=0x5598ca88ab20) at /home/alice/git/10.4/sql/sql_connect.cc:1308
      		 
      #26 0x00005598c8952baa in pfs_spawn_thread (arg=0x5598ca892c10) at /home/alice/git/10.4/storage/perfschema/pfs.cc:1862
      		 
      #27 0x00007f38d4f9a6ba in start_thread (arg=0x7f38ce4fb700) at pthread_create.c:333
      		 
      #28 0x00007f38d442f41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17027 server crashes in Bitmap<64u>::merge

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            shagalla Galina Shalygina (Inactive) added a comment - - edited

            The bug appears in Bitmap<64u>::merge() method because it tries to take a field from the NULL element.
            So in stat[0].keys.merge(possible_keys); call:

            (gdb) print stat[0]
            		 
            Cannot access memory at address 0x0

            This bug appears because of MDEV-12387 changes.
            It can be seen that the problem is got because of the conds in the considered select:

            (gdb) p dbug_print_select(select_lex)
            		 
            $1 = 0x5555573bb0a0 <dbug_item_print_buf> "select distinct t2.i1 AS i1,t2.i2 AS i2 from test.t2 left join (test.t3 join test.t1) on(multiple equal(t3.i1, t1.i2, t1.i1)) where t2.i1 = `<subquery3>`.`COUNT(t5.i2)`"
            		 
            (gdb) p dbug_print_item(conds)
            		 
            $1 = 0x5555573bb0a0 <dbug_item_print_buf> "t2.i1 = `<subquery3>`.`COUNT(t5.i2)`"

            This condition was got after the pushdown into the materialized derived tables/views optimization.
            Obviously, it shouldn't be pushed down and it's a mistake.

            Looking why it was pushed down it can be found that it happened because of the wrong table_map (map of the tables used in this condition) for the "tbl.i1 = `<subquery3>`.`COUNT(t5.i2)`" condition.

            This condition is created in setup_jtbm_semi_joins() method. It joins parent select and IN subquery. In the and_new_conditions_to_optimized_cond() method it is attached to conds of the parent select. These calls are made after the optimize_inner() call for conds. The result of this join should be the same as if it was made before optimize_cond() for conds. Comparing with the previous version of the system before MDEV-12387 changes it can be found that update_used_tables() call is missing.

            This call should be made in the setup_jtbm_semi_joins() method for the equalities that are recieved after the IN subquery optimization. These equalities are the equalities that join parent select and IN subquery.

            shagalla Galina Shalygina (Inactive) added a comment - - edited The bug appears in Bitmap<64u>::merge() method because it tries to take a field from the NULL element. So in stat [0] .keys.merge(possible_keys); call: (gdb) print stat[0] Cannot access memory at address 0x0 This bug appears because of MDEV-12387 changes. It can be seen that the problem is got because of the conds in the considered select: (gdb) p dbug_print_select(select_lex) $1 = 0x5555573bb0a0 <dbug_item_print_buf> "select distinct t2.i1 AS i1,t2.i2 AS i2 from test.t2 left join (test.t3 join test.t1) on(multiple equal(t3.i1, t1.i2, t1.i1)) where t2.i1 = `<subquery3>`.`COUNT(t5.i2)`" (gdb) p dbug_print_item(conds) $1 = 0x5555573bb0a0 <dbug_item_print_buf> "t2.i1 = `<subquery3>`.`COUNT(t5.i2)`" This condition was got after the pushdown into the materialized derived tables/views optimization. Obviously, it shouldn't be pushed down and it's a mistake. Looking why it was pushed down it can be found that it happened because of the wrong table_map (map of the tables used in this condition) for the "tbl.i1 = `<subquery3>`.`COUNT(t5.i2)`" condition. This condition is created in setup_jtbm_semi_joins() method. It joins parent select and IN subquery. In the and_new_conditions_to_optimized_cond() method it is attached to conds of the parent select. These calls are made after the optimize_inner() call for conds. The result of this join should be the same as if it was made before optimize_cond() for conds. Comparing with the previous version of the system before MDEV-12387 changes it can be found that update_used_tables() call is missing. This call should be made in the setup_jtbm_semi_joins() method for the equalities that are recieved after the IN subquery optimization. These equalities are the equalities that join parent select and IN subquery.
            igor Igor Babaev (Inactive) added a comment -

            Ok to push

            igor Igor Babaev (Inactive) added a comment - Ok to push
            shagalla Galina Shalygina (Inactive) added a comment -

            Pushed in 10.4

            shagalla Galina Shalygina (Inactive) added a comment - Pushed in 10.4

            People

              shagalla Galina Shalygina (Inactive)
              alice Alice Sherepa
              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.