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

server crashes in Bitmap<64u>::merge

Details

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

    Description

      CREATE TABLE t1  (pk int,i2 int,i1 int,v1 varchar(1)) ;
      		 
      CREATE TABLE t2  (pk int,i2 int,i1 int,v1 varchar(1)) ;
      		 
      CREATE TABLE t31 (pk int,i2 int,i1 int,v1 varchar(1)) ;
      		 
       
      		 
      SELECT t1.v1, 10 as kk
      		 
      FROM (t1 JOIN ((select * from t31) as t3 JOIN t2 ON (t2.pk = t3.pk)) ON (t2.i2 = t3.pk))
      		 
      WHERE EXISTS(SELECT t2.v1 FROM (t2 JOIN t2 as t1 ON (t1.v1 = t2.v1))
      		 
                WHERE t3.i1 IN (SELECT tmp1.i1 FROM t1 as tmp1 HAVING tmp1.i1 < 's'))
      		 
      HAVING kk <= 1;


        10.4 5abc79dd7ab2fccb4b05ca
      		 
      #4  0x000055849ab8e706 in Bitmap<64u>::merge (this=0x1b0, map2=...) at 10.4/sql/sql_bitmap.h:196
      		 
      #5  0x000055849ab5568a in add_key_field (join=0x7f5b540491a0, key_fields=0x7f5b64a16e48, and_level=0, cond=0x7f5b54050a78, field=0x7f5b54188510, eq_func=true, value=0x7f5b64a16d00, num_values=1, usable_tables=18446744073709551615, sargables=0x7f5b64a16fc8, row_col_no=0) at 10.4/sql/sql_select.cc:5398
      		 
      #6  0x000055849ab56c5b in Item_equal::add_key_fields (this=0x7f5b54050a78, join=0x7f5b540491a0, key_fields=0x7f5b64a16e48, and_level=0x7f5b64a16e38, usable_tables=18446744073709551615, sargables=0x7f5b64a16fc8) at 10.4/sql/sql_select.cc:5869
      		 
      #7  0x000055849ab55cce in Item_cond_and::add_key_fields (this=0x7f5b54050bd8, join=0x7f5b540491a0, key_fields=0x7f5b64a16e48, and_level=0x7f5b64a16e38, usable_tables=18446744073709551615, sargables=0x7f5b64a16fc8) at 10.4/sql/sql_select.cc:5593
      		 
      #8  0x000055849ab57f26 in update_ref_and_keys (thd=0x7f5b54000b00, keyuse=0x7f5b54049490, join_tab=0x7f5b54050d10, tables=3, cond=0x7f5b54050bd8, normal_tables=18446744073709551615, select_lex=0x7f5b54019430, sargables=0x7f5b64a16fc8) at 10.4/sql/sql_select.cc:6273
      		 
      #9  0x000055849ab52938 in make_join_statistics (join=0x7f5b540491a0, tables_list=..., keyuse_array=0x7f5b54049490) at 10.4/sql/sql_select.cc:4575
      		 
      #10 0x000055849ab49562 in JOIN::optimize_inner (this=0x7f5b540491a0) at 10.4/sql/sql_select.cc:1933
      		 
      #11 0x000055849ab4783b in JOIN::optimize (this=0x7f5b540491a0) at 10.4/sql/sql_select.cc:1448
      		 
      #12 0x000055849aad871d in st_select_lex::optimize_unflattened_subqueries (this=0x7f5b54015100, const_only=false) at 10.4/sql/sql_lex.cc:4102
      		 
      #13 0x000055849acc42d4 in JOIN::optimize_unflattened_subqueries (this=0x7f5b540f9a10) at 10.4/sql/opt_subselect.cc:5292
      		 
      #14 0x000055849ab4bcf9 in JOIN::optimize_stage2 (this=0x7f5b540f9a10) at 10.4/sql/sql_select.cc:2672
      		 
      #15 0x000055849ab4965a in JOIN::optimize_inner (this=0x7f5b540f9a10) at 10.4/sql/sql_select.cc:1959
      		 
      #16 0x000055849ab4783b in JOIN::optimize (this=0x7f5b540f9a10) at 10.4/sql/sql_select.cc:1448
      		 
      #17 0x000055849ab518df in mysql_select (thd=0x7f5b54000b00, tables=0x7f5b54015750, wild_num=0, fields=..., conds=0x7f5b540f8c08, og_num=0, order=0x0, group=0x0, having=0x7f5b540f8f80, proc_param=0x0, select_options=2147748608, result=0x7f5b540f99f0, unit=0x7f5b540049a8, select_lex=0x7f5b54015100) at 10.4/sql/sql_select.cc:4268
      		 
      #18 0x000055849ab432de in handle_select (thd=0x7f5b54000b00, lex=0x7f5b540048e0, result=0x7f5b540f99f0, setup_tables_done_option=0) at 10.4/sql/sql_select.cc:382
      		 
      #19 0x000055849ab0dba7 in execute_sqlcom_select (thd=0x7f5b54000b00, all_tables=0x7f5b54015750) at 10.4/sql/sql_parse.cc:6549
      		 
      #20 0x000055849ab04000 in mysql_execute_command (thd=0x7f5b54000b00) at 10.4/sql/sql_parse.cc:3771
      		 
      #21 0x000055849ab11984 in mysql_parse (thd=0x7f5b54000b00, rawbuf=0x7f5b54014e88 "SELECT t1.v1, 10 as kk\nFROM (t1 JOIN ((select * from t31) as t3 JOIN t2 ON (t2.pk = t3.pk)) ON (t2.i2 = t3.pk))\nWHERE EXISTS(SELECT t2.v1 FROM (t2 JOIN t2 as t1 ON (t1.v1 = t2.v1))\nWHERE t3.i1 IN (SEL"..., length=265, parser_state=0x7f5b64a18470, is_com_multi=false, is_next_command=false) at 10.4/sql/sql_parse.cc:8078
      		 
      #22 0x000055849aafea62 in dispatch_command (command=COM_QUERY, thd=0x7f5b54000b00, packet=0x7f5b54092ae1 "SELECT t1.v1, 10 as kk\nFROM (t1 JOIN ((select * from t31) as t3 JOIN t2 ON (t2.pk = t3.pk)) ON (t2.i2 = t3.pk))\nWHERE EXISTS(SELECT t2.v1 FROM (t2 JOIN t2 as t1 ON (t1.v1 = t2.v1))\nWHERE t3.i1 IN (SEL"..., packet_length=265, is_com_multi=false, is_next_command=false) at 10.4/sql/sql_parse.cc:1850
      		 
      #23 0x000055849aafd47f in do_command (thd=0x7f5b54000b00) at 10.4/sql/sql_parse.cc:1395
      		 
      #24 0x000055849ac64333 in do_handle_one_connection (connect=0x55849dc976f0) at 10.4/sql/sql_connect.cc:1402
      		 
      #25 0x000055849ac64084 in handle_one_connection (arg=0x55849dc976f0) at 10.4/sql/sql_connect.cc:1308
      		 
      #26 0x000055849b548b44 in pfs_spawn_thread (arg=0x55849dd1ba00) at 10.4/storage/perfschema/pfs.cc:1862
      		 
      #27 0x00007f5b6c3066ba in start_thread (arg=0x7f5b64a19700) at pthread_create.c:333
      		 
      #28 0x00007f5b6b79b41d 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-16730 server crashes in Bitmap<64u>::merge

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-16738 Assertion `!join->conds || !join->cond_equal || !join->cond_equal->current_level.elements || (join->conds->type() == Item::COND_ITEM && ((Item_cond*) (join->conds))->functype() == Item_func::COND_AND_FUNC && join->cond_equal == &((Item_cond_and *)...

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17354 Server crashes in add_key_field / .. / Item_func_null_predicate::add_key_fields upon INSERT .. SELECT

          • Major - Major loss of function.
          • Closed

          Activity

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

            The error occurs because of the MDEV-12387 changes. The bug is similar with he bug from MDEV-16730.

            Let’s consider the example from the description.
            The server crashes in Bitmap<64u>::merge() method trying to take a field from 0 item.

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

            The failing call is made while processing of the "multiple equal(t31.i1, `<subquery4>`.i1)" condition. If to run the same test in the version of MariaDB before MDEV-12387 it can be found that this multiple equality shouldn’t be transformed into the multiple equality but should remain as equality.

            This equality is transformed into the multiple equality in the and_new_conditions_to_optimized_cond() method in check_simple_equality() call. If to run the same test in the previous version of MariaDB equality is not transformed because the left item of the equality is of REF_ITEM type. In the current version it is FIELD_ITEM type which is wrong. It is because as the left and right items of the equality real items of these items are passed to the check_simple_equality() method instead of the items themselves. It is a mistake.

            After the proper changes the server crashes in the make_join_statistics() method. It can be seen that in the and_new_conditions_to_optimized_cond() method conds is saved in the wrong way. It is because of the case when single equality eq is added to the single multiple equality mult_eq. This case is missing. As the result the multiple equality mult_eq is missing and only equality eq is saved. That causes a crash.

            shagalla Galina Shalygina (Inactive) added a comment - The error occurs because of the MDEV-12387 changes. The bug is similar with he bug from MDEV-16730 . Let’s consider the example from the description. The server crashes in Bitmap<64u>::merge() method trying to take a field from 0 item. (gdb) print stat[0] Cannot access memory at address 0x0 The failing call is made while processing of the "multiple equal(t31.i1, `<subquery4>`.i1)" condition. If to run the same test in the version of MariaDB before MDEV-12387 it can be found that this multiple equality shouldn’t be transformed into the multiple equality but should remain as equality. This equality is transformed into the multiple equality in the and_new_conditions_to_optimized_cond() method in check_simple_equality() call. If to run the same test in the previous version of MariaDB equality is not transformed because the left item of the equality is of REF_ITEM type. In the current version it is FIELD_ITEM type which is wrong. It is because as the left and right items of the equality real items of these items are passed to the check_simple_equality() method instead of the items themselves. It is a mistake. After the proper changes the server crashes in the make_join_statistics() method. It can be seen that in the and_new_conditions_to_optimized_cond() method conds is saved in the wrong way. It is because of the case when single equality eq is added to the single multiple equality mult_eq. This case is missing. As the result the multiple equality mult_eq is missing and only equality eq is saved. That causes a crash.
            igor Igor Babaev (Inactive) added a comment -

            Galina submitted a patch that actually fixed two different bugs in the function and_new_conditions_to_optimized_cond(). One of these bugs was fixed by the patch for MDEV-17360. After this patch the reported test case still causes a crash. A similar crash can be reproduced by the following simple test case:

            CREATE TABLE t1 (pk int, i1 int, v1 varchar(1));
            		 
            INSERT INTO t1 VALUES (3,2,'x'), (1,1,'y'), (4,2,'z');
            		 
             
            		 
            CREATE TABLE t2 (pk int, i1 int, v1 varchar(1));
            		 
            INSERT INTO t1 VALUES (5,2,'x'), (7,1,'x');
            		 
             
            		 
            CREATE TABLE t3 (pk int, i1 int, v1 varchar(1));
            		 
            INSERT INTO t1 VALUES (8,2,'x'), (7,1,'z');
            		 
             
            		 
            SELECT t3.i1 FROM t3
            		 
              WHERE EXISTS ( SELECT t2.v1 FROM t1,t2
            		 
                               WHERE t1.v1 = t2.v1 AND 
                                     t3.i1 IN (SELECT t.i1 FROM t1 as t
            		 
                                                GROUP BY i1 HAVING t.i1 < 3));

            Galina's patch fixes the problem.

            igor Igor Babaev (Inactive) added a comment - Galina submitted a patch that actually fixed two different bugs in the function and_new_conditions_to_optimized_cond(). One of these bugs was fixed by the patch for MDEV-17360 . After this patch the reported test case still causes a crash. A similar crash can be reproduced by the following simple test case: CREATE TABLE t1 (pk int , i1 int , v1 varchar (1)); INSERT INTO t1 VALUES (3,2, 'x' ), (1,1, 'y' ), (4,2, 'z' );   CREATE TABLE t2 (pk int , i1 int , v1 varchar (1)); INSERT INTO t1 VALUES (5,2, 'x' ), (7,1, 'x' );   CREATE TABLE t3 (pk int , i1 int , v1 varchar (1)); INSERT INTO t1 VALUES (8,2, 'x' ), (7,1, 'z' );   SELECT t3.i1 FROM t3 WHERE EXISTS ( SELECT t2.v1 FROM t1,t2 WHERE t1.v1 = t2.v1 AND t3.i1 IN ( SELECT t.i1 FROM t1 as t GROUP BY i1 HAVING t.i1 < 3)); Galina's patch fixes the problem.
            igor Igor Babaev (Inactive) added a comment -

            A fix for this bug was pushed into 10.4.

            igor Igor Babaev (Inactive) added a comment - A fix for this bug was pushed into 10.4.

            People

              igor Igor Babaev (Inactive)
              alice Alice Sherepa
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.