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

Assertion `(mem_root->flags & 4) == 0' failed in convert_subq_to_jtbm

Details

    Description

      CREATE TABLE t (a INT, b INT, c INT);
      		 
      INSERT INTO t VALUES (1,2,3),(4,5,6);
      		 
      CREATE ALGORITHM=TEMPTABLE VIEW v1 AS SELECT * FROM t;
      		 
      CREATE VIEW v2 AS SELECT * FROM v1;
      		 
      PREPARE stmt FROM 'UPDATE t SET a = 0 WHERE b IN (SELECT c FROM v2)';
      		 
      EXECUTE stmt;
      		 
      EXECUTE stmt;
      		 
       
      		 
      # Cleanup
      		 
      DROP VIEW v2;
      		 
      DROP VIEW v1;
      		 
      DROP TABLE t;

      10.5 3cd706b107d3a0ada15aa8728ba876fc161ac0d5

      		 
      mariadbd: /data/bld/10.5-asan/mysys/my_alloc.c:212: alloc_root: Assertion `(mem_root->flags & 4) == 0' failed.
      		 
      241024 18:33:46 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #9  0x00007f9d03e53e32 in __GI___assert_fail (assertion=0x563bc8917960 "(mem_root->flags & 4) == 0", file=0x563bc8917660 "/data/bld/10.5-asan/mysys/my_alloc.c", line=212, function=0x563bc8917c80 <__PRETTY_FUNCTION__.0> "alloc_root") at ./assert/assert.c:101
      		 
      #10 0x0000563bc754843b in alloc_root (mem_root=0x61900009f518, length=20) at /data/bld/10.5-asan/mysys/my_alloc.c:212
      		 
      #11 0x0000563bc5460a56 in Query_arena::calloc (this=0x62b000069230, size=20) at /data/bld/10.5-asan/sql/sql_class.h:1218
      		 
      #12 0x0000563bc5c52379 in convert_subq_to_jtbm (parent_join=0x62b000039058, subq_pred=0x62b00009e090, remove_item=0x7f9cfa974700) at /data/bld/10.5-asan/sql/opt_subselect.cc:2073
      		 
      #13 0x0000563bc5c4c9a5 in convert_join_subqueries_to_semijoins (join=0x62b000039058) at /data/bld/10.5-asan/sql/opt_subselect.cc:1330
      		 
      #14 0x0000563bc57d01f1 in JOIN::optimize_inner (this=0x62b000039058) at /data/bld/10.5-asan/sql/sql_select.cc:1994
      		 
      #15 0x0000563bc57cdfc1 in JOIN::optimize (this=0x62b000039058) at /data/bld/10.5-asan/sql/sql_select.cc:1765
      		 
      #16 0x0000563bc57ef188 in mysql_select (thd=0x62b000069218, tables=0x62b00009bfa8, fields=..., conds=0x629000255668, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2200096997504, result=0x62b000038f30, unit=0x62b00009a310, select_lex=0x62b00009ab48) at /data/bld/10.5-asan/sql/sql_select.cc:4904
      		 
      #17 0x0000563bc5a34e7f in mysql_multi_update (thd=0x62b000069218, table_list=0x62b00009bfa8, fields=0x62b00009acb0, values=0x62b00009b270, conds=0x629000255668, options=0, handle_duplicates=DUP_ERROR, ignore=false, unit=0x62b00009a310, select_lex=0x62b00009ab48, result=0x7f9cfa9752c0) at /data/bld/10.5-asan/sql/sql_update.cc:2003
      		 
      #18 0x0000563bc5717cf2 in mysql_execute_command (thd=0x62b000069218) at /data/bld/10.5-asan/sql/sql_parse.cc:4574
      		 
      #19 0x0000563bc57872c6 in Prepared_statement::execute (this=0x61900009f198, expanded_query=0x7f9cfa975d70, open_cursor=false) at /data/bld/10.5-asan/sql/sql_prepare.cc:5131
      		 
      #20 0x0000563bc578240d in Prepared_statement::execute_loop (this=0x61900009f198, expanded_query=0x7f9cfa975d70, open_cursor=false, packet=0x0, packet_end=0x0) at /data/bld/10.5-asan/sql/sql_prepare.cc:4553
      		 
      #21 0x0000563bc577be47 in mysql_sql_stmt_execute (thd=0x62b000069218) at /data/bld/10.5-asan/sql/sql_prepare.cc:3594
      		 
      #22 0x0000563bc5714624 in mysql_execute_command (thd=0x62b000069218) at /data/bld/10.5-asan/sql/sql_parse.cc:4045
      		 
      #23 0x0000563bc5730fab in mysql_parse (thd=0x62b000069218, rawbuf=0x62b000038238 "EXECUTE stmt", length=12, parser_state=0x7f9cfa976c70, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:8237
      		 
      #24 0x0000563bc5706291 in dispatch_command (command=COM_QUERY, thd=0x62b000069218, packet=0x629000235219 "EXECUTE stmt", packet_length=12, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:1891
      		 
      #25 0x0000563bc5702c24 in do_command (thd=0x62b000069218) at /data/bld/10.5-asan/sql/sql_parse.cc:1375
      		 
      #26 0x0000563bc5b5c643 in do_handle_one_connection (connect=0x608000002ab8, put_in_cache=true) at /data/bld/10.5-asan/sql/sql_connect.cc:1407
      		 
      #27 0x0000563bc5b5c1a9 in handle_one_connection (arg=0x608000002a38) at /data/bld/10.5-asan/sql/sql_connect.cc:1319
      		 
      #28 0x0000563bc67b963a in pfs_spawn_thread (arg=0x615000006c18) at /data/bld/10.5-asan/storage/perfschema/pfs.cc:2201
      		 
      #29 0x00007f9d03ea8044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
      		 
      #30 0x00007f9d03f2861c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

      The failure started happening after this commit in 10.5:

      commit 2c3e07df473e26807f097e7a5905f004ef53e890
      		 
      Author: Yuchen Pei
      		 
      Date:   Fri Sep 6 11:34:31 2024 +1000
      		 
       
      		 
          MDEV-34447: Memory leakage is detected on running the test main.ps against the server 11.1

      Attachments

        Issue Links

          is caused by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-34447 Memory leakage is detected on running the test main.ps against the server 11.1

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

          Activity

            Ascending order - Click to sort in descending order
            ycp Yuchen Pei added a comment -

            I can confirm that this bug does not reproduce at the original MDEV-34447 commit at 11.1 e012407397c65df62f9d62577849a80959962fa9, so it looks like purely a problem caused by the backport

            ycp Yuchen Pei added a comment - I can confirm that this bug does not reproduce at the original MDEV-34447 commit at 11.1 e012407397c65df62f9d62577849a80959962fa9, so it looks like purely a problem caused by the backport
            ycp Yuchen Pei added a comment -

            It looks like something in newer versions (possibly 11.1+) such as MDEV-28883 causes the following change for the testcase of this issue:

            10.5: first ps goes through single update only, but the second ps goes through multi update too
            11.2: both ps executions go through multi update

            Because of this change, in 10.5, the first ps execution does not call optimize() on the outer query, but only the subquery, through optimize_unflattened_subqueries(). This resulted in select_lex->first_cond_optimization not set to false during the first ps, causing the assertion failure in the second ps, see the following hunk in the MDEV-34447 patch:

            @@ -1366,10 +1373,10 @@ int mysql_update(THD *thd,
            		 
               }
            		 
               thd->count_cuted_fields= CHECK_FIELD_IGNORE;		/* calc cuted fields */
            		 
               thd->abort_on_warning= 0;
            		 
            -  if (thd->lex->current_select->first_cond_optimization)
            		 
            +  if (!thd->lex->current_select->leaf_tables_saved)
            		 
               {
            		 
                 thd->lex->current_select->save_leaf_tables(thd);
            		 
            -    thd->lex->current_select->first_cond_optimization= 0;
            		 
            +    thd->lex->current_select->leaf_tables_saved= true;
            		 
               }
            		 
               *found_return= found;
            		 
               *updated_return= updated;

            A naive solution would be to restore these lines, which I did in the following draft fixup commit:

            8b953c79fb4 upstream/bb-10.5-mdev-35249 MDEV-35249 Fix regression caused by MDEV-34447

            Waiting for CI...

            ycp Yuchen Pei added a comment - It looks like something in newer versions (possibly 11.1+) such as MDEV-28883 causes the following change for the testcase of this issue: 10.5: first ps goes through single update only, but the second ps goes through multi update too 11.2: both ps executions go through multi update Because of this change, in 10.5, the first ps execution does not call optimize() on the outer query, but only the subquery, through optimize_unflattened_subqueries(). This resulted in select_lex->first_cond_optimization not set to false during the first ps, causing the assertion failure in the second ps, see the following hunk in the MDEV-34447 patch: @@ -1366,10 +1373,10 @@ int mysql_update(THD *thd, } thd->count_cuted_fields= CHECK_FIELD_IGNORE; /* calc cuted fields */ thd->abort_on_warning= 0; - if (thd->lex->current_select->first_cond_optimization) + if (!thd->lex->current_select->leaf_tables_saved) { thd->lex->current_select->save_leaf_tables(thd); - thd->lex->current_select->first_cond_optimization= 0; + thd->lex->current_select->leaf_tables_saved= true; } *found_return= found; *updated_return= updated; A naive solution would be to restore these lines, which I did in the following draft fixup commit: 8b953c79fb4 upstream/bb-10.5-mdev-35249 MDEV-35249 Fix regression caused by MDEV-34447 Waiting for CI...
            ycp Yuchen Pei added a comment - - edited

            Hi shulga, ptal thanks

            b8c2bd9f69d upstream/bb-10.5-mdev-35249 MDEV-35249 Fix regression caused by MDEV-34447

            I wasn't able to verify whether MDEV-28883 caused the behavioural change of from "first ps single table update / second ps multi table update" to "both ps multi table updates", because of strange test failure of the test case in the present issue at the following two-year old commit (see attached stdout)

            3a9358a4106 @ MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements

            ycp Yuchen Pei added a comment - - edited Hi shulga , ptal thanks b8c2bd9f69d upstream/bb-10.5-mdev-35249 MDEV-35249 Fix regression caused by MDEV-34447 I wasn't able to verify whether MDEV-28883 caused the behavioural change of from "first ps single table update / second ps multi table update" to "both ps multi table updates", because of strange test failure of the test case in the present issue at the following two-year old commit (see attached stdout) 3a9358a4106 @ MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
            sanja Oleksandr Byelkin added a comment -

            OK to push with or without proposed changes

            sanja Oleksandr Byelkin added a comment - OK to push with or without proposed changes
            ycp Yuchen Pei added a comment -

            thanks for the review sanja, pushed b8c2bd9f69d60057876ad5d44521a6079f5d60fe to 10.5

            ycp Yuchen Pei added a comment - thanks for the review sanja , pushed b8c2bd9f69d60057876ad5d44521a6079f5d60fe to 10.5

            People

              ycp Yuchen Pei
              elenst Elena Stepanova
              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.