Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL)
Description
Elkin reported the following crash in a debug build:
|
mariadb-10.6.14 with some changes |
#0 __GI_raise (sig=sig@entry=6) at raise.c:51
|
#1 0x00007ffff4b467f1 in __GI_abort () at abort.c:79
|
#2 0x00007ffff4b363fa in __assert_fail_base (fmt=0x7ffff4cbd6c0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x555556fff6d9 "w == MAYBE_NOP", file=file@entry=0x555556ffb7a0 "/home2/me/MEP/WTs/10.6/A0/storage/innobase/include/mtr0log.h", line=line@entry=503, function=function@entry=0x555556fff978 "void mtr_t::memcpy(const buf_block_t&, void*, const void*, ulint) [with mtr_t::write_type w = mtr_t::NORMAL; ulint = long unsigned int]") at assert.c:92
|
#3 0x00007ffff4b36472 in __GI___assert_fail (assertion=0x555556fff6d9 "w == MAYBE_NOP", file=0x555556ffb7a0 "/home2/me/MEP/WTs/10.6/A0/storage/innobase/include/mtr0log.h", line=503, function=0x555556fff978 "void mtr_t::memcpy(const buf_block_t&, void*, const void*, ulint) [with mtr_t::write_type w = mtr_t::NORMAL; ulint = long unsigned int]") at assert.c:101
|
#4 0x0000555556803e64 in mtr_t::memcpy<(mtr_t::write_type)0> (this=0x7fffe8c704a0, b=..., dest=0x7fffea32d3f5, str=0x7fffb403d928, len=2) at mtr0log.h:503
|
#5 0x000055555694a218 in trx_undo_write_xid (block=0x7fffe9c74bc0, offset=5051, xid=..., mtr=0x7fffe8c704a0) at trx0undo.cc:642
|
#6 0x000055555694ceed in trx_undo_set_state_at_prepare (trx=0x7fffeac72980, undo=0x7fffb403d8f8, rollback=false, mtr=0x7fffe8c704a0) at trx0undo.cc:1539
|
#7 0x000055555693f653 in trx_prepare_low (trx=0x7fffeac72980) at trx0trx.cc:1848
|
#8 0x000055555693f788 in trx_prepare (trx=0x7fffeac72980) at trx0trx.cc:1869
|
#9 0x000055555693f9a7 in trx_prepare_for_mysql (trx=0x7fffeac72980) at trx0trx.cc:1922
|
#10 0x00005555566e6d69 in innobase_xa_prepare (hton=0x55555859d768, thd=0x7fffb0016c08, prepare_trx=true) at ha_innodb.cc:17061
|
#11 0x00005555562a6d6f in prepare_or_error (ht=0x55555859d768, thd=0x7fffb0016c08, all=true) at handler.cc:1458
|
#12 0x00005555562a6f38 in ha_prepare (thd=0x7fffb0016c08) at handler.cc:1504
|
#13 0x00005555561d4b7d in trans_xa_prepare (thd=0x7fffb0016c08) at xa.cc:547
|
#14 0x0000555555eec1ee in mysql_execute_command (thd=0x7fffb0016c08, is_called_from_prepared_stmt=false) at sql_parse.cc:5874
|
#15 0x0000555555ef2e37 in mysql_parse (thd=0x7fffb0016c08, rawbuf=0x7fffb0025a10 "XA PREPARE '9','5',1", length=20, parser_state=0x7fffe8c71310) at sql_parse.cc:8063
|
I believe that the reason for this is that an identical XA PREPARE statement had been executed in the past.
This bug does not have any impact on release builds. The purpose of the debug assertion is to catch redundant calls for writing redo log for something that did not actually change.
Like the debug assertion expression suggests, this can be silenced by passing the appropriate template parameter.
Attachments
Issue Links
- relates to
-
MDEV-12353 Efficient InnoDB redo log record format
-
- Closed
-