Details
- 
    
Bug
 - 
    Status: Closed (View Workflow)
 - 
    
Major
 - 
    Resolution: Incomplete
 - 
    10.6.17
 - 
    None
 
- 
        Not for Release Notes
 
Description
MariaDB 10.6.17 hits the following assertion failure:
					...
			 | 
		
					2024-03-15 14:39:06 0x7fa9fc05e700 InnoDB: Assertion failure in file /home/buildbot/buildbot/build/storage/innobase/btr/btr0cur.cc line 4272
			 | 
		
					InnoDB: Failing assertion: err == DB_SUCCESS
			 | 
		
					InnoDB: We intentionally generate a memory trap.
			 | 
		
					InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
			 | 
		
					InnoDB: If you get repeated assertion failures or crashes, even
			 | 
		
					InnoDB: immediately after the mariadbd startup, there may be
			 | 
		
					InnoDB: corruption in the InnoDB tablespace. Please refer to
			 | 
		
					InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
			 | 
		
					InnoDB: about forcing recovery.
			 | 
		
					240315 14:39:06 [ERROR] mysqld got signal 6 ;
			 | 
		
					Sorry, we probably made a mistake, and this is a bug.
			 | 
		
| 
					 | 
		
					Your assistance in bug reporting will enable us to fix this for the next release.
			 | 
		
					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.6.17-MariaDB-log source revision: 15c75ad083a55e198ae78324f22970694b72f22b
			 | 
		
					key_buffer_size=134217728
			 | 
		
					read_buffer_size=131072
			 | 
		
					max_used_connections=0
			 | 
		
					max_threads=602
			 | 
		
					thread_count=9
			 | 
		
					It is possible that mysqld could use up to
			 | 
		
					key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1456870 K bytes of memory
			 | 
		
					Hope that's ok; if not, decrease some variables in the equation.
			 | 
		
