Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.11.7, 11.3.2
-
None
-
10.11.7 & 11.3.2 on docker linux/arm64
10.11.7 on AWS RDS
mysql client version: Ver 8.1.0 for macos13.3 on arm64 (Homebrew)
Description
Certain queries involving a generated column will cause the mariadb server process to segfault giving output like below before exiting:
240329 5:38:20 [ERROR] mysqld got signal 11 ;
|
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: 11.3.2-MariaDB-1:11.3.2+maria~ubu2204 source revision: 068a6819eb63bcb01fdfa037c9bf3bf63c33ee42
|
key_buffer_size=134217728
|
read_buffer_size=131072
|
max_used_connections=1
|
max_threads=153
|
thread_count=1
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 468073 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0xffff44000c78
|
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...
|
The schema in question looks like
CREATE TABLE `testtable` ( |
`a_id` int(11) DEFAULT NULL, |
`b_id` int(11) NOT NULL, |
`c_id` varchar(64) DEFAULT NULL, |
`d_bool` tinyint(1) DEFAULT 1, |
`d_bool_gen` tinyint(1) GENERATED ALWAYS AS (if(`d_bool`,1,NULL)), |
UNIQUE KEY `testkey` (`b_id`,`c_id`,`d_bool_gen`), |
KEY `a_key` (`a_id`) |
);
|
Noting the existence of a unique key constraint involving a generated column. Then a query that looks like
select * from testtable where b_id = 10 and a_id = 10; |
can trigger the fault seen above. Explaining the above query gives the output below which is why I suspect the rowid filter is involved
+------+-------------+-----------+------------+---------------+---------------+---------+-------+----------+---------------------------------+
|
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
|
+------+-------------+-----------+------------+---------------+---------------+---------+-------+----------+---------------------------------+
|
| 1 | SIMPLE | testtable | ref|filter | testkey,a_key | testkey|a_key | 4|5 | const | 202 (0%) | Using where; Using rowid filter |
|
+------+-------------+-----------+------------+---------------+---------------+---------+-------+----------+---------------------------------+
|
To help with reproduction I have found that the following synthetic data is sufficient to trigger the fault
INSERT INTO testtable (a_id, b_id, c_id, d_bool) |
SELECT MOD(seq, 1000), MOD(seq, 1001), IF(MOD(seq, 3) = 0, NULL, LEFT(MD5(seq), 64)), MOD(seq, 2) FROM seq_1_to_100000; |
INSERT INTO testtable (a_id, b_id, c_id, d_bool) |
SELECT 10, 10, IF(MOD(seq, 3) = 0, NULL, LEFT(MD5(-seq), 64)), MOD(seq, 2) FROM seq_1_to_100; |
INSERT INTO testtable (a_id, b_id, c_id, d_bool) VALUES |
(10, 10, '', 0), |
(10, 10, '', 1); |
With that synthetic data in place, repeatedly querying the below query will eventually cause the segfault.
select * from testtable where b_id = 10 and a_id = 10; |
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
Thanks marko. You are right. Actually, the scenario and cause is slightly different from MDEV-31154. The issue is readily repeatable and the failure is due to the jump to no_icp without properly resetting the push down state.
Fortunately I had observed this issue and it is already fixed as part of MDEV-31154.
+ 3. In most cases, it works today by jumping to goto no_icp when we
+ encounter a virtual column. This is hackish and already have some
+ issues as it cannot handle PK and all states are not reset properly,
+ for example, idx_cond_n_cols is not reset.
+
I am pasting the stack here as it is different from MDEV-31154 and could help us mapping similar issues in future.
#0 0x00007ffff72969fc in pthread_kill () from /lib/x86_64-linux-gnu/libc.so.6
|
#1 0x00007ffff7242476 in raise () from /lib/x86_64-linux-gnu/libc.so.6
|
#2 0x00007ffff72287f3 in abort () from /lib/x86_64-linux-gnu/libc.so.6
|
#3 0x00007ffff722871b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
|
#4 0x00007ffff7239e96 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
|
#5 0x00005555569555ca in row_sel_store_mysql_field (mysql_rec=0x7fff9c022430 "\372\n", prebuilt=0x7fff9c025298, rec=0x7fffdb799b4e "\200", index=0x7fff9c024508, offsets=0x7ffff40be760, field_no=1, templ=0x7fff9c073b68)
|
at /home/hdd/deb/maria-src2/storage/innobase/row/row0sel.cc:3048
|
#6 0x00005555569580db in row_search_idx_cond_check (mysql_rec=0x7fff9c022430 "\372\n", prebuilt=0x7fff9c025298, rec=0x7fffdb799b4e "\200", offsets=0x7ffff40be760) at /home/hdd/deb/maria-src2/storage/innobase/row/row0sel.cc:4059
|
#7 0x000055555695c745 in row_search_mvcc (buf=0x7fff9c022430 "\372\n", mode=PAGE_CUR_GE, prebuilt=0x7fff9c025298, match_mode=1, direction=0) at /home/hdd/deb/maria-src2/storage/innobase/row/row0sel.cc:5466
|
#8 0x000055555673c20e in ha_innobase::index_read (this=0x7fff9c01e150, buf=0x7fff9c022430 "\372\n", key_ptr=0x7fff9c01a8f0 "\n", key_len=4, find_flag=HA_READ_KEY_EXACT)
|
at /home/hdd/deb/maria-src2/storage/innobase/handler/ha_innodb.cc:9038
|
#9 0x0000555556250040 in handler::index_read_map (this=0x7fff9c01e150, buf=0x7fff9c022430 "\372\n", key=0x7fff9c01a8f0 "\n", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /home/hdd/deb/maria-src2/sql/handler.h:3856
|
#10 0x0000555556323d63 in handler::ha_index_read_map (this=0x7fff9c01e150, buf=0x7fff9c022430 "\372\n", key=0x7fff9c01a8f0 "\n", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /home/hdd/deb/maria-src2/sql/handler.cc:3520
|
#11 0x0000555555ff8d64 in join_read_always_key (tab=0x7fff9c06eb70) at /home/hdd/deb/maria-src2/sql/sql_select.cc:23119
|
#12 0x0000555555ff72da in sub_select (join=0x7fff9c0189f8, join_tab=0x7fff9c06eb70, end_of_records=false) at /home/hdd/deb/maria-src2/sql/sql_select.cc:22336
|
#13 0x0000555555ff68c2 in do_select (join=0x7fff9c0189f8, procedure=0x0) at /home/hdd/deb/maria-src2/sql/sql_select.cc:21862
|
#14 0x0000555555fc8071 in JOIN::exec_inner (this=0x7fff9c0189f8) at /home/hdd/deb/maria-src2/sql/sql_select.cc:4910
|
#15 0x0000555555fc718d in JOIN::exec (this=0x7fff9c0189f8) at /home/hdd/deb/maria-src2/sql/sql_select.cc:4688
|
#16 0x0000555555fc88b7 in mysql_select (thd=0x7fff9c000dc8, tables=0x7fff9c017080, fields=..., conds=0x7fff9c017f40, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2164525824, result=0x7fff9c0189d0, unit=0x7fff9c005268, select_lex=0x7fff9c016a48) at /home/hdd/deb/maria-src2/sql/sql_select.cc:5168
|
This might share a root cause with
MDEV-31154.