Bug #99029 Assertion ".var->check.thd"
Submitted: 23 Mar 2020 8:53 Modified: 21 Sep 2022 13:58
Reporter: Hrvoje Matijakovic Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S6 (Debug Builds)
Version:8.0.19, 8.0.11 OS:Linux
Assigned to: CPU Architecture:x86

[23 Mar 2020 8:53] Hrvoje Matijakovic
Description:
Running the following query results in debug build. I couldn't reproduce it on release builds.

gdb from the debug build:
Core was generated by `/sdc/MS140120-mysql-8.0.19-linux-x86_64-debug/bin/mysqld --no-defaults --basedi'.
Program terminated with signal 6, Aborted.
#0  0x00007f38128b8a61 in __pthread_kill (threadid=<optimized out>, signo=6) at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:59
59        val = INTERNAL_SYSCALL (tgkill, err, 3, THREAD_GETMEM (THREAD_SELF, pid),
(gdb) bt
+bt
#0  0x00007f38128b8a61 in __pthread_kill (threadid=<optimized out>, signo=6) at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:59
#1  0x00000000049b4155 in my_write_core (sig=6) at /sdc/MS-8.0.19_dbg/mysys/stacktrace.cc:306
#2  0x0000000003689a58 in handle_fatal_signal (sig=6) at /sdc/MS-8.0.19_dbg/sql/signal_handler.cc:169
#3  <signal handler called>
#4  0x00007f3810700337 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
#5  0x00007f3810701a28 in __GI_abort () at abort.c:90
#6  0x00007f38106f9156 in __assert_fail_base (fmt=0x7f3810854be0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5e0e33b "!var->check(thd)", file=file@entry=0x5e0e2e8 "/sdc/MS-8.0.19_dbg/sql/opt_hints.cc", line=line@entry=676, function=function@entry=0x5e0ea80 <Sys_var_hint::restore_vars(THD*)::__PRETTY_FUNCTION__> "void Sys_var_hint::restore_vars(THD*)") at assert.c:92
#7  0x00007f38106f9202 in __GI___assert_fail (assertion=0x5e0e33b "!var->check(thd)", file=0x5e0e2e8 "/sdc/MS-8.0.19_dbg/sql/opt_hints.cc", line=676, function=0x5e0ea80 <Sys_var_hint::restore_vars(THD*)::__PRETTY_FUNCTION__> "void Sys_var_hint::restore_vars(THD*)") at assert.c:101
#8  0x0000000003a59dba in Sys_var_hint::restore_vars (this=0x7f37b5c63a18, thd=0x7f37b5c20000) at /sdc/MS-8.0.19_dbg/sql/opt_hints.cc:676
#9  0x00000000034ba6fa in mysql_execute_command (thd=0x7f37b5c20000, first_level=true) at /sdc/MS-8.0.19_dbg/sql/sql_parse.cc:4604
#10 0x00000000034bc78a in mysql_parse (thd=0x7f37b5c20000, parser_state=0x7f380f0a1ae0) at /sdc/MS-8.0.19_dbg/sql/sql_parse.cc:5288
#11 0x00000000034b1b6a in dispatch_command (thd=0x7f37b5c20000, com_data=0x7f380f0a2b90, command=COM_QUERY) at /sdc/MS-8.0.19_dbg/sql/sql_parse.cc:1777
#12 0x00000000034b0074 in do_command (thd=0x7f37b5c20000) at /sdc/MS-8.0.19_dbg/sql/sql_parse.cc:1275
#13 0x0000000003674649 in handle_connection (arg=0x7f37c0c733e0) at /sdc/MS-8.0.19_dbg/sql/conn_handler/connection_handler_per_thread.cc:302
#14 0x0000000005180948 in pfs_spawn_thread (arg=0x7f380e86d8a0) at /sdc/MS-8.0.19_dbg/storage/perfschema/pfs.cc:2854
#15 0x00007f38128b3e65 in start_thread (arg=0x7f380f0a3700) at pthread_create.c:307
#16 0x00007f38107c888d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

How to repeat:
# mysqld options required for replay:  --maximum-max_join_size=1M
CREATE DATABASE test;
USE test;
SET @@session.sql_mode=TRADITIONAL;
explain SELECT /*+ SET_VAR(max_join_size=1)SET_VAR(max_join_size=1) */ * FROM t1;
[24 Mar 2020 4:41] MySQL Verification Team
Hello Hrvoje Matijakovic,

Thank you for the bug report and test case.
Verified as described on 8.0.19 debug build.

regards,
Umesh
[21 Sep 2022 13:58] Jon Stephens
Documented fix in the MySQL 8.0.32 changelog as follows:

    When a mysqld startup option was used with the maximum- prefix,
    the upper bound for the corresponding system variable was set
    but its current value was not checked against or adjusted
    according to the new limit and thus could in some cases be
    greater than the stated maximum. We fix this by adjusting the
    current value if it is larger than the new user defined maximum
    value.

Closed.