[MDEV-17814] Server crashes in is_current_stmt_binlog_format_row Created: 2018-11-23  Updated: 2024-01-30

Status: Open
Project: MariaDB Server
Component/s: Server, Storage Engine - InnoDB
Affects Version/s: 10.3.11, 10.4.0, 10.2.19
Fix Version/s: 10.4

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Vladislav Lesin
Resolution: Unresolved Votes: 1
Labels: upstream-fixed

Attachments: File MDEV-17814-10.2-WIP.patch    
Issue Links:
Blocks
is blocked by MDEV-20605 Awaken transaction can miss inserted ... Closed
Duplicate
is duplicated by MDEV-32951 Move duplicates from trx_t to cursor In Progress
Relates
relates to MDEV-24534 Assertion `!is_current_stmt_binlog_fo... Open
relates to MDEV-28709 unexpected X lock on Supremum in READ... Closed
relates to MDEV-17073 INSERT…ON DUPLICATE KEY UPDATE became... Closed

 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.



 Comments   
Comment by Elena Stepanova [ 2018-12-13 ]

New occurrence on 10.4: https://travis-ci.org/elenst/travis-tests/jobs/467607663

Comment by Marko Mäkelä [ 2018-12-14 ]

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.

Comment by Marko Mäkelä [ 2019-10-17 ]

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.

Comment by Marko Mäkelä [ 2019-10-17 ]

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.

Comment by Marko Mäkelä [ 2024-01-12 ]

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.

Comment by Marko Mäkelä [ 2024-01-12 ]

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).

Generated at Thu Feb 08 08:39:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.