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

Assertion `!is_arena_for_set_stmt()' failed upon PS with SET STATEMENT within executable comment

    XMLWordPrintable

    Details

      Description

      The issue appears to be 10.2-only and debug-only, so I don't expect it to be fixed, but it has to be filed.

      Execute from MTR with --ps-protocol.

      /*!100102 SET STATEMENT LOCK_WAIT_TIMEOUT= 1 FOR */ SELECT 1;
      select 2;
      

      The second select doesn't affect the outcome, but it seems to help to get a coredump, otherwise the server tends to die in the middle of writing a crash report in the error log, without a coredump.

      10.2 fb9d1519

      mysqld: /data/src/10.2/sql/sql_lex.h:2926: void LEX::free_set_stmt_mem_root(): Assertion `!is_arena_for_set_stmt()' failed.
      210404  2:55:09 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f9cb1b57f36 in __GI___assert_fail (assertion=0x5595de1218bb "!is_arena_for_set_stmt()", file=0x5595de121865 "/data/src/10.2/sql/sql_lex.h", line=2926, function=0x5595de121898 "void LEX::free_set_stmt_mem_root()") at assert.c:101
      #8  0x00005595dd61bab2 in LEX::free_set_stmt_mem_root (this=0x7f9c9407d868) at /data/src/10.2/sql/sql_lex.h:2926
      #9  0x00005595dd61bca8 in LEX::~LEX (this=0x7f9c9407d868, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_lex.h:2939
      #10 0x00005595dd61dec0 in st_lex_local::~st_lex_local (this=0x7f9c9407d868, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_lex.h:3387
      #11 0x00005595dd61dee0 in st_lex_local::~st_lex_local (this=0x7f9c9407d868, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_lex.h:3387
      #12 0x00005595dd6ef23f in Prepared_statement::~Prepared_statement (this=0x7f9c940068b0, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_prepare.cc:4082
      #13 0x00005595dd6ef2b4 in Prepared_statement::~Prepared_statement (this=0x7f9c940068b0, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_prepare.cc:4086
      #14 0x00005595dd681545 in delete_statement_as_hash_key (key=0x7f9c940068b0) at /data/src/10.2/sql/sql_class.cc:3642
      #15 0x00005595de079a34 in my_hash_delete (hash=0x7f9c94002838, record=0x7f9c940068b0 "\350\\s\336\225U") at /data/src/10.2/mysys/hash.c:632
      #16 0x00005595dd681883 in Statement_map::erase (this=0x7f9c94002838, statement=0x7f9c940068b0) at /data/src/10.2/sql/sql_class.cc:3757
      #17 0x00005595dd6f2197 in Prepared_statement::deallocate (this=0x7f9c940068b0) at /data/src/10.2/sql/sql_prepare.cc:5202
      #18 0x00005595dd6ee382 in mysqld_stmt_close (thd=0x7f9c94000d90, packet=0x7f9c94008b51 "\001") at /data/src/10.2/sql/sql_prepare.cc:3720
      #19 0x00005595dd6c1354 in dispatch_command (command=COM_STMT_CLOSE, thd=0x7f9c94000d90, packet=0x7f9c94008b51 "\001", packet_length=4, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1790
      #20 0x00005595dd6c015f in do_command (thd=0x7f9c94000d90) at /data/src/10.2/sql/sql_parse.cc:1381
      #21 0x00005595dd81ac94 in do_handle_one_connection (connect=0x5595e011f120) at /data/src/10.2/sql/sql_connect.cc:1336
      #22 0x00005595dd81a9f9 in handle_one_connection (arg=0x5595e011f120) at /data/src/10.2/sql/sql_connect.cc:1241
      #23 0x00005595de044f16 in pfs_spawn_thread (arg=0x5595e0102800) at /data/src/10.2/storage/perfschema/pfs.cc:1869
      #24 0x00007f9cb2069609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #25 0x00007f9cb1c43293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      No obvious immediate problem on non-debug builds.
      Not reproducible on 10.3+, including very old 10.3.6.

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:

                Git Integration