Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
11.4, 11.8, 12.3
Description
The test innodb.undo_leak_fail occasionally fails on my system like this:
|
11.4 b07a36ee329569b9b2a4b373a1b16fe2dc3ed32a |
CURRENT_TEST: innodb.undo_leak_fail
|
--- /mariadb/server/mysql-test/suite/innodb/r/undo_leak_fail.result 2026-02-02 16:18:12.970590869 +0200
|
+++ /mariadb/server/mysql-test/suite/innodb/r/undo_leak_fail.reject 2026-03-24 11:38:47.046311159 +0200
|
@@ -75,7 +75,7 @@
|
# restart: --debug_dbug=d,unused_undo_free_fail_5
|
SELECT IF(file_size>10485760,'ok',file_size) FROM information_schema.innodb_sys_tablespaces WHERE space=0;
|
IF(file_size>10485760,'ok',file_size)
|
-ok
|
+10485760
|
FOUND 1 /InnoDB: :autoshrink failed to free the segment .* in page .*/ in mysqld.1.err
|
SET GLOBAL innodb_fast_shutdown= 0;
|
# restart
|
|
|
Result length mismatch
|
I was able to reproduce this as follows:
while mysql-test/mtr --parallel=auto --mysqld=--skip-innodb-use-native-aio --rr=-h innodb.undo_leak_fail{,,,,,,}; do :; done |
For the failure of worker 2 that I got, I analyzed the following trace:
rr replay mysql-test/var/2/log/mysqld.1.rr/mariadbd-7
|
The unexpected shrinking of the system tablespace to 640 pages (10 MiB) takes place despite the unused_undo_free_fail_5 fault injection that had been introduced in MDEV-34529. The interesting part is as follows:
|
11.4 b07a36ee329569b9b2a4b373a1b16fe2dc3ed32a |
#0 fsp_free_seg_inode (space=0x560bc4abb930, inode=<optimized out>, iblock=0x60057007500, mtr=0x7ffd84c42cf8) at /mariadb/server/storage/innobase/fsp/fsp0fsp.cc:1516
|
#1 0x0000560bb776287c in fseg_free_step_low (space=space@entry=0x560bc4abb930, inode=inode@entry=0x6005725f4b2 "", iblock=iblock@entry=0x60057007500, mtr=mtr@entry=0x7ffd84c42cf8, hdr_page=hdr_page@entry=0x0,
|
ahi=0x0) at /mariadb/server/storage/innobase/fsp/fsp0fsp.cc:2866
|
#2 0x0000560bb7764001 in fseg_inode_free (page_no=0xf3, offset=0x34b2) at /mariadb/server/storage/innobase/fsp/fsp0fsp.cc:3876
|
#3 inode_info::free_segs (this=this@entry=0x7ffd84c43110) at /mariadb/server/storage/innobase/fsp/fsp0fsp.cc:3907
|
#4 0x0000560bb7764a9f in fil_space_t::garbage_collect (this=this@entry=0x560bc4abb930, shutdown=<optimized out>) at /mariadb/server/storage/innobase/fsp/fsp0fsp.cc:4016
|
#5 0x0000560bb77665e9 in fsp_system_tablespace_truncate (shutdown=0x0) at /mariadb/server/storage/innobase/fsp/fsp0fsp.cc:5775
|
Because the function fsp_free_seg_inode() will return DB_SUCCESS instead of DB_SUCCESS_LOCKED_REC, we will skip the fault injection:
|
b07a36ee329569b9b2a4b373a1b16fe2dc3ed32a:storage/innobase/fsp/fsp0fsp.cc |
|
3876
|
while ((err= fseg_free_step_low(space, inode, iblock, |
3877
|
&mtr, nullptr)) == DB_SUCCESS_LOCKED_REC)
|
3878
|
{
|
3879
|
DBUG_EXECUTE_IF("unused_undo_free_fail_5", |
3880
|
err= DB_CORRUPTION;
|
3881
|
goto func_exit;); |
If I move the DBUG_EXECUTE_IF from the while statement body before the while statement, then the test will pass. However, in that case the fault injection point would be equivalent to the unused_undo_free_fail_4.
I suspect that MDEV-38833 or MDEV-38968 changed the timing on server startup and shutdown in such a way that this test started to fail more often on my system. I did not find any failure of this kind on https://buildbot.mariadb.org.
Attachments
Issue Links
- is caused by
-
-
- Closed
-
- relates to
-
MDEV-33073 always green buildbot
-
- Stalled
-