Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Incomplete
-
10.4.13, 10.4.14
Description
Server crashes repeatedly with stack trace like this:
020-07-16 9:27:03 0 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
|
Version: '10.4.13-MariaDB-log' socket: '/tmp/mysql.sock' port: 33306 MariaDB Server
|
200716 9:27:56 [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.4.13-MariaDB-log
|
key_buffer_size=33554432
|
read_buffer_size=1048576
|
max_used_connections=74
|
max_threads=2010
|
thread_count=80
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10348902 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x7f28283308b8
|
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 = 0x7f28aafb1de0 thread_stack 0x49000
|
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x2e)[0x55af7c963e2e]
|
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x30f)[0x55af7c374b3f]
|
sigaction.c:0(__restore_rt)[0x7f2d914245e0]
|
/usr/local/mysql/bin/mysqld(+0xbb8f85)[0x55af7c603f85]
|
/usr/local/mysql/bin/mysqld(+0xad8bb8)[0x55af7c523bb8]
|
row/row0sel.cc:4777(row_search_mvcc(unsigned char*, page_cur_mode_t, row_prebuilt_t*, unsigned long, unsigned long))[0x55af7c3798f4]
|
handler/ha_innodb.cc:9279(ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function))[0x55af7c1b3cb7]
|
sql/handler.cc:2896(handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function))[0x55af7c1a58b9]
|
sql/sql_select.cc:21124(join_read_always_key(st_join_table*))[0x55af7c1c8123]
|
/usr/local/mysql/bin/mysqld(_ZN4JOIN4execEv+0x33)[0x55af7c1c8353]
|
/usr/local/mysql/bin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x186)[0x55af7c1c65b6]
|
/usr/local/mysql/bin/mysqld(+0x6e5637)[0x55af7c130637]
|
/usr/local/mysql/bin/mysqld(_Z27mysql_handle_single_derivedP3LEXP10TABLE_LISTj+0x104)[0x55af7c1301d4]
|
sql/sql_derived.cc:1200(mysql_derived_fill(THD*, LEX*, TABLE_LIST*))[0x55af7c1a5649]
|
/usr/local/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x178)[0x55af7c1a5888]
|
/usr/local/mysql/bin/mysqld(+0x74d07c)[0x55af7c19807c]
|
/usr/local/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x1be)[0x55af7c1a58ce]
|
sql_select.cc:0(evaluate_join_record(JOIN*, st_join_table*, int))[0x55af7c1c8123]
|
/usr/local/mysql/bin/mysqld(_ZN4JOIN4execEv+0x33)[0x55af7c1c8353]
|
/usr/local/mysql/bin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x186)[0x55af7c1c65b6]
|
/usr/local/mysql/bin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x1c7)[0x55af7c1c7117]
|
/usr/local/mysql/bin/mysqld(+0x6167d7)[0x55af7c0617d7]
|
/usr/local/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x3a6a)[0x55af7c16d91a]
|
sql/sql_parse.cc:6360(execute_sqlcom_select(THD*, TABLE_LIST*))[0x55af7c172f7c]
|
/usr/local/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x1d9e)[0x55af7c1754ee]
|
/usr/local/mysql/bin/mysqld(_Z10do_commandP3THD+0x109)[0x55af7c176d79]
|
/usr/local/mysql/bin/mysqld(_Z11tp_callbackP13TP_connection+0x1d8)[0x55af7c347068]
|
/usr/local/mysql/bin/mysqld(+0xab4cc0)[0x55af7c4ffcc0]
|
sql/threadpool_common.cc:365(tp_callback(TP_connection*))[0x55af7c88fdcd]
|
pthread_create.c:0(start_thread)[0x7f2d9141cde5]
|
/lib64/libc.so.6(clone+0x6d)[0x7f2d9027af1d]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7f2828075ad0): SELECT ...
|
while executing complex enough SELECT involving the secondary index previously reported as problematic:
2020-07-16 9:26:30 165327 [ERROR] InnoDB: Clustered record for sec rec not found index `T_IDX02` of table `db`.`T`
|
InnoDB: sec index record PHYSICAL RECORD: n_fields 1; compact format; info bits 64
|
...
|
2020-07-16 09:26:30 0x7f70c44e6700 InnoDB: Assertion failure in file /home/buildbot/buildbot/build/storage/innobase/rem/rem0rec.cc line 1982
|
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 mysqld 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.
|
200716 9:26:30 [ERROR] mysqld got signal 6 ;
|
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.4.13-MariaDB-log
|
key_buffer_size=33554432
|
read_buffer_size=1048576
|
max_used_connections=235
|
max_threads=2010
|
thread_count=151
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10348902 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x7f6fd261a508
|
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 = 0x7f70c44e5de0 thread_stack 0x49000
|
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x2e)[0x55d0a511ee2e]
|
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x30f)[0x55d0a4b2fb3f]
|
/lib64/libpthread.so.0(+0xf5e0)[0x7f759cd8e5e0]
|
/lib64/libc.so.6(gsignal+0x37)[0x7f759bb1d277]
|
/lib64/libc.so.6(abort+0x148)[0x7f759bb1e968]
|
/usr/local/mysql/bin/mysqld(+0x629e48)[0x55d0a482fe48]
|
/usr/local/mysql/bin/mysqld(+0xb72683)[0x55d0a4d78683]
|
/usr/local/mysql/bin/mysqld(+0xc43ddf)[0x55d0a4e49ddf]
|
/usr/local/mysql/bin/mysqld(+0xbb9c00)[0x55d0a4dbfc00]
|
/usr/local/mysql/bin/mysqld(+0xad8bb8)[0x55d0a4cdebb8]
|
/usr/local/mysql/bin/mysqld(_ZN7handler17ha_index_read_mapEPhPKhm16ha_rkey_function+0x94)[0x55d0a4b348f4]
|
/usr/local/mysql/bin/mysqld(+0x768cb7)[0x55d0a496ecb7]
|
/usr/local/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x1a9)[0x55d0a49608b9]
|
/usr/local/mysql/bin/mysqld(_ZN4JOIN10exec_innerEv+0xc73)[0x55d0a4983123]
|
/usr/local/mysql/bin/mysqld(_ZN4JOIN4execEv+0x33)[0x55d0a4983353]
|
/usr/local/mysql/bin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x186)[0x55d0a49815b6]
|
/usr/local/mysql/bin/mysqld(+0x6e5637)[0x55d0a48eb637]
|
/usr/local/mysql/bin/mysqld(_Z27mysql_handle_single_derivedP3LEXP10TABLE_LISTj+0x104)[0x55d0a48eb1d4]
|
/usr/local/mysql/bin/mysqld(_ZN13st_join_table12preread_initEv+0x79)[0x55d0a4960649]
|
/usr/local/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x178)[0x55d0a4960888]
|
/usr/local/mysql/bin/mysqld(_ZN4JOIN10exec_innerEv+0xc73)[0x55d0a4983123]
|
/usr/local/mysql/bin/mysqld(_ZN4JOIN4execEv+0x33)[0x55d0a4983353]
|
/usr/local/mysql/bin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x186)[0x55d0a49815b6]
|
/usr/local/mysql/bin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x1c7)[0x55d0a4982117]
|
/usr/local/mysql/bin/mysqld(+0x6167d7)[0x55d0a481c7d7]
|
/usr/local/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x3a6a)[0x55d0a492891a]
|
/usr/local/mysql/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x33c)[0x55d0a492df7c]
|
/usr/local/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x1d9e)[0x55d0a49304ee]
|
/usr/local/mysql/bin/mysqld(_Z10do_commandP3THD+0x109)[0x55d0a4931d79]
|
/usr/local/mysql/bin/mysqld(_Z11tp_callbackP13TP_connection+0x1d8)[0x55d0a4b02068]
|
/usr/local/mysql/bin/mysqld(+0xab4cc0)[0x55d0a4cbacc0]
|
/usr/local/mysql/bin/mysqld(+0xe44dcd)[0x55d0a504adcd]
|
/lib64/libpthread.so.0(+0x7de5)[0x7f759cd86de5]
|
/lib64/libc.so.6(clone+0x6d)[0x7f759bbe4f1d]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7f70720c3200): SELECT ...
|
After dropping and recreating the index crashes stopped. The instance had never been restored from mariabackup. There are no virtual columns involved.
Attachments
Issue Links
- is blocked by
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
The simple CTE test case in MDEV-23723 looks like something else. I do not think that any InnoDB corruption should be involved in that case.
valerii, I think that any secondary index page can be corrupted due to MDEV-24449. I think that that bug (which was only recently fixed, and is present in all earlier InnoDB releases) can also cause arbitrary pages in the system tablespace to be corrupted.
Does this still occur after upgrading to 10.4.18 or 10.5?
looks similar to MDEV-25442 (MDEV-23723), the query there is causing crash or corruption, like:
2021-04-19 10:57:22 5 [ERROR] InnoDB: Clustered record for sec rec not found index `idx_auction_lots_05` of table `test`.`auction_lots_test`
|
InnoDB: sec index record PHYSICAL RECORD: n_fields 5; compact format; info bits 0
|
0: len 8; hex 8000000000018c73; asc s;;
|
1: len 30; hex 8000000000dca0c400000000000080000000000000800000000000005f52; asc _R; (total 255 bytes);
|
2: len 8; hex 800000000000005f; asc _;;
|
3: len 30; hex 52808000000000000000800000000000000080000000000000004e415f64; asc R NA_d; (total 239 bytes);
|
4: len 0; hex ; asc ;;
|
One of many possible causes of this could be MDEV-30009 and the InnoDB change buffer.
See a test case in the comment to
MDEV-23723.The stack trace there matches the very first stack trace in the description here, so it may be related. It doesn't however cause the corruption errors and other problems described here.