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

            Descending order - Click to sort in ascending order
            shagalla Galina Shalygina (Inactive) added a comment -

            Pushed in 10.4

            shagalla Galina Shalygina (Inactive) added a comment - Pushed in 10.4
            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 - - 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.

            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.