MySQL Bugs: #114493: MYSQL SERVER Abort

Bug #114493	MYSQL SERVER Abort
Submitted:	27 Mar 2024 2:26	Modified:	1 Apr 2024 9:30
Reporter:	jingchen zhang	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: DML	Severity:	S6 (Debug Builds)
Version:	8.3.0-debug-asan	OS:	Ubuntu
Assigned to:		CPU Architecture:	x86

Description:
When I use USE test, MySQL aborts.

#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140736525088320) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140736525088320) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140736525088320, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff7507476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff74ed7f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff74ed71b in __assert_fail_base (fmt=0x7ffff76a2130 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x914db20 <str> "0",
    file=0x914b7c0 <str> "/home/mysql-server/sql/rpl_handler.cc", line=1477, function=<optimized out>) at ./assert/assert.c:92
#6  0x00007ffff74fee96 in __GI___assert_fail (assertion=0x914db20 <str> "0", file=0x914b7c0 <str> "/home/mysql-server/sql/rpl_handler.cc", line=1477,
    function=0x914d9a0 <__PRETTY_FUNCTION__._Z23launch_hook_trans_beginP3THDP9Table_ref> "int launch_hook_trans_begin(THD *, Table_ref *)")
    at ./assert/assert.c:101
#7  0x0000000005735e28 in launch_hook_trans_begin (thd=0x6270002e9900, all_tables=<optimized out>) at /home/mysql-server/sql/rpl_handler.cc:1477
#8  0x000000000343466a in mysql_execute_command (thd=0x6270002e9900, first_level=<optimized out>) at /home/mysql-server/sql/sql_parse.cc:3074
#9  0x0000000003430912 in dispatch_sql_command (thd=<optimized out>, parser_state=<optimized out>) at /home/mysql-server/sql/sql_parse.cc:5301
#10 0x000000000342a0fc in dispatch_command (thd=0x24f, com_data=<optimized out>, command=<optimized out>) at /home/mysql-server/sql/sql_parse.cc:2133
#11 0x000000000342e05e in do_command (thd=<optimized out>) at /home/mysql-server/sql/sql_parse.cc:1462
#12 0x000000000383bf14 in handle_connection (arg=<optimized out>, arg@entry=0x60300016e430)
    at /home/mysql-server/sql/conn_handler/connection_handler_per_thread.cc:303
#13 0x00000000074d07fe in pfs_spawn_thread (arg=0x614000142260) at /home/mysql-server/storage/perfschema/pfs.cc:3050
#14 0x00007ffff7559ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#15 0x00007ffff75eb850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

How to repeat:
mysql> SET @@SESSION.group_replication_consistency= BEFORE_ON_PRIMARY_FAILOVER;
Query OK, 0 rows affected (0.00 sec)

mysql>  SET @debug_save= @@GLOBAL.DEBUG;
Query OK, 0 rows affected (0.00 sec)

mysql>  SET @@GLOBAL.DEBUG= '+d,launch_hook_trans_begin_assert_if_hold';
Query OK, 0 rows affected (0.00 sec)

mysql>  USE test;
Database changed

Hello jingchen zhang,

Thank you for the report and test case.
Observed that 8.3.0 debug build is affected.

regards.
Umesh

--
mysqld-debug: ../../mysql-8.3.0/sql/rpl_handler.cc:1477: int launch_hook_trans_begin(THD*, Table_ref*): Assertion `0' failed.
2024-03-27T10:23:49Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=602a3d189b5c27b7bce27e91c90f0841e9e160b5
Thread pointer: 0x7f2bb0000da0
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 = 7f2c64271b58 thread_stack 0x100000
 #0 0x33be5d5 print_fatal_signal(int) at mysql-8.3.0/sql/signal_handler.cc:154
 #1 0x33be79f handle_fatal_signal at mysql-8.3.0/sql/signal_handler.cc:230
 #2 0x7f2c764e562f <unknown>
 #3 0x7f2c7482d387 <unknown>
 #4 0x7f2c7482ea77 <unknown>
 #5 0x7f2c748261a5 <unknown>
 #6 0x7f2c74826251 <unknown>
 #7 0x3ed02c8 launch_hook_trans_begin(THD*, Table_ref*) at mysql-8.3.0/sql/rpl_handler.cc:1477
 #8 0x323d0dc mysql_execute_command(THD*, bool) at mysql-8.3.0/sql/sql_parse.cc:3074
 #9 0x3241cbd dispatch_sql_command(THD*, Parser_state*) at mysql-8.3.0/sql/sql_parse.cc:5301
 #10 0x3243380 dispatch_command(THD*, COM_DATA const*, enum_server_command) at mysql-8.3.0/sql/sql_parse.cc:2133
 #11 0x324488d do_command(THD*) at mysql-8.3.0/sql/sql_parse.cc:1462
 #12 0x33b05e5 handle_connection at mysql-8.3.0/sql/conn_handler/connection_handler_per_thread.cc:303
 #13 0x49651f0 pfs_spawn_thread at mysql-8.3.0/storage/perfschema/pfs.cc:3050
 #14 0x7f2c764ddea4 <unknown>
 #15 0x7f2c748f5b2c <unknown>
 #16 0xffffffffffffffff <unknown>

Posted by developer:
 
The debug point 'launch_hook_trans_begin_assert_if_hold' is used to validate that some statements are not hold when consistency guarantees are used.
We can see that list at https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-consistency-guarante...
We can see the debug point being used on the test `gr_primary_failover_consistency_cmd_not_hold.test`.

The bug reporter is using the debug point on opposite scenario, when a statement that is hold, thence the assert triggers as expected.