Details
-
Bug
-
Status: Stalled (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 13.0, 13.1, 13.2
-
Debug builds only
-
Unexpected results
-
Q1/2027 Replic. Maintenance
Description
CHANGE MASTER TO master_host='not important'; |
SET GLOBAL log_slow_verbosity='warning'; |
SET GLOBAL init_slave='garbage'; |
SET GLOBAL long_query_time=0; |
SET GLOBAL slow_query_log=1; |
START SLAVE SQL_THREAD;
|
|
CS 12.3.2 66b3c6784689fbb65110a5b21efcb815a8bcde24 (Debug, MSAN, Clang 20.1.8-20250708) Build 03/06/2026 |
==1558226==WARNING: MemorySanitizer: use-of-uninitialized-value
|
#0 0x5555572276ec in MYSQL_QUERY_LOG::write(THD*, long, char const*, unsigned long, unsigned long long, unsigned long long, bool, char const*, unsigned long) /test/12.3/sql/log.cc:4227:60
|
#1 0x555557224c7b in Log_to_file_event_handler::log_slow(THD*, my_hrtime_t, char const*, unsigned long, unsigned long long, unsigned long long, bool, char const*, unsigned long) /test/12.3/sql/log.cc:1369:31
|
#2 0x55555722a7d1 in LOGGER::slow_log_print(THD*, char const*, unsigned long, unsigned long long) /test/12.3/sql/log.cc:1646:36
|
#3 0x555556382208 in log_slow_statement(THD*) /test/12.3/sql/sql_parse.cc:2615:5
|
#4 0x555556375bab in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /test/12.3/sql/sql_parse.cc:2475:5
|
#5 0x55555636f5e8 in execute_init_command(THD*, st_mysql_lex_string*, st_mysql_rwlock*) /test/12.3/sql/sql_parse.cc:972:3
|
#6 0x55555608015a in handle_slave_sql /test/12.3/sql/slave.cc:5425:5
|
#7 0x5555576e60b7 in pfs_spawn_thread /test/12.3/storage/perfschema/pfs.cc:2198:3
|
#8 0x7fffe669caa3 in start_thread nptl/pthread_create.c:447:8
|
#9 0x7fffe6729c6b in clone3 misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
|
Likely Cause
- A few Diagnostics_area properties, namely m_statement_warn_count for this case, are neither zero-initialized nor reset to zero in Debug builds.
This is still safe, though, as long as they are set during runtime before use; e.g. – - – A user thread sets some of them to 0 (via set_ok_status()) after successfully connecting a user; a replication SQL thread was not instructed to set it, however.
- A failed statement does not update those (via set_ok_status() or set_eof_status()) either.
- The Slow Query Log checks whether there are warnings to log via m_statement_warn_count (through Diagnostics_area::unsafe_statement_warn_count().
Consequently, the Slow Query Log reads an unconfigured m_statement_warn_count when an SQL thread fails on its first statement (from the @@init_slave script or actual replication).
Attachments
Issue Links
- is caused by
-
MDEV-32203 Raise notes when an index cannot be used on data type mismatch
-
- Closed
-
- relates to
-
MDEV-34718 Trigger doesn't work correctly with bulk update
-
- Closed
-
- split to
-
MDEV-41474 `@@log_slow_verbosity='errors'` to Log Errors to Slow Query Log
-
- Open
-