[MDEV-15155] [Draft] Assertion failed: m_state == 3 || m_state == 0 || m_state == 1, file d:\qa-win-debug\build\storage\innobase\include\read0types.h, line 156 Created: 2018-01-31  Updated: 2020-05-23  Resolved: 2018-02-23

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.3.5
Fix Version/s: 10.3.5

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Elena Stepanova
Resolution: Fixed Votes: 0
Labels: None

Attachments: HTML File dump_contents    
Issue Links:
Problem/Incident
is caused by MDEV-15104 Remove trx_sys_t::rw_trx_ids and trx_... Closed
Epic Link: InnoDB trx_sys improvements

 Description   

http://buildbot.askmonty.org/buildbot/builders/qa-win-debug/builds/1067/steps/crash_tests/logs/stdio

10.3 1951e7f05ae7b6069eeffdfe8ab304fa3a18a85a

Assertion failed: m_state == 3 || m_state == 0 || m_state == 1, file d:\qa-win-debug\build\storage\innobase\include\read0types.h, line 156
180201  1:16:47 [ERROR] mysqld got exception 0x80000003 ;
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.5-MariaDB-debug-log
key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=7
max_threads=65537
thread_count=12
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4320 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x0
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...
mysqld.exe!my_sigabrt_handler()[my_thr_init.c:486]
mysqld.exe!raise()[signal.cpp:516]
mysqld.exe!abort()[abort.cpp:71]
mysqld.exe!common_assert_to_stderr<wchar_t>()[assert.cpp:149]
mysqld.exe!_wassert()[assert.cpp:404]
mysqld.exe!ReadView::is_open()[read0types.h:154]
mysqld.exe!lock_trx_print_wait_and_mvcc_state()[lock0lock.cc:5348]
mysqld.exe!lock_print_info_all_transactions_callback()[lock0lock.cc:5413]
mysqld.exe!rw_trx_hash_t::eliminate_duplicates()[trx0sys.h:532]
mysqld.exe!rw_trx_hash_t::debug_iterator()[trx0sys.h:562]
mysqld.exe!l_find()[lf_hash.c:126]
mysqld.exe!lf_hash_iterate()[lf_hash.c:518]
mysqld.exe!rw_trx_hash_t::iterate()[trx0sys.h:764]
mysqld.exe!rw_trx_hash_t::iterate_no_dups()[trx0sys.h:787]
mysqld.exe!rw_trx_hash_t::iterate_no_dups()[trx0sys.h:795]
mysqld.exe!lock_print_info_all_transactions()[lock0lock.cc:5454]
mysqld.exe!srv_printf_innodb_monitor()[srv0srv.cc:1282]
mysqld.exe!srv_monitor_thread()[srv0srv.cc:1747]
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

E:\buildbot\rqg/runall.pl --no-mask --seed=1517436829 --threads=5 --duration=400 --queries=100M --reporters=QueryTimeout,Backtrace,ErrorLog,Deadlock,Shutdown --redefine=conf/mariadb/redefine_random_keys.yy --redefine=conf/mariadb/redefine_set_session_vars.yy --validators=TransformerNoComparator --transformers=ConvertSubqueriesToViews,DisableOptimizations,EnableOptimizations,ExecuteAsCTE,ExecuteAsInsertSelect,ExecuteAsPreparedOnce,ExecuteAsSelectItem,ExecuteAsUnion,ExecuteAsUpdateDelete,ExecuteAsView,NullIf,OrderBy,StraightJoin,ExecuteAsExecuteImmediate --store-binaries --grammar=conf/mariadb/optimizer.yy --engine=InnoDB --mtr-build-thread=150 --basedir1=D:\qa-win-debug\build --vardir1=E:\buildbot\vardirs\qa-win-debug\10.3-1067\optim-crash-tests/current1_1



 Comments   
Comment by Marko Mäkelä [ 2018-02-21 ]

svoj refactored this code in MDEV-15104. Based on the filing date, this could possibly be a duplicate of the regression that was fixed in MDEV-15246.

Comment by Sergey Vojtovich [ 2018-02-21 ]

It is different bug. ReadView::is_open() was intended to be called by view owner thread. But here it is called by remote thread.
I overlooked this, because original code was prone to race conditions as well (and there's even a comment about it).

This should definitely be fixed, but this particular assertion failure is not indication of regression. That is release builds should handle this code just fine.

Comment by Sergey Vojtovich [ 2018-02-22 ]

Should be fixed in https://github.com/MariaDB/server/commit/988ec800edb3dd9238b6f3948157d21bdb0c083b

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