|
mleich reported this file testing MDEV-30136:
#5 0x0000556bcc528d01 in ut_dbg_assertion_failed (expr=expr@entry=0x556bcd4792e0 "success", file=file@entry=0x556bcd47d280 "/data/Server/bb-10.11-new-innodb-defaults/storage/innobase/fil/fil0fil.cc", line=line@entry=1385)
|
at /data/Server/bb-10.11-new-innodb-defaults/storage/innobase/ut/ut0dbg.cc:60
|
#6 0x0000556bcc759aca in fil_space_t::reopen_all () at /data/Server/bb-10.11-new-innodb-defaults/storage/innobase/fil/fil0fil.cc:1385
|
#7 0x0000556bcc759ddc in fil_system_t::set_buffered (this=0x556bceb772c0 <fil_system>, buffered=<optimized out>) at /data/Server/bb-10.11-new-innodb-defaults/storage/innobase/fil/fil0fil.cc:1432
|
#8 0x0000556bcbfbca0b in innodb_data_file_buffering_update (save=0x6290001094d0) at /data/Server/bb-10.11-new-innodb-defaults/storage/innobase/handler/ha_innodb.cc:18336
|
This crash occurs in some code that being is introduced in MDEV-30136, for closing and reopening all InnoDB data files to modify their parameters. A file was not found because concurrently, another thread was renaming the file.
A similar failure seems possible in fil_node_open_file() when the file that had been previously closed due to innodb_open_files and fil_space_t::try_to_close(), is being renamed at the same time when it is being opened.
Before MDEV-28870, the rename operation was being protected by fil_system.mutex. Holding fil_system.mutex across the rename operation made the problem go away in MDEV-30136.
|