Details
-
Bug
-
Status: In Testing (View Workflow)
-
Major
-
Resolution: Unresolved
-
11.7.2
-
Docker image mariadb:latest in a K3s Kubernetes cluster on an Arch Linux machine
Description
MariaDB crashes when executing a query that tries to access a table information_schema.users
I haven't checked with other similar tables, but it surely does not happen with the tables "tables" and "columns" of the information_schema schema
Following is the stack trace:
[ERROR] mariadbd 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 about how to report
|
a bug on https://jira.mariadb.org/.
|
|
|
Please include the information from the server start above, to the end of the
|
information below.
|
|
|
Server version: 11.7.2-MariaDB-ubu2404 source revision: 80067a69feaeb5df30abb1bfaf7d4e713ccbf027
|
|
|
The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/
|
contains instructions to obtain a better version of the backtrace below.
|
Following these instructions will help MariaDB developers provide a fix quicker.
|
|
|
Attempting backtrace. Include this in the bug report.
|
(note: Retrieving this information may fail)
|
|
|
Thread pointer: 0x7b8338000c68
|
stack_bottom = 0x7b839cf33000 thread_stack 0x49000
|
addr2line: 'mariadbd': No such file
|
Printing to addr2line failed
|
mariadbd(my_print_stacktrace+0x30)[0x597c5edc4550]
|
mariadbd(handle_fatal_signal+0x1f3)[0x597c5e94e763]
|
/lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7b83b76cd330]
|
addr2line: 'mariadbd': No such file
|
mariadbd(_Z23fill_users_schema_tableP3THDP10TABLE_LISTP4Item+0x168)[0x597c5e5af418]
|
mariadbd(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x2aa)[0x597c5e70192a]
|
mariadbd(_ZN4JOIN10exec_innerEv+0x9dd)[0x597c5e69742d]
|
mariadbd(_ZN4JOIN4execEv+0x37)[0x597c5e697de7]
|
mariadbd(_ZN30subselect_single_select_engine4execEv+0x149)[0x597c5ea21e09]
|
mariadbd(_ZN24Item_singlerow_subselect7val_intEv+0x64)[0x597c5ea12bb4]
|
mariadbd(_ZN14Arg_comparator18compare_int_signedEv+0x1d)[0x597c5e985d7d]
|
mariadbd(_ZN12Item_func_eq8val_boolEv+0x2f)[0x597c5e986e0f]
|
mariadbd(_ZN15Item_bool_func215remove_eq_condsEP3THDPN4Item11cond_resultEb+0x84)[0x597c5e6bba94]
|
mariadbd(_ZN9Item_cond15remove_eq_condsEP3THDPN4Item11cond_resultEb+0x125)[0x597c5e6c43f5]
|
mariadbd(+0x88dcdd)[0x597c5e6c3cdd]
|
mariadbd(_ZN4JOIN14optimize_innerEv+0x5ca)[0x597c5e69f17a]
|
mariadbd(_ZN4JOIN8optimizeEv+0x10a)[0x597c5e6a034a]
|
mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xcf)[0x597c5e6a047f]
|
mariadbd(_Z13handle_selectP3THDP3LEXP13select_resulty+0x17a)[0x597c5e6a0faa]
|
mariadbd(+0x810ee1)[0x597c5e646ee1]
|
mariadbd(_Z21mysql_execute_commandP3THDb+0x3868)[0x597c5e652ba8]
|
mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x19a)[0x597c5e65ac2a]
|
mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0xb08)[0x597c5e64c5f8]
|
mariadbd(_Z10do_commandP3THDb+0x164)[0x597c5e64e1b4]
|
mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x65b)[0x597c5e7dc8ab]
|
mariadbd(handle_one_connection+0x71)[0x597c5e7dccf1]
|
mariadbd(+0xd3ebde)[0x597c5eb74bde]
|
/lib/x86_64-linux-gnu/libc.so.6(+0x9caa4)[0x7b83b7724aa4]
|
/lib/x86_64-linux-gnu/libc.so.6(__clone+0x44)[0x7b83b77b1a34]
|
|
|
Connection ID (thread ID): 5
|
Status: NOT_KILLED
|
Query (0x7b8338012f90): SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1 --
|
|
|
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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,hash_join_cardinality=on,cset_narrowing=on,sargable_casefold=on
|
|
|
Writing a core file...
|
Working directory at /var/lib/mysql
|
Resource Limits (excludes unlimited resources):
|
Limit Soft Limit Hard Limit Units
|
Max stack size 8388608 unlimited bytes
|
Max open files 32190 32190 files
|
Max locked memory 8388608 8388608 bytes
|
Max pending signals 92541 92541 signals
|
Max msgqueue size 819200 819200 bytes
|
Max nice priority 0 0
|
Max realtime priority 0 0
|
Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
|
|
|
Kernel version: Linux version 6.13.6-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Fri, 07 Mar 2025 20:19:00 +0000
|
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Priority | Minor [ 4 ] | Major [ 3 ] |
| Description |
MariaDB crashes when executing a query that tries to access a (non-existent) table information_schema.users
It does not appear to happen with other non-existent tables. Following is the stack trace: [ERROR] mariadbd 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 about how to report a bug on https://jira.mariadb.org/. Please include the information from the server start above, to the end of the information below. Server version: 11.7.2-MariaDB-ubu2404 source revision: 80067a69feaeb5df30abb1bfaf7d4e713ccbf027 The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains instructions to obtain a better version of the backtrace below. Following these instructions will help MariaDB developers provide a fix quicker. Attempting backtrace. Include this in the bug report. (note: Retrieving this information may fail) Thread pointer: 0x7b8338000c68 stack_bottom = 0x7b839cf33000 thread_stack 0x49000 addr2line: 'mariadbd': No such file Printing to addr2line failed mariadbd(my_print_stacktrace+0x30)[0x597c5edc4550] mariadbd(handle_fatal_signal+0x1f3)[0x597c5e94e763] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7b83b76cd330] addr2line: 'mariadbd': No such file mariadbd(_Z23fill_users_schema_tableP3THDP10TABLE_LISTP4Item+0x168)[0x597c5e5af418] mariadbd(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x2aa)[0x597c5e70192a] mariadbd(_ZN4JOIN10exec_innerEv+0x9dd)[0x597c5e69742d] mariadbd(_ZN4JOIN4execEv+0x37)[0x597c5e697de7] mariadbd(_ZN30subselect_single_select_engine4execEv+0x149)[0x597c5ea21e09] mariadbd(_ZN24Item_singlerow_subselect7val_intEv+0x64)[0x597c5ea12bb4] mariadbd(_ZN14Arg_comparator18compare_int_signedEv+0x1d)[0x597c5e985d7d] mariadbd(_ZN12Item_func_eq8val_boolEv+0x2f)[0x597c5e986e0f] mariadbd(_ZN15Item_bool_func215remove_eq_condsEP3THDPN4Item11cond_resultEb+0x84)[0x597c5e6bba94] mariadbd(_ZN9Item_cond15remove_eq_condsEP3THDPN4Item11cond_resultEb+0x125)[0x597c5e6c43f5] mariadbd(+0x88dcdd)[0x597c5e6c3cdd] mariadbd(_ZN4JOIN14optimize_innerEv+0x5ca)[0x597c5e69f17a] mariadbd(_ZN4JOIN8optimizeEv+0x10a)[0x597c5e6a034a] mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xcf)[0x597c5e6a047f] mariadbd(_Z13handle_selectP3THDP3LEXP13select_resulty+0x17a)[0x597c5e6a0faa] mariadbd(+0x810ee1)[0x597c5e646ee1] mariadbd(_Z21mysql_execute_commandP3THDb+0x3868)[0x597c5e652ba8] mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x19a)[0x597c5e65ac2a] mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0xb08)[0x597c5e64c5f8] mariadbd(_Z10do_commandP3THDb+0x164)[0x597c5e64e1b4] mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x65b)[0x597c5e7dc8ab] mariadbd(handle_one_connection+0x71)[0x597c5e7dccf1] mariadbd(+0xd3ebde)[0x597c5eb74bde] /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4)[0x7b83b7724aa4] /lib/x86_64-linux-gnu/libc.so.6(__clone+0x44)[0x7b83b77b1a34] Connection ID (thread ID): 5 Status: NOT_KILLED Query (0x7b8338012f90): SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1 -- Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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,hash_join_cardinality=on,cset_narrowing=on,sargable_casefold=on Writing a core file... Working directory at /var/lib/mysql Resource Limits (excludes unlimited resources): Limit Soft Limit Hard Limit Units Max stack size 8388608 unlimited bytes Max open files 32190 32190 files Max locked memory 8388608 8388608 bytes Max pending signals 92541 92541 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h Kernel version: Linux version 6.13.6-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Fri, 07 Mar 2025 20:19:00 +0000 |
MariaDB crashes when executing a query that tries to access a (non-existent) table information_schema.users
It does not appear to happen with other non-existent tables. Following is the stack trace: {noformat} [ERROR] mariadbd 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 about how to report a bug on https://jira.mariadb.org/. Please include the information from the server start above, to the end of the information below. Server version: 11.7.2-MariaDB-ubu2404 source revision: 80067a69feaeb5df30abb1bfaf7d4e713ccbf027 The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains instructions to obtain a better version of the backtrace below. Following these instructions will help MariaDB developers provide a fix quicker. Attempting backtrace. Include this in the bug report. (note: Retrieving this information may fail) Thread pointer: 0x7b8338000c68 stack_bottom = 0x7b839cf33000 thread_stack 0x49000 addr2line: 'mariadbd': No such file Printing to addr2line failed mariadbd(my_print_stacktrace+0x30)[0x597c5edc4550] mariadbd(handle_fatal_signal+0x1f3)[0x597c5e94e763] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7b83b76cd330] addr2line: 'mariadbd': No such file mariadbd(_Z23fill_users_schema_tableP3THDP10TABLE_LISTP4Item+0x168)[0x597c5e5af418] mariadbd(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x2aa)[0x597c5e70192a] mariadbd(_ZN4JOIN10exec_innerEv+0x9dd)[0x597c5e69742d] mariadbd(_ZN4JOIN4execEv+0x37)[0x597c5e697de7] mariadbd(_ZN30subselect_single_select_engine4execEv+0x149)[0x597c5ea21e09] mariadbd(_ZN24Item_singlerow_subselect7val_intEv+0x64)[0x597c5ea12bb4] mariadbd(_ZN14Arg_comparator18compare_int_signedEv+0x1d)[0x597c5e985d7d] mariadbd(_ZN12Item_func_eq8val_boolEv+0x2f)[0x597c5e986e0f] mariadbd(_ZN15Item_bool_func215remove_eq_condsEP3THDPN4Item11cond_resultEb+0x84)[0x597c5e6bba94] mariadbd(_ZN9Item_cond15remove_eq_condsEP3THDPN4Item11cond_resultEb+0x125)[0x597c5e6c43f5] mariadbd(+0x88dcdd)[0x597c5e6c3cdd] mariadbd(_ZN4JOIN14optimize_innerEv+0x5ca)[0x597c5e69f17a] mariadbd(_ZN4JOIN8optimizeEv+0x10a)[0x597c5e6a034a] mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xcf)[0x597c5e6a047f] mariadbd(_Z13handle_selectP3THDP3LEXP13select_resulty+0x17a)[0x597c5e6a0faa] mariadbd(+0x810ee1)[0x597c5e646ee1] mariadbd(_Z21mysql_execute_commandP3THDb+0x3868)[0x597c5e652ba8] mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x19a)[0x597c5e65ac2a] mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0xb08)[0x597c5e64c5f8] mariadbd(_Z10do_commandP3THDb+0x164)[0x597c5e64e1b4] mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x65b)[0x597c5e7dc8ab] mariadbd(handle_one_connection+0x71)[0x597c5e7dccf1] mariadbd(+0xd3ebde)[0x597c5eb74bde] /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4)[0x7b83b7724aa4] /lib/x86_64-linux-gnu/libc.so.6(__clone+0x44)[0x7b83b77b1a34] Connection ID (thread ID): 5 Status: NOT_KILLED Query (0x7b8338012f90): SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1 -- Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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,hash_join_cardinality=on,cset_narrowing=on,sargable_casefold=on Writing a core file... Working directory at /var/lib/mysql Resource Limits (excludes unlimited resources): Limit Soft Limit Hard Limit Units Max stack size 8388608 unlimited bytes Max open files 32190 32190 files Max locked memory 8388608 8388608 bytes Max pending signals 92541 92541 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h Kernel version: Linux version 6.13.6-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Fri, 07 Mar 2025 20:19:00 +0000{noformat} |
| Description |
MariaDB crashes when executing a query that tries to access a (non-existent) table information_schema.users
It does not appear to happen with other non-existent tables. Following is the stack trace: {noformat} [ERROR] mariadbd 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 about how to report a bug on https://jira.mariadb.org/. Please include the information from the server start above, to the end of the information below. Server version: 11.7.2-MariaDB-ubu2404 source revision: 80067a69feaeb5df30abb1bfaf7d4e713ccbf027 The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains instructions to obtain a better version of the backtrace below. Following these instructions will help MariaDB developers provide a fix quicker. Attempting backtrace. Include this in the bug report. (note: Retrieving this information may fail) Thread pointer: 0x7b8338000c68 stack_bottom = 0x7b839cf33000 thread_stack 0x49000 addr2line: 'mariadbd': No such file Printing to addr2line failed mariadbd(my_print_stacktrace+0x30)[0x597c5edc4550] mariadbd(handle_fatal_signal+0x1f3)[0x597c5e94e763] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7b83b76cd330] addr2line: 'mariadbd': No such file mariadbd(_Z23fill_users_schema_tableP3THDP10TABLE_LISTP4Item+0x168)[0x597c5e5af418] mariadbd(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x2aa)[0x597c5e70192a] mariadbd(_ZN4JOIN10exec_innerEv+0x9dd)[0x597c5e69742d] mariadbd(_ZN4JOIN4execEv+0x37)[0x597c5e697de7] mariadbd(_ZN30subselect_single_select_engine4execEv+0x149)[0x597c5ea21e09] mariadbd(_ZN24Item_singlerow_subselect7val_intEv+0x64)[0x597c5ea12bb4] mariadbd(_ZN14Arg_comparator18compare_int_signedEv+0x1d)[0x597c5e985d7d] mariadbd(_ZN12Item_func_eq8val_boolEv+0x2f)[0x597c5e986e0f] mariadbd(_ZN15Item_bool_func215remove_eq_condsEP3THDPN4Item11cond_resultEb+0x84)[0x597c5e6bba94] mariadbd(_ZN9Item_cond15remove_eq_condsEP3THDPN4Item11cond_resultEb+0x125)[0x597c5e6c43f5] mariadbd(+0x88dcdd)[0x597c5e6c3cdd] mariadbd(_ZN4JOIN14optimize_innerEv+0x5ca)[0x597c5e69f17a] mariadbd(_ZN4JOIN8optimizeEv+0x10a)[0x597c5e6a034a] mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xcf)[0x597c5e6a047f] mariadbd(_Z13handle_selectP3THDP3LEXP13select_resulty+0x17a)[0x597c5e6a0faa] mariadbd(+0x810ee1)[0x597c5e646ee1] mariadbd(_Z21mysql_execute_commandP3THDb+0x3868)[0x597c5e652ba8] mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x19a)[0x597c5e65ac2a] mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0xb08)[0x597c5e64c5f8] mariadbd(_Z10do_commandP3THDb+0x164)[0x597c5e64e1b4] mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x65b)[0x597c5e7dc8ab] mariadbd(handle_one_connection+0x71)[0x597c5e7dccf1] mariadbd(+0xd3ebde)[0x597c5eb74bde] /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4)[0x7b83b7724aa4] /lib/x86_64-linux-gnu/libc.so.6(__clone+0x44)[0x7b83b77b1a34] Connection ID (thread ID): 5 Status: NOT_KILLED Query (0x7b8338012f90): SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1 -- Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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,hash_join_cardinality=on,cset_narrowing=on,sargable_casefold=on Writing a core file... Working directory at /var/lib/mysql Resource Limits (excludes unlimited resources): Limit Soft Limit Hard Limit Units Max stack size 8388608 unlimited bytes Max open files 32190 32190 files Max locked memory 8388608 8388608 bytes Max pending signals 92541 92541 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h Kernel version: Linux version 6.13.6-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Fri, 07 Mar 2025 20:19:00 +0000{noformat} |
MariaDB crashes when executing a query that tries to access a table information_schema.users
I haven't checked with other similar tables, but it surely does not happen with the tables "tables" and "columns" of the information_schema schema Following is the stack trace: [ERROR] mariadbd 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 about how to report a bug on https://jira.mariadb.org/. Please include the information from the server start above, to the end of the information below. Server version: 11.7.2-MariaDB-ubu2404 source revision: 80067a69feaeb5df30abb1bfaf7d4e713ccbf027 The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains instructions to obtain a better version of the backtrace below. Following these instructions will help MariaDB developers provide a fix quicker. Attempting backtrace. Include this in the bug report. (note: Retrieving this information may fail) Thread pointer: 0x7b8338000c68 stack_bottom = 0x7b839cf33000 thread_stack 0x49000 addr2line: 'mariadbd': No such file Printing to addr2line failed mariadbd(my_print_stacktrace+0x30)[0x597c5edc4550] mariadbd(handle_fatal_signal+0x1f3)[0x597c5e94e763] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7b83b76cd330] addr2line: 'mariadbd': No such file mariadbd(_Z23fill_users_schema_tableP3THDP10TABLE_LISTP4Item+0x168)[0x597c5e5af418] mariadbd(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x2aa)[0x597c5e70192a] mariadbd(_ZN4JOIN10exec_innerEv+0x9dd)[0x597c5e69742d] mariadbd(_ZN4JOIN4execEv+0x37)[0x597c5e697de7] mariadbd(_ZN30subselect_single_select_engine4execEv+0x149)[0x597c5ea21e09] mariadbd(_ZN24Item_singlerow_subselect7val_intEv+0x64)[0x597c5ea12bb4] mariadbd(_ZN14Arg_comparator18compare_int_signedEv+0x1d)[0x597c5e985d7d] mariadbd(_ZN12Item_func_eq8val_boolEv+0x2f)[0x597c5e986e0f] mariadbd(_ZN15Item_bool_func215remove_eq_condsEP3THDPN4Item11cond_resultEb+0x84)[0x597c5e6bba94] mariadbd(_ZN9Item_cond15remove_eq_condsEP3THDPN4Item11cond_resultEb+0x125)[0x597c5e6c43f5] mariadbd(+0x88dcdd)[0x597c5e6c3cdd] mariadbd(_ZN4JOIN14optimize_innerEv+0x5ca)[0x597c5e69f17a] mariadbd(_ZN4JOIN8optimizeEv+0x10a)[0x597c5e6a034a] mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xcf)[0x597c5e6a047f] mariadbd(_Z13handle_selectP3THDP3LEXP13select_resulty+0x17a)[0x597c5e6a0faa] mariadbd(+0x810ee1)[0x597c5e646ee1] mariadbd(_Z21mysql_execute_commandP3THDb+0x3868)[0x597c5e652ba8] mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x19a)[0x597c5e65ac2a] mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0xb08)[0x597c5e64c5f8] mariadbd(_Z10do_commandP3THDb+0x164)[0x597c5e64e1b4] mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x65b)[0x597c5e7dc8ab] mariadbd(handle_one_connection+0x71)[0x597c5e7dccf1] mariadbd(+0xd3ebde)[0x597c5eb74bde] /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4)[0x7b83b7724aa4] /lib/x86_64-linux-gnu/libc.so.6(__clone+0x44)[0x7b83b77b1a34] Connection ID (thread ID): 5 Status: NOT_KILLED Query (0x7b8338012f90): SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1 -- Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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,hash_join_cardinality=on,cset_narrowing=on,sargable_casefold=on Writing a core file... Working directory at /var/lib/mysql Resource Limits (excludes unlimited resources): Limit Soft Limit Hard Limit Units Max stack size 8388608 unlimited bytes Max open files 32190 32190 files Max locked memory 8388608 8388608 bytes Max pending signals 92541 92541 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h Kernel version: Linux version 6.13.6-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Fri, 07 Mar 2025 20:19:00 +0000 |
| Status | Open [ 1 ] | Needs Feedback [ 10501 ] |
| Description |
MariaDB crashes when executing a query that tries to access a table information_schema.users
I haven't checked with other similar tables, but it surely does not happen with the tables "tables" and "columns" of the information_schema schema Following is the stack trace: [ERROR] mariadbd 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 about how to report a bug on https://jira.mariadb.org/. Please include the information from the server start above, to the end of the information below. Server version: 11.7.2-MariaDB-ubu2404 source revision: 80067a69feaeb5df30abb1bfaf7d4e713ccbf027 The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains instructions to obtain a better version of the backtrace below. Following these instructions will help MariaDB developers provide a fix quicker. Attempting backtrace. Include this in the bug report. (note: Retrieving this information may fail) Thread pointer: 0x7b8338000c68 stack_bottom = 0x7b839cf33000 thread_stack 0x49000 addr2line: 'mariadbd': No such file Printing to addr2line failed mariadbd(my_print_stacktrace+0x30)[0x597c5edc4550] mariadbd(handle_fatal_signal+0x1f3)[0x597c5e94e763] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7b83b76cd330] addr2line: 'mariadbd': No such file mariadbd(_Z23fill_users_schema_tableP3THDP10TABLE_LISTP4Item+0x168)[0x597c5e5af418] mariadbd(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x2aa)[0x597c5e70192a] mariadbd(_ZN4JOIN10exec_innerEv+0x9dd)[0x597c5e69742d] mariadbd(_ZN4JOIN4execEv+0x37)[0x597c5e697de7] mariadbd(_ZN30subselect_single_select_engine4execEv+0x149)[0x597c5ea21e09] mariadbd(_ZN24Item_singlerow_subselect7val_intEv+0x64)[0x597c5ea12bb4] mariadbd(_ZN14Arg_comparator18compare_int_signedEv+0x1d)[0x597c5e985d7d] mariadbd(_ZN12Item_func_eq8val_boolEv+0x2f)[0x597c5e986e0f] mariadbd(_ZN15Item_bool_func215remove_eq_condsEP3THDPN4Item11cond_resultEb+0x84)[0x597c5e6bba94] mariadbd(_ZN9Item_cond15remove_eq_condsEP3THDPN4Item11cond_resultEb+0x125)[0x597c5e6c43f5] mariadbd(+0x88dcdd)[0x597c5e6c3cdd] mariadbd(_ZN4JOIN14optimize_innerEv+0x5ca)[0x597c5e69f17a] mariadbd(_ZN4JOIN8optimizeEv+0x10a)[0x597c5e6a034a] mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xcf)[0x597c5e6a047f] mariadbd(_Z13handle_selectP3THDP3LEXP13select_resulty+0x17a)[0x597c5e6a0faa] mariadbd(+0x810ee1)[0x597c5e646ee1] mariadbd(_Z21mysql_execute_commandP3THDb+0x3868)[0x597c5e652ba8] mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x19a)[0x597c5e65ac2a] mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0xb08)[0x597c5e64c5f8] mariadbd(_Z10do_commandP3THDb+0x164)[0x597c5e64e1b4] mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x65b)[0x597c5e7dc8ab] mariadbd(handle_one_connection+0x71)[0x597c5e7dccf1] mariadbd(+0xd3ebde)[0x597c5eb74bde] /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4)[0x7b83b7724aa4] /lib/x86_64-linux-gnu/libc.so.6(__clone+0x44)[0x7b83b77b1a34] Connection ID (thread ID): 5 Status: NOT_KILLED Query (0x7b8338012f90): SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1 -- Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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,hash_join_cardinality=on,cset_narrowing=on,sargable_casefold=on Writing a core file... Working directory at /var/lib/mysql Resource Limits (excludes unlimited resources): Limit Soft Limit Hard Limit Units Max stack size 8388608 unlimited bytes Max open files 32190 32190 files Max locked memory 8388608 8388608 bytes Max pending signals 92541 92541 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h Kernel version: Linux version 6.13.6-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Fri, 07 Mar 2025 20:19:00 +0000 |
MariaDB crashes when executing a query that tries to access a table information_schema.users
I haven't checked with other similar tables, but it surely does not happen with the tables "tables" and "columns" of the information_schema schema Following is the stack trace: {noformat} [ERROR] mariadbd 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 about how to report a bug on https://jira.mariadb.org/. Please include the information from the server start above, to the end of the information below. Server version: 11.7.2-MariaDB-ubu2404 source revision: 80067a69feaeb5df30abb1bfaf7d4e713ccbf027 The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains instructions to obtain a better version of the backtrace below. Following these instructions will help MariaDB developers provide a fix quicker. Attempting backtrace. Include this in the bug report. (note: Retrieving this information may fail) Thread pointer: 0x7b8338000c68 stack_bottom = 0x7b839cf33000 thread_stack 0x49000 addr2line: 'mariadbd': No such file Printing to addr2line failed mariadbd(my_print_stacktrace+0x30)[0x597c5edc4550] mariadbd(handle_fatal_signal+0x1f3)[0x597c5e94e763] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7b83b76cd330] addr2line: 'mariadbd': No such file mariadbd(_Z23fill_users_schema_tableP3THDP10TABLE_LISTP4Item+0x168)[0x597c5e5af418] mariadbd(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x2aa)[0x597c5e70192a] mariadbd(_ZN4JOIN10exec_innerEv+0x9dd)[0x597c5e69742d] mariadbd(_ZN4JOIN4execEv+0x37)[0x597c5e697de7] mariadbd(_ZN30subselect_single_select_engine4execEv+0x149)[0x597c5ea21e09] mariadbd(_ZN24Item_singlerow_subselect7val_intEv+0x64)[0x597c5ea12bb4] mariadbd(_ZN14Arg_comparator18compare_int_signedEv+0x1d)[0x597c5e985d7d] mariadbd(_ZN12Item_func_eq8val_boolEv+0x2f)[0x597c5e986e0f] mariadbd(_ZN15Item_bool_func215remove_eq_condsEP3THDPN4Item11cond_resultEb+0x84)[0x597c5e6bba94] mariadbd(_ZN9Item_cond15remove_eq_condsEP3THDPN4Item11cond_resultEb+0x125)[0x597c5e6c43f5] mariadbd(+0x88dcdd)[0x597c5e6c3cdd] mariadbd(_ZN4JOIN14optimize_innerEv+0x5ca)[0x597c5e69f17a] mariadbd(_ZN4JOIN8optimizeEv+0x10a)[0x597c5e6a034a] mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xcf)[0x597c5e6a047f] mariadbd(_Z13handle_selectP3THDP3LEXP13select_resulty+0x17a)[0x597c5e6a0faa] mariadbd(+0x810ee1)[0x597c5e646ee1] mariadbd(_Z21mysql_execute_commandP3THDb+0x3868)[0x597c5e652ba8] mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x19a)[0x597c5e65ac2a] mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0xb08)[0x597c5e64c5f8] mariadbd(_Z10do_commandP3THDb+0x164)[0x597c5e64e1b4] mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x65b)[0x597c5e7dc8ab] mariadbd(handle_one_connection+0x71)[0x597c5e7dccf1] mariadbd(+0xd3ebde)[0x597c5eb74bde] /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4)[0x7b83b7724aa4] /lib/x86_64-linux-gnu/libc.so.6(__clone+0x44)[0x7b83b77b1a34] Connection ID (thread ID): 5 Status: NOT_KILLED Query (0x7b8338012f90): SELECT * FROM sometable WHERE something=1 AND (SELECT 1 FROM information_schema.users) = 1 -- Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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,hash_join_cardinality=on,cset_narrowing=on,sargable_casefold=on Writing a core file... Working directory at /var/lib/mysql Resource Limits (excludes unlimited resources): Limit Soft Limit Hard Limit Units Max stack size 8388608 unlimited bytes Max open files 32190 32190 files Max locked memory 8388608 8388608 bytes Max pending signals 92541 92541 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h Kernel version: Linux version 6.13.6-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Fri, 07 Mar 2025 20:19:00 +0000{noformat} |
| Status | Needs Feedback [ 10501 ] | Open [ 1 ] |
| Summary | MariaDB crashes when trying to access information_schema.users | MariaDB crashes when trying to access information_schema.users under --skip-grant-tables |
| Labels | crash |
| Component/s | Authentication and Privilege System [ 13101 ] | |
| Component/s | Information Schema [ 14413 ] |
| Fix Version/s | 11.8 [ 29921 ] |
| Assignee | Sergei Golubchik [ serg ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | In Testing [ 10301 ] |