| 
					 | 
		
					Thread pointer: 0x7f9c60000c58
			 | 
		
					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 = 0x7fa9fc05dd40 thread_stack 0x49000
			 | 
		
					mysys/stacktrace.c:216(my_print_stacktrace)[0x557db4e5354e]
			 | 
		
					sql/signal_handler.cc:238(handle_fatal_signal)[0x557db4824be7]
			 | 
		
					2024-03-15 14:39:07 0 [Note] WSREP: (bda9dd93-acb5, 'tcp://0.0.0.0:4567') turning message relay requesting off
			 | 
		
					/lib/x86_64-linux-gnu/libpthread.so.0(+0x13140)[0x7fa9fd44b140]
			 | 
		
					/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7fa9fcf83ce1]
			 | 
		
					/lib/x86_64-linux-gnu/libc.so.6(abort+0x123)[0x7fa9fcf6d537]
			 | 
		
					/opt/mysql/gc_adios_prod_3306/bin/mysqld(+0x6c4189)[0x557db44c4189]
			 | 
		
					btr/btr0cur.cc:4159(btr_cur_pessimistic_update(unsigned long, btr_cur_t*, unsigned short**, mem_block_info_t**, mem_block_info_t*, big_rec_t**, upd_t*, unsigned long, que_thr_t*, unsigned long, mtr_t*))[0x557db4ca6869]
			 | 
		
					row/row0upd.cc:2448(row_upd_clust_rec(unsigned long, upd_node_t*, dict_index_t*, unsigned short*, mem_block_info_t**, que_thr_t*, mtr_t*))[0x557db4c2e4f9]
			 | 
		
					row/row0upd.cc:2679(row_upd_clust_step(upd_node_t*, que_thr_t*))[0x557db4c3156a]
			 | 
		
					row/row0upd.cc:2781(row_upd_step(que_thr_t*))[0x557db4c32f60]
			 | 
		
					row/row0mysql.cc:1690(row_update_for_mysql(row_prebuilt_t*))[0x557db4c0dd31]
			 | 
		
					handler/ha_innodb.cc:8687(ha_innobase::update_row(unsigned char const*, unsigned char const*))[0x557db4b479e3]
			 | 
		
					sql/handler.cc:7719(handler::ha_update_row(unsigned char const*, unsigned char const*))[0x557db48342e2]
			 | 
		
					sql/log_event_server.cc:8569(Update_rows_log_event::do_exec_row(rpl_group_info*))[0x557db494bd6b]
			 | 
		
					sql/log_event_server.cc:5801(Rows_log_event::do_apply_event(rpl_group_info*))[0x557db493fe1d]
			 | 
		
					sql/log_event.h:1510(Log_event::apply_event(rpl_group_info*))[0x557db4b161d7]
			 | 
		
					sql/wsrep_high_priority_service.cc:129(apply_events(THD*, Relay_log_info*, wsrep::const_buffer const&, wsrep::mutable_buffer&))[0x557db4afda70]
			 | 
		
					sql/wsrep_high_priority_service.cc:598(Wsrep_applier_service::apply_write_set(wsrep::ws_meta const&, wsrep::const_buffer const&, wsrep::mutable_buffer&))[0x557db4afdb63]
			 | 
		
					src/server_state.cpp:333(apply_write_set(wsrep::server_state&, wsrep::high_priority_service&, wsrep::ws_handle const&, wsrep::ws_meta const&, wsrep::const_buffer const&))[0x557db4fb4a1f]
			 | 
		
					src/server_state.cpp:1131(wsrep::server_state::on_apply(wsrep::high_priority_service&, wsrep::ws_handle const&, wsrep::ws_meta const&, wsrep::const_buffer const&))[0x557db4fb5745]
			 | 
		
					src/wsrep_provider_v26.cpp:507((anonymous namespace)::apply_cb(void*, wsrep_ws_handle const*, unsigned int, wsrep_buf const*, wsrep_trx_meta const*, bool*))[0x557db4fc52a8]
			 | 
		
					src/trx_handle.cpp:396(galera::TrxHandleSlave::apply(void*, wsrep_cb_status (*)(void*, wsrep_ws_handle const*, unsigned int, wsrep_buf const*, wsrep_trx_meta const*, bool*), wsrep_trx_meta const&, bool&))[0x7fa9fc547d31]
			 | 
		
					src/replicator_smm.cpp:512(galera::ReplicatorSMM::apply_trx(void*, galera::TrxHandleSlave&))[0x7fa9fc555e4f]
			 | 
		
					src/replicator_str.cpp:1157(galera::ReplicatorSMM::process_IST_writeset(void*, boost::shared_ptr<galera::TrxHandleSlave> const&))[0x7fa9fc5687d6]
			 | 
		
					src/trx_handle.hpp:624(galera::TrxHandleSlave::exit_loop() const)[0x7fa9fc56967a]
			 | 
		
					src/replicator_smm.cpp:404(galera::ReplicatorSMM::async_recv(void*))[0x7fa9fc55ae7b]
			 | 
		
					src/wsrep_provider.cpp:266(galera_recv)[0x7fa9fc5365ba]
			 | 
		
					src/wsrep_provider_v26.cpp:859(wsrep::wsrep_provider_v26::run_applier(wsrep::high_priority_service*))[0x557db4fc59de]
			 | 
		
					sql/wsrep_thd.cc:59(wsrep_replication_process(THD*, void*))[0x557db4b17fc2]
			 | 
		
					sql/wsrep_mysqld.cc:3695(start_wsrep_THD(void*))[0x557db4b08e5d]
			 | 
		
					perfschema/pfs.cc:2204(pfs_spawn_thread)[0x557db4a9910c]
			 | 
		
					/lib/x86_64-linux-gnu/libpthread.so.0(+0x7ea7)[0x7fa9fd43fea7]
			 | 
		
					/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fa9fd046a2f]
			 | 
		
| 
					 | 
		
					Trying to get some variables.
			 | 
		
					Some pointers may be invalid and cause the dump to abort.
			 | 
		
					Query (0x7fa98c97ae3b): update T set C1='...' where _ID=2810341728
			 | 
		
| 
					 | 
		
					Connection ID (thread ID): 6
			 | 
		
					Status: NOT_KILLED
			 | 
		
					...
			 | 
		
while applying Galera write set. I can not find any known bug with similar stack trace that applies to 10.6.17, so decided to report a new one.
The datadir content is gone, as the node was added back to the customer via SST, so no core dump for further study is available.
Attachments
Issue Links
- relates to
 - 
                    
MDEV-31767 InnoDB tables are being flagged as corrupted on an I/O bound server
-         
 - Closed
 
 -         
 - 
                    
MDEV-33588 buf::Block_hint is a performance hog
-         
 - Closed
 
 -