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

Assertion `0' in open_tables upon function-related operations

    XMLWordPrintable

Details

    Description

      The test case fails for me every time on a 10.9 debug build, but it is still a concurrent test, so maybe it can fail to fail in some circumstances. Try to run with --repeat then.

      CREATE TABLE t1 (a INT);
      CREATE TABLE t2 (b INT);
      CREATE TRIGGER tr1 BEFORE INSERT ON t1 FOR EACH ROW UPDATE t2 SET b = 0;
      CREATE TRIGGER tr2 BEFORE INSERT ON t2 FOR EACH ROW UPDATE t1 SET a = 6;
      CREATE VIEW v1 AS SELECT * FROM t1;
       
      SET AUTOCOMMIT=OFF;
      SELECT * FROM t1;
       
      --connect (con1,localhost,root,,test)
      --send
        DROP TRIGGER tr1;
       
      --connection default
      --error ER_LOCK_DEADLOCK
      INSERT INTO t2 SELECT * FROM t2;
      --error ER_SP_DOES_NOT_EXIST
      SELECT f() FROM t2;
       
      --connect (con2,localhost,root,,test)
      --send
        ALTER VIEW v1 AS SELECT f() FROM t1;
       
      --connection con1
      --reap
      --send
      CREATE FUNCTION f() RETURNS INT RETURN 1;
       
      --connection default
      SELECT * FROM ( SELECT * FROM v1 ) sq;
       
      # Cleanup
      COMMIT;
       
      --connection con2
      --reap
       
      DROP VIEW v1;
      DROP FUNCTION f;
      DROP TABLE t1, t2;
      

      10.9 5dba54bf

      mariadbd: /data/src/10.9/sql/sql_base.cc:4658: bool open_tables(THD*, const DDL_options_st&, TABLE_LIST**, uint*, uint, Prelocking_strategy*): Assertion `0' failed.
      220515  2:50:36 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f048119f662 in __GI___assert_fail (assertion=0x55d31ad99007 "0", file=0x55d31ad998d8 "/data/src/10.9/sql/sql_base.cc", line=4658, function=0x55d31ad9b130 "bool open_tables(THD*, const DDL_options_st&, TABLE_LIST**, uint*, uint, Prelocking_strategy*)") at assert.c:101
      #8  0x000055d319f8e449 in open_tables (thd=0x7f0458000db8, options=..., start=0x7f047c2b3868, counter=0x7f047c2b3884, flags=0, prelocking_strategy=0x7f047c2b3908) at /data/src/10.9/sql/sql_base.cc:4658
      #9  0x000055d319f9012e in open_and_lock_tables (thd=0x7f0458000db8, options=..., tables=0x7f0458014030, derived=true, flags=0, prelocking_strategy=0x7f047c2b3908) at /data/src/10.9/sql/sql_base.cc:5540
      #10 0x000055d319f46d7d in open_and_lock_tables (thd=0x7f0458000db8, tables=0x7f0458014030, derived=true, flags=0) at /data/src/10.9/sql/sql_base.h:510
      #11 0x000055d31a196d4f in mysql_create_view (thd=0x7f0458000db8, views=0x7f0458014030, mode=VIEW_ALTER) at /data/src/10.9/sql/sql_view.cc:465
      #12 0x000055d31a043513 in mysql_execute_command (thd=0x7f0458000db8, is_called_from_prepared_stmt=false) at /data/src/10.9/sql/sql_parse.cc:5815
      #13 0x000055d31a04a0b3 in mysql_parse (thd=0x7f0458000db8, rawbuf=0x7f0458013b50 "ALTER VIEW v1 AS SELECT f() FROM t1", length=35, parser_state=0x7f047c2b4500) at /data/src/10.9/sql/sql_parse.cc:8047
      #14 0x000055d31a03670b in dispatch_command (command=COM_QUERY, thd=0x7f0458000db8, packet=0x7f045800b9a9 "ALTER VIEW v1 AS SELECT f() FROM t1", packet_length=35, blocking=true) at /data/src/10.9/sql/sql_parse.cc:1912
      #15 0x000055d31a035038 in do_command (thd=0x7f0458000db8, blocking=true) at /data/src/10.9/sql/sql_parse.cc:1409
      #16 0x000055d31a20a720 in do_handle_one_connection (connect=0x55d31d8624b8, put_in_cache=true) at /data/src/10.9/sql/sql_connect.cc:1418
      #17 0x000055d31a20a3bf in handle_one_connection (arg=0x55d31d8624b8) at /data/src/10.9/sql/sql_connect.cc:1312
      #18 0x000055d31a704a98 in pfs_spawn_thread (arg=0x55d31d96be18) at /data/src/10.9/storage/perfschema/pfs.cc:2201
      #19 0x00007f0481669ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #20 0x00007f0481268def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Reproducible with at least MyISAM and InnoDB.
      No obvious effect on a non-debug build or on 10.8.

      The failure started happening on 10.9 after this commit:

      commit 92bfc0e8c4bb5c86359c29458d67f3e7836ec18a
      Author: Aleksey Midenkov
      Date:   Fri May 6 10:45:17 2022 +0300
       
          MDEV-17554 Auto-create new partition for system versioned tables with history partitioned by INTERVAL/LIMIT
      

      However, I can't claim it is a regression, because the commit added the assert itself:

      +            // FIXME: is this really used?
      +            DBUG_ASSERT(0);
      

      Attachments

        1. bad.log
          4 kB
          Aleksey Midenkov
        2. good.log
          6 kB
          Aleksey Midenkov

        Issue Links

          Activity

            People

              midenok Aleksey Midenkov
              elenst Elena Stepanova
              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.