Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
11.4
Description
The test is to be put into the galera suite, to pick up the config.
--source include/have_innodb.inc
|
|
|
call mtr.add_suppression("Inconsistency detected: Inconsistent by consensus"); |
SET lock_wait_timeout=0; |
|
|
SET wsrep_on=ON; |
|
|
CREATE TABLE t (a DATE) ENGINE=InnoDB; |
SET GLOBAL WSREP_IGNORE_APPLY_ERRORS= 0; |
--error ER_BAD_FIELD_ERROR
|
ALTER TABLE t MODIFY b INT; |
--error 0,ER_LOCK_WAIT_TIMEOUT
|
DELETE FROM mysql.wsrep_streaming_log; |
SET wsrep_on=OFF; |
|
|
DROP TABLE t; |
|
11.4 3a6af458e6149657c1e135af821a23a7c15c68f1 |
mariadbd: /data/bld/11.4-asan/sql/sql_select.cc:34235: virtual bool Sql_cmd_dml::prepare(THD*): Assertion `thd->is_error()' failed.
|
250127 3:41:44 [ERROR] /share8t/bld/11.4-asan/sql/mariadbd got signal 6 ;
|
|
|
#9 0x00007f3598853eb2 in __GI___assert_fail (assertion=0x55e56103b1a0 "thd->is_error()", file=0x55e5610268e0 "/data/bld/11.4-asan/sql/sql_select.cc", line=34235, function=0x55e56103b140 "virtual bool Sql_cmd_dml::prepare(THD*)") at ./assert/assert.c:101
|
#10 0x000055e55eeb3398 in Sql_cmd_dml::prepare (this=0x62d0003853d8, thd=0x62c000220218) at /data/bld/11.4-asan/sql/sql_select.cc:34235
|
#11 0x000055e55eeb34f0 in Sql_cmd_dml::execute (this=0x62d0003853d8, thd=0x62c000220218) at /data/bld/11.4-asan/sql/sql_select.cc:34277
|
#12 0x000055e55ecca108 in mysql_execute_command (thd=0x62c000220218, is_called_from_prepared_stmt=false) at /data/bld/11.4-asan/sql/sql_parse.cc:4425
|
#13 0x000055e55ece2430 in mysql_parse (thd=0x62c000220218, rawbuf=0x62d000384438 "DELETE FROM mysql.wsrep_streaming_log", length=37, parser_state=0x7f357ff50a90) at /data/bld/11.4-asan/sql/sql_parse.cc:7907
|
#14 0x000055e55ece11b2 in wsrep_mysql_parse (thd=0x62c000220218, rawbuf=0x62d000384438 "DELETE FROM mysql.wsrep_streaming_log", length=37, parser_state=0x7f357ff50a90) at /data/bld/11.4-asan/sql/sql_parse.cc:7717
|
#15 0x000055e55ecb9317 in dispatch_command (command=COM_QUERY, thd=0x62c000220218, packet=0x6290002e4219 "DELETE FROM mysql.wsrep_streaming_log", packet_length=37, blocking=true) at /data/bld/11.4-asan/sql/sql_parse.cc:1892
|
#16 0x000055e55ecb6198 in do_command (thd=0x62c000220218, blocking=true) at /data/bld/11.4-asan/sql/sql_parse.cc:1418
|
#17 0x000055e55f1975d9 in do_handle_one_connection (connect=0x60800001fab8, put_in_cache=true) at /data/bld/11.4-asan/sql/sql_connect.cc:1408
|
#18 0x000055e55f197138 in handle_one_connection (arg=0x60800001f938) at /data/bld/11.4-asan/sql/sql_connect.cc:1320
|
#19 0x000055e55fe137a8 in pfs_spawn_thread (arg=0x617000031798) at /data/bld/11.4-asan/storage/perfschema/pfs.cc:2201
|
#20 0x00007f35988a81c4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#21 0x00007f359892885c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
The failure started happening after this merge in 11.4:
commit 17f01186f5c34dd5d6a89248f666985f4f20e2aa
|
Merge: 437550b7cf8 28b29580828
|
Author: Marko Mäkelä
|
Date: Thu Jan 9 07:58:08 2025 +0200
|
|
|
Merge 10.11 into 11.4
|
Also reproducible on bb-11.4-release at the moment of reporting.
However it is not reproducible on 10.11 (not even on the top commit which was merged), and it's not a small merge, I can't guess which commit could have caused it.
I also can't say whether there is any problem on a non-debug build, as I don't really know what is the expected result here, I've just added expected errors and suppressions in the test as they happen now, to get to the assertion failure.
Attachments
Activity
sciascid janlindstrom Thanks, the fix has been merged with the main branch: https://github.com/MariaDB/server/commit/10fd2c207a8d79e038fba752a72129a3a0e94b6b
supposedly caused by
commit 75dd0246f8bAuthor: Daniele Sciascia <daniele.sciascia@galeracluster.com>Date: Wed Dec 11 17:35:53 2024 +0100Remove error handling from wsrep_sync_wait()Let the wsrep-lib error be set/overriden at the end ofdispatch_command().Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>because there are checks sometimes that if a function returns an error status, a my_error() was called. That is, the latter cannot be postponed to the end of dispatch_command()