Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order
--list-combinations shows the list of existing combinations for the specified test with easily selectable form like this:
$ mtr --list-combinations versioning.foreign
|
Combinations for versioning.foreign: timestamp,trx_id
|
versioning.foreign,timestamp
|
versioning.foreign,trx_id
|
More options to consider
Don't print hints:
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.
|
...
|
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 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.
|
...
|
Output from gdb follows. The first stack trace is from the failing thread.
|
The following stack traces are from all threads (so the failing one is
|
duplicated).
|
Don't print resource limits:
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 unlimited unlimited bytes
|
Max resident set unlimited unlimited bytes
|
Max processes 127927 127927 processes
|
Max open files 1024 1024 files
|
Max locked memory 4200996864 4200996864 bytes
|
Max address space unlimited unlimited bytes
|
Max file locks unlimited unlimited locks
|
Max pending signals 127927 127927 signals
|
Max msgqueue size 819200 819200 bytes
|
Max nice priority 0 0
|
Max realtime priority 0 0
|
Max realtime timeout unlimited unlimited us
|
Don't print non-debugger backtrace:
Thread pointer: 0x7eff34000d58
|
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 = 0x7eff6008fcd0 thread_stack 0x49000
|
addr2line: DWARF error: invalid or unhandled FORM value: 0x23
|
??:0(my_print_stacktrace)[0x560cd7865c44]
|
??:0(handle_fatal_signal)[0x560cd6f37cf0]
|
libc_sigaction.c:0(__restore_rt)[0x7eff66cf2d30]
|
nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7eff66d4914b]
|
posix/raise.c:27(__GI_raise)[0x7eff66cf2c86]
|
stdlib/abort.c:81(__GI_abort)[0x7eff66cd97fc]
|
intl/loadmsgcat.c:1177(_nl_load_domain)[0x7eff66cd971b]
|
:0(__GI___assert_fail)[0x7eff66cea5d6]
|
addr2line: DWARF error: invalid or unhandled FORM value: 0x23
|
??:0(Alter_table_ctx::fk_handle_alter(THD*))[0x560cd6c5527c]
|
??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_
|
st*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x560cd6c48904]
|
??:0(Sql_cmd_alter_table::execute(THD*))[0x560cd6d339c7]
|
??:0(mysql_execute_command(THD*, bool))[0x560cd6b1e96d]
|
??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560cd6b0fa9f]
|
??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560cd6b0cd8f]
|
??:0(do_command(THD*, bool))[0x560cd6b105ee]
|
??:0(do_handle_one_connection(CONNECT*, bool))[0x560cd6d27b88]
|
??:0(handle_one_connection)[0x560cd6d277fa]
|
:0(pfs_spawn_thread)[0x560cd72a305f]
|
nptl/pthread_create.c:442(start_thread)[0x7eff66d472e2]
|
x86_64/clone3.S:83(__clone3)[0x7eff66dd6240]
|
Besides the option non-debugger backtrace should not be printed if debugger backtrace was successfully printed.
The above options should be accumulated into one option --quiet-devel (or something like this).
Attachments
Issue Links
- relates to
-
-
- Stalled
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order --list-combinations shows the list of existing combinations for the specified test with easily selectable form like this: {noformat} $ mtr --list-combinations versioning.foreign Combinations for versioning.foreign: timestamp,trx_id versioning.foreign,timestamp versioning.foreign,trx_id {noformat} |
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order --list-combinations shows the list of existing combinations for the specified test with easily selectable form like this: {noformat} $ mtr --list-combinations versioning.foreign Combinations for versioning.foreign: timestamp,trx_id versioning.foreign,timestamp versioning.foreign,trx_id {noformat} h3. More options to consider: h4. Don't print hints: {noformat} 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. ... 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 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. ... Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). {noformat} h4. Don't print resource limits: {noformat} 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 unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 127927 127927 processes Max open files 1024 1024 files Max locked memory 4200996864 4200996864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 127927 127927 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us {noformat} h4. Don't print non-debugger backtrace {noformat} Thread pointer: 0x7eff34000d58 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 = 0x7eff6008fcd0 thread_stack 0x49000 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(my_print_stacktrace)[0x560cd7865c44] ??:0(handle_fatal_signal)[0x560cd6f37cf0] libc_sigaction.c:0(__restore_rt)[0x7eff66cf2d30] nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7eff66d4914b] posix/raise.c:27(__GI_raise)[0x7eff66cf2c86] stdlib/abort.c:81(__GI_abort)[0x7eff66cd97fc] intl/loadmsgcat.c:1177(_nl_load_domain)[0x7eff66cd971b] :0(__GI___assert_fail)[0x7eff66cea5d6] addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(Alter_table_ctx::fk_handle_alter(THD*))[0x560cd6c5527c] ??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_ st*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x560cd6c48904] ??:0(Sql_cmd_alter_table::execute(THD*))[0x560cd6d339c7] ??:0(mysql_execute_command(THD*, bool))[0x560cd6b1e96d] ??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560cd6b0fa9f] ??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560cd6b0cd8f] ??:0(do_command(THD*, bool))[0x560cd6b105ee] ??:0(do_handle_one_connection(CONNECT*, bool))[0x560cd6d27b88] ??:0(handle_one_connection)[0x560cd6d277fa] :0(pfs_spawn_thread)[0x560cd72a305f] nptl/pthread_create.c:442(start_thread)[0x7eff66d472e2] x86_64/clone3.S:83(__clone3)[0x7eff66dd6240] {noformat} The above options should be accumulated into one option --quiet-devel (or something like this). |
| Description |
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order --list-combinations shows the list of existing combinations for the specified test with easily selectable form like this: {noformat} $ mtr --list-combinations versioning.foreign Combinations for versioning.foreign: timestamp,trx_id versioning.foreign,timestamp versioning.foreign,trx_id {noformat} h3. More options to consider: h4. Don't print hints: {noformat} 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. ... 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 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. ... Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). {noformat} h4. Don't print resource limits: {noformat} 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 unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 127927 127927 processes Max open files 1024 1024 files Max locked memory 4200996864 4200996864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 127927 127927 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us {noformat} h4. Don't print non-debugger backtrace {noformat} Thread pointer: 0x7eff34000d58 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 = 0x7eff6008fcd0 thread_stack 0x49000 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(my_print_stacktrace)[0x560cd7865c44] ??:0(handle_fatal_signal)[0x560cd6f37cf0] libc_sigaction.c:0(__restore_rt)[0x7eff66cf2d30] nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7eff66d4914b] posix/raise.c:27(__GI_raise)[0x7eff66cf2c86] stdlib/abort.c:81(__GI_abort)[0x7eff66cd97fc] intl/loadmsgcat.c:1177(_nl_load_domain)[0x7eff66cd971b] :0(__GI___assert_fail)[0x7eff66cea5d6] addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(Alter_table_ctx::fk_handle_alter(THD*))[0x560cd6c5527c] ??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_ st*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x560cd6c48904] ??:0(Sql_cmd_alter_table::execute(THD*))[0x560cd6d339c7] ??:0(mysql_execute_command(THD*, bool))[0x560cd6b1e96d] ??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560cd6b0fa9f] ??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560cd6b0cd8f] ??:0(do_command(THD*, bool))[0x560cd6b105ee] ??:0(do_handle_one_connection(CONNECT*, bool))[0x560cd6d27b88] ??:0(handle_one_connection)[0x560cd6d277fa] :0(pfs_spawn_thread)[0x560cd72a305f] nptl/pthread_create.c:442(start_thread)[0x7eff66d472e2] x86_64/clone3.S:83(__clone3)[0x7eff66dd6240] {noformat} The above options should be accumulated into one option --quiet-devel (or something like this). |
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order --list-combinations shows the list of existing combinations for the specified test with easily selectable form like this: {noformat} $ mtr --list-combinations versioning.foreign Combinations for versioning.foreign: timestamp,trx_id versioning.foreign,timestamp versioning.foreign,trx_id {noformat} h3. More options to consider h4. Don't print hints: {noformat} 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. ... 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 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. ... Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). {noformat} h4. Don't print resource limits: {noformat} 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 unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 127927 127927 processes Max open files 1024 1024 files Max locked memory 4200996864 4200996864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 127927 127927 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us {noformat} h4. Don't print non-debugger backtrace {noformat} Thread pointer: 0x7eff34000d58 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 = 0x7eff6008fcd0 thread_stack 0x49000 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(my_print_stacktrace)[0x560cd7865c44] ??:0(handle_fatal_signal)[0x560cd6f37cf0] libc_sigaction.c:0(__restore_rt)[0x7eff66cf2d30] nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7eff66d4914b] posix/raise.c:27(__GI_raise)[0x7eff66cf2c86] stdlib/abort.c:81(__GI_abort)[0x7eff66cd97fc] intl/loadmsgcat.c:1177(_nl_load_domain)[0x7eff66cd971b] :0(__GI___assert_fail)[0x7eff66cea5d6] addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(Alter_table_ctx::fk_handle_alter(THD*))[0x560cd6c5527c] ??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_ st*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x560cd6c48904] ??:0(Sql_cmd_alter_table::execute(THD*))[0x560cd6d339c7] ??:0(mysql_execute_command(THD*, bool))[0x560cd6b1e96d] ??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560cd6b0fa9f] ??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560cd6b0cd8f] ??:0(do_command(THD*, bool))[0x560cd6b105ee] ??:0(do_handle_one_connection(CONNECT*, bool))[0x560cd6d27b88] ??:0(handle_one_connection)[0x560cd6d277fa] :0(pfs_spawn_thread)[0x560cd72a305f] nptl/pthread_create.c:442(start_thread)[0x7eff66d472e2] x86_64/clone3.S:83(__clone3)[0x7eff66dd6240] {noformat} The above options should be accumulated into one option --quiet-devel (or something like this). |
| Description |
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order --list-combinations shows the list of existing combinations for the specified test with easily selectable form like this: {noformat} $ mtr --list-combinations versioning.foreign Combinations for versioning.foreign: timestamp,trx_id versioning.foreign,timestamp versioning.foreign,trx_id {noformat} h3. More options to consider h4. Don't print hints: {noformat} 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. ... 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 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. ... Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). {noformat} h4. Don't print resource limits: {noformat} 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 unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 127927 127927 processes Max open files 1024 1024 files Max locked memory 4200996864 4200996864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 127927 127927 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us {noformat} h4. Don't print non-debugger backtrace {noformat} Thread pointer: 0x7eff34000d58 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 = 0x7eff6008fcd0 thread_stack 0x49000 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(my_print_stacktrace)[0x560cd7865c44] ??:0(handle_fatal_signal)[0x560cd6f37cf0] libc_sigaction.c:0(__restore_rt)[0x7eff66cf2d30] nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7eff66d4914b] posix/raise.c:27(__GI_raise)[0x7eff66cf2c86] stdlib/abort.c:81(__GI_abort)[0x7eff66cd97fc] intl/loadmsgcat.c:1177(_nl_load_domain)[0x7eff66cd971b] :0(__GI___assert_fail)[0x7eff66cea5d6] addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(Alter_table_ctx::fk_handle_alter(THD*))[0x560cd6c5527c] ??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_ st*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x560cd6c48904] ??:0(Sql_cmd_alter_table::execute(THD*))[0x560cd6d339c7] ??:0(mysql_execute_command(THD*, bool))[0x560cd6b1e96d] ??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560cd6b0fa9f] ??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560cd6b0cd8f] ??:0(do_command(THD*, bool))[0x560cd6b105ee] ??:0(do_handle_one_connection(CONNECT*, bool))[0x560cd6d27b88] ??:0(handle_one_connection)[0x560cd6d277fa] :0(pfs_spawn_thread)[0x560cd72a305f] nptl/pthread_create.c:442(start_thread)[0x7eff66d472e2] x86_64/clone3.S:83(__clone3)[0x7eff66dd6240] {noformat} The above options should be accumulated into one option --quiet-devel (or something like this). |
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order --list-combinations shows the list of existing combinations for the specified test with easily selectable form like this: {noformat} $ mtr --list-combinations versioning.foreign Combinations for versioning.foreign: timestamp,trx_id versioning.foreign,timestamp versioning.foreign,trx_id {noformat} h3. More options to consider h4. Don't print hints: {noformat} 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. ... 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 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. ... Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). {noformat} h4. Don't print resource limits: {noformat} 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 unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 127927 127927 processes Max open files 1024 1024 files Max locked memory 4200996864 4200996864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 127927 127927 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us {noformat} h4. Don't print non-debugger backtrace: {noformat} Thread pointer: 0x7eff34000d58 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 = 0x7eff6008fcd0 thread_stack 0x49000 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(my_print_stacktrace)[0x560cd7865c44] ??:0(handle_fatal_signal)[0x560cd6f37cf0] libc_sigaction.c:0(__restore_rt)[0x7eff66cf2d30] nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7eff66d4914b] posix/raise.c:27(__GI_raise)[0x7eff66cf2c86] stdlib/abort.c:81(__GI_abort)[0x7eff66cd97fc] intl/loadmsgcat.c:1177(_nl_load_domain)[0x7eff66cd971b] :0(__GI___assert_fail)[0x7eff66cea5d6] addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(Alter_table_ctx::fk_handle_alter(THD*))[0x560cd6c5527c] ??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_ st*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x560cd6c48904] ??:0(Sql_cmd_alter_table::execute(THD*))[0x560cd6d339c7] ??:0(mysql_execute_command(THD*, bool))[0x560cd6b1e96d] ??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560cd6b0fa9f] ??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560cd6b0cd8f] ??:0(do_command(THD*, bool))[0x560cd6b105ee] ??:0(do_handle_one_connection(CONNECT*, bool))[0x560cd6d27b88] ??:0(handle_one_connection)[0x560cd6d277fa] :0(pfs_spawn_thread)[0x560cd72a305f] nptl/pthread_create.c:442(start_thread)[0x7eff66d472e2] x86_64/clone3.S:83(__clone3)[0x7eff66dd6240] {noformat} The above options should be accumulated into one option --quiet-devel (or something like this). |
| Description |
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order --list-combinations shows the list of existing combinations for the specified test with easily selectable form like this: {noformat} $ mtr --list-combinations versioning.foreign Combinations for versioning.foreign: timestamp,trx_id versioning.foreign,timestamp versioning.foreign,trx_id {noformat} h3. More options to consider h4. Don't print hints: {noformat} 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. ... 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 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. ... Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). {noformat} h4. Don't print resource limits: {noformat} 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 unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 127927 127927 processes Max open files 1024 1024 files Max locked memory 4200996864 4200996864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 127927 127927 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us {noformat} h4. Don't print non-debugger backtrace: {noformat} Thread pointer: 0x7eff34000d58 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 = 0x7eff6008fcd0 thread_stack 0x49000 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(my_print_stacktrace)[0x560cd7865c44] ??:0(handle_fatal_signal)[0x560cd6f37cf0] libc_sigaction.c:0(__restore_rt)[0x7eff66cf2d30] nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7eff66d4914b] posix/raise.c:27(__GI_raise)[0x7eff66cf2c86] stdlib/abort.c:81(__GI_abort)[0x7eff66cd97fc] intl/loadmsgcat.c:1177(_nl_load_domain)[0x7eff66cd971b] :0(__GI___assert_fail)[0x7eff66cea5d6] addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(Alter_table_ctx::fk_handle_alter(THD*))[0x560cd6c5527c] ??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_ st*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x560cd6c48904] ??:0(Sql_cmd_alter_table::execute(THD*))[0x560cd6d339c7] ??:0(mysql_execute_command(THD*, bool))[0x560cd6b1e96d] ??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560cd6b0fa9f] ??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560cd6b0cd8f] ??:0(do_command(THD*, bool))[0x560cd6b105ee] ??:0(do_handle_one_connection(CONNECT*, bool))[0x560cd6d27b88] ??:0(handle_one_connection)[0x560cd6d277fa] :0(pfs_spawn_thread)[0x560cd72a305f] nptl/pthread_create.c:442(start_thread)[0x7eff66d472e2] x86_64/clone3.S:83(__clone3)[0x7eff66dd6240] {noformat} The above options should be accumulated into one option --quiet-devel (or something like this). |
When debugging often it doesn't matter on what combination bug reproduces and you don't need to run test with all the combinations. So currently you have to know how combinations are named and explicitly specify one.
--one-combination option selects first combination for the test in alphabetical order --list-combinations shows the list of existing combinations for the specified test with easily selectable form like this: {noformat} $ mtr --list-combinations versioning.foreign Combinations for versioning.foreign: timestamp,trx_id versioning.foreign,timestamp versioning.foreign,trx_id {noformat} h3. More options to consider h4. Don't print hints: {noformat} 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. ... 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 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. ... Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). {noformat} h4. Don't print resource limits: {noformat} 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 unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 127927 127927 processes Max open files 1024 1024 files Max locked memory 4200996864 4200996864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 127927 127927 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us {noformat} h4. Don't print non-debugger backtrace: {noformat} Thread pointer: 0x7eff34000d58 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 = 0x7eff6008fcd0 thread_stack 0x49000 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(my_print_stacktrace)[0x560cd7865c44] ??:0(handle_fatal_signal)[0x560cd6f37cf0] libc_sigaction.c:0(__restore_rt)[0x7eff66cf2d30] nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7eff66d4914b] posix/raise.c:27(__GI_raise)[0x7eff66cf2c86] stdlib/abort.c:81(__GI_abort)[0x7eff66cd97fc] intl/loadmsgcat.c:1177(_nl_load_domain)[0x7eff66cd971b] :0(__GI___assert_fail)[0x7eff66cea5d6] addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0(Alter_table_ctx::fk_handle_alter(THD*))[0x560cd6c5527c] ??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, Table_specification_ st*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x560cd6c48904] ??:0(Sql_cmd_alter_table::execute(THD*))[0x560cd6d339c7] ??:0(mysql_execute_command(THD*, bool))[0x560cd6b1e96d] ??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560cd6b0fa9f] ??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560cd6b0cd8f] ??:0(do_command(THD*, bool))[0x560cd6b105ee] ??:0(do_handle_one_connection(CONNECT*, bool))[0x560cd6d27b88] ??:0(handle_one_connection)[0x560cd6d277fa] :0(pfs_spawn_thread)[0x560cd72a305f] nptl/pthread_create.c:442(start_thread)[0x7eff66d472e2] x86_64/clone3.S:83(__clone3)[0x7eff66dd6240] {noformat} Besides the option non-debugger backtrace should not be printed if debugger backtrace was successfully printed. The above options should be accumulated into one option --quiet-devel (or something like this). |
| Comment |
[ For --parallel don't print this at the default verbosity level :
{code} worker[5] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 worker[4] Using MTR_BUILD_THREAD 301, with reserved ports 16020..16039 worker[1] Using MTR_BUILD_THREAD 302, with reserved ports 16040..16059 worker[3] Using MTR_BUILD_THREAD 304, with reserved ports 16080..16099 worker[2] Using MTR_BUILD_THREAD 303, with reserved ports 16060..16079 worker[7] Using MTR_BUILD_THREAD 305, with reserved ports 16100..16119 worker[6] Using MTR_BUILD_THREAD 306, with reserved ports 16120..16139 worker[9] Using MTR_BUILD_THREAD 307, with reserved ports 16140..16159 worker[17] Using MTR_BUILD_THREAD 308, with reserved ports 16160..16179 worker[8] Using MTR_BUILD_THREAD 309, with reserved ports 16180..16199 worker[18] Using MTR_BUILD_THREAD 310, with reserved ports 16200..16219 worker[11] Using MTR_BUILD_THREAD 311, with reserved ports 16220..16239 worker[13] Using MTR_BUILD_THREAD 312, with reserved ports 16240..16259 worker[10] Using MTR_BUILD_THREAD 313, with reserved ports 16260..16279 worker[16] Using MTR_BUILD_THREAD 314, with reserved ports 16280..16299 worker[15] Using MTR_BUILD_THREAD 315, with reserved ports 16300..16319 worker[19] Using MTR_BUILD_THREAD 317, with reserved ports 16340..16359 worker[20] Using MTR_BUILD_THREAD 316, with reserved ports 16320..16339 worker[12] Using MTR_BUILD_THREAD 318, with reserved ports 16360..16379 worker[22] Using MTR_BUILD_THREAD 319, with reserved ports 16380..16399 worker[23] Using MTR_BUILD_THREAD 321, with reserved ports 16420..16439 worker[21] Using MTR_BUILD_THREAD 320, with reserved ports 16400..16419 worker[14] Using MTR_BUILD_THREAD 322, with reserved ports 16440..16459 worker[24] Using MTR_BUILD_THREAD 323, with reserved ports 16460..16479 worker[26] Using MTR_BUILD_THREAD 325, with reserved ports 16500..16519 worker[25] Using MTR_BUILD_THREAD 324, with reserved ports 16480..16499 worker[27] Using MTR_BUILD_THREAD 326, with reserved ports 16520..16539 worker[30] Using MTR_BUILD_THREAD 328, with reserved ports 16560..16579 worker[28] Using MTR_BUILD_THREAD 327, with reserved ports 16540..16559 worker[33] Using MTR_BUILD_THREAD 329, with reserved ports 16580..16599 worker[29] Using MTR_BUILD_THREAD 330, with reserved ports 16600..16619 worker[36] Using MTR_BUILD_THREAD 333, with reserved ports 16660..16679 worker[32] Using MTR_BUILD_THREAD 331, with reserved ports 16620..16639 worker[31] Using MTR_BUILD_THREAD 332, with reserved ports 16640..16659 worker[34] Using MTR_BUILD_THREAD 334, with reserved ports 16680..16699 worker[35] Using MTR_BUILD_THREAD 335, with reserved ports 16700..16719 {code} ] |
| Fix Version/s | 10.4 [ 22408 ] | |
| Fix Version/s | 10.3 [ 22126 ] |
| Link | This issue relates to MDEV-30281 [ MDEV-30281 ] |