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

main.errors fails in buildbot and outside with wrong errno 1290

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.1(EOL)
    • 10.1.26
    • Tests
    • None

    Description

      http://buildbot.askmonty.org/buildbot/builders/kvm-fulltest2/builds/8564/steps/test_3/logs/stdio

      Also reproducible locally with ps-protocol.

      $ perl ./mtr main.errors --ps-protocol
       
      main.errors                              [ fail ]
              Test ended at 2017-06-27 00:59:55
       
      CURRENT_TEST: main.errors
      mysqltest: At line 208: query 'select * from seq_1_to_1000' failed with wrong errno 1290: 'The MariaDB server is running with the --max-thread-mem-used=8192 option so it cannot execute this statement', instead of 1939...
       
      The result from queries just before the failure was:
      < snip >
      REPLACE t2(b) SELECT '' AS b FROM t1 GROUP BY VALUES(b);
      ERROR 42S22: Unknown column '' in 'VALUES() function'
      UPDATE t2 SET a=(SELECT '' AS b FROM t1 GROUP BY VALUES(b));
      ERROR 42S22: Unknown column '' in 'VALUES() function'
      INSERT INTO t2 VALUES (1,0) ON DUPLICATE KEY UPDATE
      b=(SELECT '' AS b FROM t1 GROUP BY VALUES(b));
      ERROR 42S22: Unknown column '' in 'VALUES() function'
      INSERT INTO t2(a,b) VALUES (1,0) ON DUPLICATE KEY UPDATE
      b=(SELECT VALUES(a)+2 FROM t1);
      DROP TABLE t1, t2;
      #
      # MDEV-492: incorrect error check before sending OK in mysql_update 
      #
      CREATE TABLE t1 (a CHAR(3), b BLOB);
      UPDATE t1 SET a = 'new'
      WHERE COLUMN_CREATE( 1, 'v', 1, 'w' ) IS NULL;
      ERROR 22007: Illegal value used as argument of dynamic column function
      drop table t1;
      set max_session_mem_used = 8192;
      select * from seq_1_to_1000;
      

      The failure appeared in 10.1 with this revision:

      commit b6ce68f450ce06db989febf4dc3e2428d6400dd7
      Author: Sergei Golubchik <serg@mariadb.org>
      Date:   Thu Jun 15 20:16:18 2017 +0200
       
          MDEV-13012 Assertion `share->error' failed in discover_handlerton upon executing statement with max_session_mem_used = 8192
          
          and
          MDEV-13011 Server crashes in THD::handle_condition or Assertion `! is_set() || m_can_overwrite_status' fails upon attempt to connect with max_session_mem_used = 8192
          
          errors when a connection is killed in the
          * TABLE_SHARE::init_from_sql_statement_string()
          * THD::init()
          
          also, safety-wise, don't check max_mem_used on free() and when some error
          was already issued.
      

      Attachments

        Issue Links

          Activity

            elenst Elena Stepanova created issue -
            serg Sergei Golubchik made changes -
            Field Original Value New Value
            Fix Version/s 10.1.25 [ 22542 ]
            Fix Version/s 10.1 [ 16100 ]
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Closed [ 6 ]

            Reopening issue because we get in some cases the wrong error code when using max_session_mem_used.

            When compiling with valgrind, this always happens.

            monty Michael Widenius added a comment - Reopening issue because we get in some cases the wrong error code when using max_session_mem_used. When compiling with valgrind, this always happens.
            monty Michael Widenius made changes -
            Assignee Sergei Golubchik [ serg ] Michael Widenius [ monty ]
            Resolution Fixed [ 1 ]
            Status Closed [ 6 ] Stalled [ 10000 ]

            Here is the commit message for the fix to this problem:

            MDEV-13179 main.errors fails with wrong errno

            The problem was that the introduction of max-thread-mem-used can cause
            an allocation error very early, even before mysql_parse() is called.
            As mysql_parse() calls thd->reset_for_next_command(), which called
            clear_error(), the error number was lost.

            Fixed by adding an option to have unique messages for each KILL
            signal and change max-thread-mem-used to use this new feature.
            This removes a lot of problems with the original approach, where
            one could get errors signaled silenty almost any time.

            Fixed by moving clear_error() from reset_for_next_command() to
            do_command(), before any memory allocation for the thread.

            Related changes:

            • reset_for_next_command() now have an optional parameter if we should
              call clear_error() or not. By default it's called, but not anymore from
              dispatch_command() which was the original problem.
            • Added optional paramater to clear_error() to force calling of
              reset_diagnostics_area(). Before clear_error() only called
              reset_diagnostics_area() if there was no error, so we normally
              called reset_diagnostics_area() twice.
            • This change removed several duplicated calls to clear_error()
              when starting a query.
            • Reset max_mem_used on COM_QUIT, to protect against kill during
              quit.
            • Use fatal_error() instead of setting is_fatal_error (cleanup)
            • Set fatal_error if max_thead_mem_used is signaled.
              (Same logic we use for other places where we are out of resources)
            monty Michael Widenius added a comment - Here is the commit message for the fix to this problem: MDEV-13179 main.errors fails with wrong errno The problem was that the introduction of max-thread-mem-used can cause an allocation error very early, even before mysql_parse() is called. As mysql_parse() calls thd->reset_for_next_command(), which called clear_error(), the error number was lost. Fixed by adding an option to have unique messages for each KILL signal and change max-thread-mem-used to use this new feature. This removes a lot of problems with the original approach, where one could get errors signaled silenty almost any time. Fixed by moving clear_error() from reset_for_next_command() to do_command(), before any memory allocation for the thread. Related changes: reset_for_next_command() now have an optional parameter if we should call clear_error() or not. By default it's called, but not anymore from dispatch_command() which was the original problem. Added optional paramater to clear_error() to force calling of reset_diagnostics_area(). Before clear_error() only called reset_diagnostics_area() if there was no error, so we normally called reset_diagnostics_area() twice. This change removed several duplicated calls to clear_error() when starting a query. Reset max_mem_used on COM_QUIT, to protect against kill during quit. Use fatal_error() instead of setting is_fatal_error (cleanup) Set fatal_error if max_thead_mem_used is signaled. (Same logic we use for other places where we are out of resources)
            monty Michael Widenius made changes -
            Fix Version/s 10.1.26 [ 22553 ]
            Fix Version/s 10.1.25 [ 22542 ]
            Resolution Fixed [ 1 ]
            Status Stalled [ 10000 ] Closed [ 6 ]
            Roel Roel Van de Paar made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 81382 ] MariaDB v4 [ 152386 ]

            People

              monty Michael Widenius
              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.