[MDEV-31394] Mariadb 10.5 crushed with specific query Created: 2023-06-02  Updated: 2023-07-09  Resolved: 2023-07-09

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.5.20
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Dmytro Lavryk Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Environment:

FreeBSD


Issue Links:
Duplicate
is duplicated by MDEV-31240 Crash with condition pushable into de... Closed

 Description   

230602 17:58:27 [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.5.20-MariaDB-log source revision: b735ca47738a1d2e995a429f40afd620eb7d8843
key_buffer_size=25165824
read_buffer_size=4194304
max_used_connections=10
max_threads=130
thread_count=10
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1092585 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x219511ec58
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 = 0x2193f91f38 thread_stack 0x49000
0x12c8dbc <my_print_stacktrace+0x3c> at /usr/local/libexec/mariadbd
0xc5e7e9 <handle_fatal_signal+0x299> at /usr/local/libexec/mariadbd
0x828a21a60 <pthread_sigmask+0x540> at /lib/libthr.so.3
0x828a210ac <pthread_setschedparam+0x82c> at /lib/libthr.so.3
0x7fffffffe2d3 <???> at ???
0xf6c0ac <_ZN13st_join_table21choose_best_splittingEjyPy+0x52c> at /usr/local/libexec/mariadbd
0xdedee4 <_Z16best_access_pathP4JOINP13st_join_tableyPK8POSITIONjbdPS3_S6_+0x194> at /usr/local/libexec/mariadbd
0xe0ce3a <_ZN4JOIN34make_notnull_conds_for_range_scansEv+0x194a> at /usr/local/libexec/mariadbd
0xdf1752 <_Z11choose_planP4JOINy+0x912> at /usr/local/libexec/mariadbd
0xdde41c <_ZN4JOIN42handle_implicit_grouping_with_window_funcsEv+0x2a2c> at /usr/local/libexec/mariadbd
0xdda5eb <_ZN4JOIN14optimize_innerEv+0x12fb> at /usr/local/libexec/mariadbd
0xdd7b52 <_ZN4JOIN8optimizeEv+0xa2> at /usr/local/libexec/mariadbd
0xd7f47b <_ZN13st_select_lex31optimize_unflattened_subqueriesEb+0x28b> at /usr/local/libexec/mariadbd
0xdd8b2e <_ZN4JOIN15optimize_stage2Ev+0xfce> at /usr/local/libexec/mariadbd
0xdda413 <_ZN4JOIN14optimize_innerEv+0x1123> at /usr/local/libexec/mariadbd
0xdd7b52 <_ZN4JOIN8optimizeEv+0xa2> at /usr/local/libexec/mariadbd
0xdd2512 <_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x92> at /usr/local/libexec/mariadbd
0xdd23ef <_Z13handle_selectP3THDP3LEXP13select_resultm+0x14f> at /usr/local/libexec/mariadbd
0xda3dbb <_Z12check_accessP3THD11privilege_tPKcPS1_P22st_grant_internal_infobb+0x84b> at /usr/local/libexec/mariadbd
0xd9f78d <_Z21mysql_execute_commandP3THD+0x5fd> at /usr/local/libexec/mariadbd
0xd9c7da <_Z11mysql_parseP3THDPcjP12Parser_statebb+0x21a> at /usr/local/libexec/mariadbd
0xd9acdf <_Z16dispatch_command19enum_server_commandP3THDPcjbb+0xcaf> at /usr/local/libexec/mariadbd
0xd9cb66 <_Z10do_commandP3THD+0x156> at /usr/local/libexec/mariadbd
0xebb7f9 <_Z24do_handle_one_connectionP7CONNECTb+0x119> at /usr/local/libexec/mariadbd
0xebb64b <handle_one_connection+0x7b> at /usr/local/libexec/mariadbd
0x10081db <_ZN11MyCTX_nopad6finishEPhPj+0x1452b> at /usr/local/libexec/mariadbd
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x2195149fb0): SELECT msopModification.id FROM `modx_msop_modifications` AS `msopModification` WHERE  (  (  ( `msopModification`.`rid` = 74 AND `msopModification`.`id` NOT IN (0) AND `msopModification`.`type` NOT IN (0) )  AND `msopModification`.`active` = 1 )  AND (IF((SELECT count(*) FROM (SELECT __grind.mid FROM `modx_msop_modification_options` AS `__grind` WHERE `__grind`.`key` = 'grind' GROUP BY __grind.mid ) as __grind WHERE __grind.mid = msopModification.id), EXISTS (SELECT NULL FROM (SELECT _grind.mid FROM `modx_msop_modification_options` AS `_grind` WHERE  ( `_grind`.`key` = 'grind' AND `_grind`.`value` = 'У зернах' )  GROUP BY _grind.mid ) as _grind WHERE _grind.mid = msopModification.id) ,TRUE)) AND (IF((SELECT count(*) FROM (SELECT __volume.mid FROM `modx_msop_modification_options` AS `__volume` WHERE `__volume`.`key` = 'volume' GROUP BY __volume.mid ) as __volume WHERE __volume.mid = msopModification.id), EXISTS (SELECT NULL FROM (SELECT _volume.mid FROM `modx_msop_modification_options` AS `_volume` WHERE  ( `_volume`.`key` = 'volume' AND `_volume`.`value` = '0.125' )  GROUP BY _volume.mid ) as _volume WHERE _volume.mid = msopModification.id) ,TRUE)) )  ORDER BY msopModification.type ASC, msopModification.rank ASC
 
Connection ID (thread ID): 274
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=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Core pattern: %N.core



 Comments   
Comment by Elena Stepanova [ 2023-06-06 ]

This appears to be the same bug as MDEV-31240.
The releases with the fix should be out very soon, let's keep it open until you confirm the fix works for you.

Generated at Thu Feb 08 10:23:32 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.