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

Assertion `! is_set()' failed in Diagnostics_area::set_eof_status on executing ANALYZE SELECT via PS

Details

    Description

      The problem appeared on 10.1 tree with this revision

      commit d44dd54bc838e6679f451a8faf07a7f44efe2fa4
      Author: Sergei Petrunia <psergey@askmonty.org>
      Date:   Fri Oct 17 14:18:10 2014 +0400
       
          MDEV-6400: "ANALYZE SELECT ... INTO @var" doesn't set @var
          
          Make ANALYZE work for
          - ANALYZE SELECT ... INTO @var
          - ANALYZE INSERT SELECT ...;
          - ANALYZE SELECT .. INTO OUTFILE

      Test case

      prepare stmt from "analyze select * from mysql.user";
      execute stmt;

      Error log

      10.1/sql/sql_error.cc:406: void Diagnostics_area::set_eof_status(THD*): Assertion `! is_set()' failed.
      141105 14:27:33 [ERROR] mysqld got signal 6 ;

      #6  0x00007f459bd6a6f1 in *__GI___assert_fail (assertion=0x7f459ef8b687 "! is_set()", file=<optimized out>, line=406, function=0x7f459ef8c480 "void Diagnostics_area::set_eof_status(THD*)") at assert.c:81
      #7  0x00007f459e657f28 in Diagnostics_area::set_eof_status (this=0x7f45993fd100, thd=0x7f45993f8070) at 10.1/sql/sql_error.cc:406
      #8  0x00007f459e5d2da1 in my_eof (thd=0x7f45993f8070) at 10.1/sql/sql_class.h:3849
      #9  0x00007f459e641be1 in select_send::send_eof (this=0x7f4592900d60) at 10.1/sql/sql_class.cc:2697
      #10 0x00007f459e7df671 in Explain_query::send_explain (this=0x7f4592900860, thd=0x7f45993f8070) at 10.1/sql/sql_explain.cc:146
      #11 0x00007f459e688616 in execute_sqlcom_select (thd=0x7f45993f8070, all_tables=0x7f4592b2d698) at 10.1/sql/sql_parse.cc:5692
      #12 0x00007f459e67eac3 in mysql_execute_command (thd=0x7f45993f8070) at 10.1/sql/sql_parse.cc:2802
      #13 0x00007f459e6a51b0 in Prepared_statement::execute (this=0x7f4592a39470, expanded_query=0x7f459e14d550, open_cursor=false) at 10.1/sql/sql_prepare.cc:4038
      #14 0x00007f459e6a3ff9 in Prepared_statement::execute_loop (this=0x7f4592a39470, expanded_query=0x7f459e14d550, open_cursor=false, packet=0x0, packet_end=0x0) at 10.1/sql/sql_prepare.cc:3665
      #15 0x00007f459e6a2095 in mysql_sql_stmt_execute (thd=0x7f45993f8070) at 10.1/sql/sql_prepare.cc:2801
      #16 0x00007f459e67eaf4 in mysql_execute_command (thd=0x7f45993f8070) at 10.1/sql/sql_parse.cc:2813
      #17 0x00007f459e68b681 in mysql_parse (thd=0x7f45993f8070, rawbuf=0x7f45928ff088 "execute stmt", length=12, parser_state=0x7f459e14e1c0) at 10.1/sql/sql_parse.cc:6953
      #18 0x00007f459e67b741 in dispatch_command (command=COM_QUERY, thd=0x7f45993f8070, packet=0x7f4597bfa071 "", packet_length=12) at 10.1/sql/sql_parse.cc:1466
      #19 0x00007f459e67a55f in do_command (thd=0x7f45993f8070) at 10.1/sql/sql_parse.cc:1095
      #20 0x00007f459e7a7f27 in do_handle_one_connection (thd_arg=0x7f45993f8070) at 10.1/sql/sql_connect.cc:1351
      #21 0x00007f459e7a7c6c in handle_one_connection (arg=0x7f45993f8070) at 10.1/sql/sql_connect.cc:1262
      #22 0x00007f459ed39f2e in pfs_spawn_thread (arg=0x7f459b4249f0) at 10.1/storage/perfschema/pfs.cc:1860
      #23 0x00007f459dd84b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
      #24 0x00007f459be1b20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

      Stack trace from

      commit 43f185e171eecdce41e71c548ce0bc2bd6969c0f
      Author: Alexander Barkov <bar@mariadb.org>
      Date:   Mon Nov 3 21:45:06 2014 +0400

      Attachments

        Issue Links

          Activity

            Variation of the stack trace using binary protocol:

            #6  0x00007f78f71946f1 in *__GI___assert_fail (assertion=0x7f78fa3b5687 "! is_set()", file=<optimized out>, line=406, function=0x7f78fa3b6480 "void Diagnostics_area::set_eof_status(THD*)") at assert.c:81
            #7  0x00007f78f9a81f28 in Diagnostics_area::set_eof_status (this=0x7f78dd89d100, thd=0x7f78dd898070) at 10.1/sql/sql_error.cc:406
            #8  0x00007f78f99fcda1 in my_eof (thd=0x7f78dd898070) at 10.1/sql/sql_class.h:3849
            #9  0x00007f78f9accb41 in Select_fetch_protocol_binary::send_eof (this=0x7f78d9186528) at 10.1/sql/sql_prepare.cc:3093
            #10 0x00007f78f9e2bf1d in Materialized_cursor::open (this=0x7f78d916a888, join=0x0) at 10.1/sql/sql_cursor.cc:301
            #11 0x00007f78f9e2b8e1 in mysql_open_cursor (thd=0x7f78dd898070, result=0x7f78d9186528, pcursor=0x7f78d9186588) at 10.1/sql/sql_cursor.cc:164
            #12 0x00007f78f9acf0f9 in Prepared_statement::execute (this=0x7f78d9186470, expanded_query=0x7f78f94d6010, open_cursor=true) at 10.1/sql/sql_prepare.cc:4018
            #13 0x00007f78f9acdff9 in Prepared_statement::execute_loop (this=0x7f78d9186470, expanded_query=0x7f78f94d6010, open_cursor=true, packet=0x7f78dd89e07a "def\004test\001l\020dbmail_partlists\004part\004part\f?", packet_end=0x7f78dd89e07a "def\004test\001l\020dbmail_partlists\004part\004part\f?") at 10.1/sql/sql_prepare.cc:3665
            #14 0x00007f78f9acbe39 in mysqld_stmt_execute (thd=0x7f78dd898070, packet_arg=0x7f78dd89e071 "", packet_length=9) at 10.1/sql/sql_prepare.cc:2746
            #15 0x00007f78f9aa5474 in dispatch_command (command=COM_STMT_EXECUTE, thd=0x7f78dd898070, packet=0x7f78dd89e071 "", packet_length=9) at 10.1/sql/sql_parse.cc:1414
            #16 0x00007f78f9aa455f in do_command (thd=0x7f78dd898070) at 10.1/sql/sql_parse.cc:1095
            #17 0x00007f78f9bd1f27 in do_handle_one_connection (thd_arg=0x7f78dd898070) at 10.1/sql/sql_connect.cc:1351
            #18 0x00007f78f9bd1c6c in handle_one_connection (arg=0x7f78dd898070) at 10.1/sql/sql_connect.cc:1262
            #19 0x00007f78f91aeb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
            #20 0x00007f78f724520d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

            elenst Elena Stepanova added a comment - Variation of the stack trace using binary protocol: #6 0x00007f78f71946f1 in *__GI___assert_fail (assertion=0x7f78fa3b5687 "! is_set()", file=<optimized out>, line=406, function=0x7f78fa3b6480 "void Diagnostics_area::set_eof_status(THD*)") at assert.c:81 #7 0x00007f78f9a81f28 in Diagnostics_area::set_eof_status (this=0x7f78dd89d100, thd=0x7f78dd898070) at 10.1/sql/sql_error.cc:406 #8 0x00007f78f99fcda1 in my_eof (thd=0x7f78dd898070) at 10.1/sql/sql_class.h:3849 #9 0x00007f78f9accb41 in Select_fetch_protocol_binary::send_eof (this=0x7f78d9186528) at 10.1/sql/sql_prepare.cc:3093 #10 0x00007f78f9e2bf1d in Materialized_cursor::open (this=0x7f78d916a888, join=0x0) at 10.1/sql/sql_cursor.cc:301 #11 0x00007f78f9e2b8e1 in mysql_open_cursor (thd=0x7f78dd898070, result=0x7f78d9186528, pcursor=0x7f78d9186588) at 10.1/sql/sql_cursor.cc:164 #12 0x00007f78f9acf0f9 in Prepared_statement::execute (this=0x7f78d9186470, expanded_query=0x7f78f94d6010, open_cursor=true) at 10.1/sql/sql_prepare.cc:4018 #13 0x00007f78f9acdff9 in Prepared_statement::execute_loop (this=0x7f78d9186470, expanded_query=0x7f78f94d6010, open_cursor=true, packet=0x7f78dd89e07a "def\004test\001l\020dbmail_partlists\004part\004part\f?", packet_end=0x7f78dd89e07a "def\004test\001l\020dbmail_partlists\004part\004part\f?") at 10.1/sql/sql_prepare.cc:3665 #14 0x00007f78f9acbe39 in mysqld_stmt_execute (thd=0x7f78dd898070, packet_arg=0x7f78dd89e071 "", packet_length=9) at 10.1/sql/sql_prepare.cc:2746 #15 0x00007f78f9aa5474 in dispatch_command (command=COM_STMT_EXECUTE, thd=0x7f78dd898070, packet=0x7f78dd89e071 "", packet_length=9) at 10.1/sql/sql_parse.cc:1414 #16 0x00007f78f9aa455f in do_command (thd=0x7f78dd898070) at 10.1/sql/sql_parse.cc:1095 #17 0x00007f78f9bd1f27 in do_handle_one_connection (thd_arg=0x7f78dd898070) at 10.1/sql/sql_connect.cc:1351 #18 0x00007f78f9bd1c6c in handle_one_connection (arg=0x7f78dd898070) at 10.1/sql/sql_connect.cc:1262 #19 0x00007f78f91aeb50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #20 0x00007f78f724520d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

            it looks like metadata sent twice (first before optimize, second after execution)

            sanja Oleksandr Byelkin added a comment - it looks like metadata sent twice (first before optimize, second after execution)

            First it send normal select fields, then ANALYZE fields after execution (which is second result set).

            sanja Oleksandr Byelkin added a comment - First it send normal select fields, then ANALYZE fields after execution (which is second result set).

            As expected normal execution do it only once.

            sanja Oleksandr Byelkin added a comment - As expected normal execution do it only once.

            ... because select_send_analyze used as select result class...

            sanja Oleksandr Byelkin added a comment - ... because select_send_analyze used as select result class...

            select_send::is_result_interceptor() return 1 which is a problem because it return results to client

            sanja Oleksandr Byelkin added a comment - select_send::is_result_interceptor() return 1 which is a problem because it return results to client

            People

              sanja Oleksandr Byelkin
              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.