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

Server crashes in is_current_stmt_binlog_format_row

Details

    Description

      https://travis-ci.org/elenst/travis-tests/jobs/457440238

      Note: it might be related to MDEV-14472, but no assertion failure here, just SIGSEGV.

      10.3 02b70702d9df

      181120 14:29:37 [ERROR] mysqld got signal 11 ;
      This could be because you hit a bug. It is also possible that this binary
      or one of the libraries it was linked against is corrupt, improperly built,
      or misconfigured. This error can also be caused by malfunctioning hardware.
      To report this bug, see https://mariadb.com/kb/en/reporting-bugs
      We will try our best to scrape up some info that will hopefully help
      diagnose the problem, but since we have already crashed, 
      something is definitely wrong and this may fail.
      Server version: 10.3.12-MariaDB-debug-log
      key_buffer_size=134217728
      read_buffer_size=131072
      max_used_connections=8
      max_threads=153
      thread_count=14
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467474 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
      Thread pointer: 0x5558faf45650
      Attempting backtrace. You can use the following information to find out
      where mysqld died. If you see no messages after this, something went
      terribly wrong...
      stack_bottom = 0x7f9a38d57e80 thread_stack 0x49000
      /home/travis/server/bin/mysqld(my_print_stacktrace+0x40)[0x5558f8046d3a]
      /home/travis/server/bin/mysqld(handle_fatal_signal+0x3dc)[0x5558f789ebfb]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f9a599ac330]
      sql/sql_class.h:2485(THD::is_current_stmt_binlog_format_row() const)[0x5558f74d4b14]
      sql/sql_class.cc:4795(thd_rpl_stmt_based)[0x5558f7544826]
      que/que0que.cc:688(que_thr_stop(que_thr_t*))[0x5558f7bb66a6]
      que/que0que.cc:739(que_thr_dec_refer_count)[0x5558f7bb680c]
      que/que0que.cc:1119(que_run_threads_low)[0x5558f7bb7635]
      que/que0que.cc:1146(que_run_threads(que_thr_t*))[0x5558f7bb7767]
      que/que0que.cc:1223(que_eval_sql(pars_info_t*, char const*, unsigned long, trx_t*))[0x5558f7bb7a0e]
      dict/dict0stats.cc:306(dict_stats_exec_sql)[0x5558f7dbf33f]
      dict/dict0stats.cc:3685(dict_stats_rename_table_in_index_stats)[0x5558f7dc6a66]
      dict/dict0stats.cc:3792(dict_stats_rename_table(char const*, char const*, char*, unsigned long))[0x5558f7dc6eb4]
      handler/ha_innodb.cc:13264(ha_innobase::rename_table(char const*, char const*))[0x5558f7ac2e68]
      sql/handler.cc:4547(handler::ha_rename_table(char const*, char const*))[0x5558f78ab391]
      sql/sql_table.cc:5459(mysql_rename_table(handlerton*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, unsigned int))[0x5558f7675a74]
      sql/sql_rename.cc:294(do_rename)[0x5558f75d040b]
      sql/sql_rename.cc:377(rename_tables)[0x5558f75d0686]
      sql/sql_rename.cc:154(mysql_rename_tables(THD*, TABLE_LIST*, bool))[0x5558f75cff0d]
      sql/sql_parse.cc:4447(mysql_execute_command(THD*))[0x5558f75a42d0]
      sql/sql_parse.cc:8090(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x5558f75afe6e]
      sql/sql_parse.cc:1852(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x5558f759d076]
      sql/sql_parse.cc:1395(do_command(THD*))[0x5558f759baa7]
      sql/sql_connect.cc:1402(do_handle_one_connection(CONNECT*))[0x5558f7704552]
      sql/sql_connect.cc:1309(handle_one_connection)[0x5558f77042d6]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f9a599a4184]
      /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f9a58eb0ffd]
      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x5558faf58188): RENAME TABLE seq6 TO seq4 /* QNO 24898 CON_ID 17 */
      Connection ID (thread ID): 17
      Status: NOT_KILLED
      Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on
      

      elenst-jira-refs 61b46fa51f8

      perl ./runall-new.pl --basedir=/home/travis/server --vardir=/home/travis/logs/vardir --duration=350 --threads=6 --seed=1542723917 --reporters=Backtrace,ErrorLog,Deadlock --validators=TransformerNoComparator --views --redefine=conf/mariadb/alter_table.yy --redefine=conf/mariadb/instant_add.yy --redefine=conf/mariadb/sp.yy --redefine=conf/mariadb/bulk_insert.yy --redefine=conf/mariadb/versioning.yy --redefine=conf/mariadb/sequences.yy --mysqld=--log_output=FILE --mysqld=--max-statement-time=30 --mysqld=--lock-wait-timeout=10 --mysqld=--loose-innodb-lock-wait-timeout=5 --mysqld=--loose-debug_assert_on_not_freed_memory=0 --mysqld=--default-storage-engine=Aria --grammar=conf/partitioning/partitions.yy --skip-gendata --gendata-advanced --vcols --transformers=ExecuteAsIntersect,ExecuteAsExcept,ExecuteAsCTE,ExecuteAsExecuteImmediate,ExecuteAsDeleteReturning,ExecuteAsInsertSelect,ExecuteAsUnion,ExecuteAsUpdateDelete,ExecuteAsView,ExecuteAsPreparedTwice
      

      Not reproducible right away.

      Attachments

        Issue Links

          Activity

            elenst Elena Stepanova added a comment - New occurrence on 10.4: https://travis-ci.org/elenst/travis-tests/jobs/467607663

            The crash was introduced by MDEV-17073.

            Internal transactions may not have trx->mysql_thd. But at the same time, trx->duplicates should only hold if REPLACE or INSERT…ON DUPLICATE KEY UPDATE was executed from SQL.

            The flag trx->duplicates feels misplaced. A more appropriate place for it would be row_prebuilt_t or similar.

            I will prevent the crashes by checking for trx->mysql_thd==NULL before the calls, but this will not fix the issue with the flag.

            marko Marko Mäkelä added a comment - The crash was introduced by MDEV-17073 . Internal transactions may not have trx->mysql_thd . But at the same time, trx->duplicates should only hold if REPLACE or INSERT…ON DUPLICATE KEY UPDATE was executed from SQL. The flag trx->duplicates feels misplaced. A more appropriate place for it would be row_prebuilt_t or similar. I will prevent the crashes by checking for trx->mysql_thd==NULL before the calls, but this will not fix the issue with the flag.

            In MySQL 8.0.18, the flag trx->duplicates was finally moved to row_prebuilt_t. I think that we must apply that fix to MariaDB Server.

            marko Marko Mäkelä added a comment - In MySQL 8.0.18, the flag trx->duplicates was finally moved to row_prebuilt_t . I think that we must apply that fix to MariaDB Server.

            MDEV-17814-10.2-WIP.patch is a backport of the change from MySQL 8.0 to MariaDB Server 10.2.

            I am not entirely satisfied with the change to the function lock_rec_inherit_to_gap(). In MySQL 8.0, something was changed earlier, and I am not convinced that the change is actually correct. My patch discards the problematic condition.

            It seems that we must first fix MDEV-20605 and try to ensure that we can safely delete records without having to insert any gap locks for other transactions during rollback, purge, or any b-tree page splits or merges.

            marko Marko Mäkelä added a comment - MDEV-17814-10.2-WIP.patch is a backport of the change from MySQL 8.0 to MariaDB Server 10.2. I am not entirely satisfied with the change to the function lock_rec_inherit_to_gap() . In MySQL 8.0, something was changed earlier , and I am not convinced that the change is actually correct. My patch discards the problematic condition. It seems that we must first fix MDEV-20605 and try to ensure that we can safely delete records without having to insert any gap locks for other transactions during rollback, purge, or any b-tree page splits or merges.

            The logic around InnoDB persistent statistics as well as DDL was refactored in MariaDB Server 10.6. First it could make sense to check if the problem is reproducible in 10.6 at all. In older releases we also have other bugs in this area that are not feasible, such as MDEV-15020.

            marko Marko Mäkelä added a comment - The logic around InnoDB persistent statistics as well as DDL was refactored in MariaDB Server 10.6. First it could make sense to check if the problem is reproducible in 10.6 at all. In older releases we also have other bugs in this area that are not feasible, such as MDEV-15020 .

            vlad.lesin has filed MDEV-32951 for the suggestion that the field trx_t::duplicates be moved to the cursor (ha_innobase::m_prebuilt or similar).

            marko Marko Mäkelä added a comment - vlad.lesin has filed MDEV-32951 for the suggestion that the field trx_t::duplicates be moved to the cursor ( ha_innobase::m_prebuilt or similar).

            People

              vlad.lesin Vladislav Lesin
              elenst Elena Stepanova
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.