Am 03.10.2019 um 11:23 schrieb Thomas Plant: > Am 03.10.2019 um 10:27 schrieb Thomas Plant: >> Hello, >> >> we have a client VM with MariaDB 10.4.8 which crashes always on the same >> query (it's in the log). Can someone help me to debug the problem, or is >> it already known problem? Server ist a CentOS 7 patched up to date and >> MariaDB 10.4.8 from the MariaDB repositories. >> >> Log contains the following: >> >> 191003 9:43:19 [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.8-MariaDB >> key_buffer_size=134217728 >> read_buffer_size=131072 >> max_used_connections=1 >> max_threads=302 >> thread_count=7 >> It is possible that mysqld could use up to >> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = >> 795622 K bytes of memory >> Hope that's ok; if not, decrease some variables in the equation. >> >> Thread pointer: 0x55d12dc0ed28 >> 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 = 0x7ff2fd21dcf0 thread_stack 0x49000 >> /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55d12b70483e] >> /usr/sbin/mysqld(handle_fatal_signal+0x30f)[0x55d12b19ae0f] >> sigaction.c:0(__restore_rt)[0x7ff3153325f0] >> /usr/sbin/mysqld(handler_index_cond_check+0xbf)[0x55d12b1a56af] >> /usr/sbin/mysqld(+0x59ee80)[0x55d12ae94e80] >> /usr/sbin/mysqld(+0xb340cd)[0x55d12b42a0cd] >> /usr/sbin/mysqld(+0xa52c87)[0x55d12b348c87] >> /usr/sbin/mysqld(+0xa52edf)[0x55d12b348edf] >> /usr/sbin/mysqld(_ZN7handler11ha_rnd_nextEPh+0x10f)[0x55d12b19f8ff] >> /usr/sbin/mysqld(_Z13rr_sequentialP11READ_RECORD+0x1c)[0x55d12b2cde9c] >> /usr/sbin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x1a9)[0x55d12afc7dd9] >> /usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0xb9c)[0x55d12afea4cc] >> /usr/sbin/mysqld(_ZN4JOIN4execEv+0x33)[0x55d12afea723] >> /usr/sbin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x186)[0x55d12afe8a26] >> >> /usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x1d7)[0x55d12afe9597] >> /usr/sbin/mysqld(+0x58dd2a)[0x55d12ae83d2a] >> /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x4591)[0x55d12af90641] >> /usr/sbin/mysqld(_ZN18Prepared_statement7executeEP6Stringb+0x4b6)[0x55d12afa8d06] >> /usr/sbin/mysqld(_ZN18Prepared_statement12execute_loopEP6StringbPhS2_+0x92)[0x55d12afa8ec2] >> /usr/sbin/mysqld(+0x6b3827)[0x55d12afa9827] >> /usr/sbin/mysqld(_Z19mysqld_stmt_executeP3THDPcj+0x27)[0x55d12afa98b7] >> /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x1625)[0x55d12af97d85] >> /usr/sbin/mysqld(_Z10do_commandP3THD+0x11c)[0x55d12af99aac] >> /usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x1fa)[0x55d12b07718a] >> /usr/sbin/mysqld(handle_one_connection+0x3d)[0x55d12b07726d] >> pthread_create.c:0(start_thread)[0x7ff31532ae65] >> /lib64/libc.so.6(clone+0x6d)[0x7ff3136cb88d] >> >> Trying to get some variables. >> Some pointers may be invalid and cause the dump to abort. >> Query (0x55d12dc24b38): select * from `users` where (`role` = ? or >> `role` = ?) and exists (select * from `email_templates` inner join >> `users_email` on `email_template >> s`.`id` = `users_email`.`email_template_id` where `users`.`id` = >> `users_email`.`user_id` and `email_template_id` = ?) and >> `users`.`deleted_at` is null >> Connection ID (thread ID): 9 >> 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_pushdow >> n=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_increme >> ntal=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 >> >> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains >> information that should help you find out what is causing the crash. >> Writing a core file... >> Working directory at /var/lib/mysql >> Resource Limits: >> Limit Soft Limit Hard Limit Units >> Max cpu time unlimited unlimited seconds >> Max file size unlimited unlimited bytes >> Max data size unlimited unlimited bytes >> Max stack size 8388608 unlimited bytes >> Max core file size 0 unlimited bytes >> Max resident set unlimited unlimited bytes >> Max processes 15028 15028 >> processes >> Max open files 16364 16364 files >> Max locked memory 65536 65536 bytes >> Max address space unlimited unlimited bytes >> Max file locks unlimited unlimited locks >> Max pending signals 15028 15028 signals >> Max msgqueue size 819200 819200 bytes >> Max nice priority 0 0 >> Max realtime priority 0 0 >> Max realtime timeout unlimited unlimited us >> Core pattern: core >> >> >> Thanks for any hint. >> Kind Regards, >> Thomas >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~maria-discuss >> Post to : maria-discuss@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~maria-discuss >> More help : https://help.launchpad.net/ListHelp > Client did some tests and he discovered that the following query will > crash reliably: > > > SELECT > * > FROM > `users` > WHERE > ( `role` = 1 OR `role` = 10 ) > AND EXISTS ( SELECT * FROM `email_templates` INNER JOIN `users_email` ON > `email_templates`.`id` = `users_email`.`email_template_id` WHERE > `users`.`id` = `users_email`.`user_id` AND `email_template_id` = 12 ) > AND `users`.`deleted_at` IS NULL; > > > Strange thing is when he changes the `email_template_id` = 12 to > `email_template_id` = 11 (or any other value) the query works. > > I checked with "mysqlcheck -ce dbname" and no error resulted. > > > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-discuss > Post to : maria-discuss@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-discuss > More help : https://help.launchpad.net/ListHelp Installed MariaDB 10.3 and the query gives no problems. So is this a 10.4 bug?
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
