Bug #91310 | Crash related to sql_print_information / acl_authenticate | ||
---|---|---|---|
Submitted: | 19 Jun 2018 6:34 | Modified: | 21 Jun 2018 16:20 |
Reporter: | Daniël van Eeden (OCA) | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server: Connection Handling | Severity: | S3 (Non-critical) |
Version: | 5.7.22 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[19 Jun 2018 6:34]
Daniël van Eeden
[19 Jun 2018 7:40]
MySQL Verification Team
IS this a self-built binary? Can you check stack like this; addr2line --demangle --inlines --pretty-print --addresses --basenames --functions --exe=/usr/sbin/mysqld 0xeed26b 0x79f2c1 0xc04590 0xc08e95 0x7a9fc5 0xc7ca1d 0xc7da68 0xd80ab3 0x1263904
[20 Jun 2018 6:33]
Daniël van Eeden
$ addr2line --demangle --inlines --pretty-print --addresses --basenames --functions --exe=/usr/sbin/mysqld 0xeed26b 0x79f2c1 0xc04590 0xc08e95 0x7a9fc5 0xc7ca1d 0xc7da68 0xd80ab3 0x1263904 0x0000000000eed26b: my_print_stacktrace at stacktrace.c:227 0x000000000079f2c1: handle_fatal_signal at signal_handler.cc:150 (discriminator 3) 0x0000000000c04590: error_log_print(loglevel, char const*, __va_list_tag*) [clone .part.131] at log.cc:2100 (inlined by) error_log_print at log.cc:2118 0x0000000000c08e95: sql_print_information(char const*, ...) at log.cc:2171 0x00000000007a9fc5: acl_authenticate(THD*, enum_server_command) at sql_authentication.cc:2544 0x0000000000c7ca1d: check_connection(THD*) at sql_connect.cc:686 0x0000000000c7da68: thd_prepare_connection(THD*) at sql_connect.cc:741 (inlined by) thd_prepare_connection(THD*) at sql_connect.cc:892 0x0000000000d80ab3: handle_connection at connection_handler_per_thread.cc:294 0x0000000001263904: pfs_spawn_thread at pfs.cc:2193 The binary is a re-build RPM with no code changes, but with OpenSSL instead of YaSSL
[21 Jun 2018 8:22]
MySQL Verification Team
Hm, line 2544 seems off. We'll need to get the disassembly from your mysqld binary at and around address 0x00000000007a9fc5 gdb /usr/sbin/mysqld disas 0x00000000007a9fc5
[21 Jun 2018 11:51]
Daniël van Eeden
gdb disas output
Attachment: 91310_disas_0x00000000007a9fc5.txt (text/plain), 71.35 KiB.
[21 Jun 2018 11:53]
Daniël van Eeden
0x00000000007a9fc0 <+2848>: callq 0x7a6980 <login_failed_error(int, MPVIO_EXT*, MPVIO_EXT*)> 0x00000000007a9fc5 <+2853>: mov %r13,%rdi
[21 Jun 2018 16:20]
MySQL Verification Team
So it was one of the two sql_print_information calls from this login_failed_error function that crashed... But I am unable to guess why. Say the mpvio->auth_info struct was broken/corrupted, then the previous calls to my_error would have crashed first?! A core file would be nice to have. /** a helper function to report an access denied error in all the proper places */ static void login_failed_error(MPVIO_EXT *mpvio, int passwd_used) { THD *thd= current_thd; if (passwd_used == 2) { my_error(ER_ACCESS_DENIED_NO_PASSWORD_ERROR, MYF(0), mpvio->auth_info.user_name, mpvio->auth_info.host_or_ip); query_logger.general_log_print(thd, COM_CONNECT, ER(ER_ACCESS_DENIED_NO_PASSWORD_ERROR), mpvio->auth_info.user_name, mpvio->auth_info.host_or_ip); /* Log access denied messages to the error log when log-warnings = 2 so that the overhead of the general query log is not required to track failed connections. */ sql_print_information(ER(ER_ACCESS_DENIED_NO_PASSWORD_ERROR), mpvio->auth_info.user_name, mpvio->auth_info.host_or_ip); } else { my_error(ER_ACCESS_DENIED_ERROR, MYF(0), mpvio->auth_info.user_name, mpvio->auth_info.host_or_ip, passwd_used ? ER(ER_YES) : ER(ER_NO)); query_logger.general_log_print(thd, COM_CONNECT, ER(ER_ACCESS_DENIED_ERROR), mpvio->auth_info.user_name, mpvio->auth_info.host_or_ip, passwd_used ? ER(ER_YES) : ER(ER_NO)); /* Log access denied messages to the error log when log-warnings = 2 so that the overhead of the general query log is not required to track failed connections. */ sql_print_information(ER(ER_ACCESS_DENIED_ERROR), mpvio->auth_info.user_name, mpvio->auth_info.host_or_ip, passwd_used ? ER(ER_YES) : ER(ER_NO)); } }