MySQL Bugs: #117328: Innodb FATAL [MY-013622] fsync() returned EIO with [MY-013183] Assertion failure: os0file.cc

Bug #117328	Innodb FATAL [MY-013622] fsync() returned EIO with [MY-013183] Assertion failure: os0file.cc
Submitted:	29 Jan 21:21	Modified:	30 Jan 11:28
Reporter:	Paul Fenstermacher	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	8.0.32-commercial	OS:	Red Hat
Assigned to:		CPU Architecture:	x86

Description:
Crashed on shutdown during host reboot.  This is not same cause as Bug #114608 (Bug # 114339), which is caused by innodb_use_fdatasync=ON.  
We are running 8.0.32 where innodb_use_fdatasync=OFF by default (I verified it is off).

From errorlog:

2025-01-20T12:44:20.701092Z 0 [System] [MY-013172] [Server] Received SHUTDOWN from user <via user signal>. Shutting down mysqld (Version: 8.0.32-commercial).
2025-01-20T12:44:23.798293Z 0 [ERROR] [MY-013622] [InnoDB] [FATAL] fsync() returned EIO, aborting.
2025-01-20T12:44:23.798347Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: os0file.cc:2861:ib::fatal triggered thread 140036761417472
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2025-01-20T12:44:23Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=f6ac8562a7f995c937214cbd1acd129c677ada4a
Thread pointer: 0x0
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 = 0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x213f091]
/usr/sbin/mysqld(print_fatal_signal(int)+0x387) [0xfdfcc7]
/usr/sbin/mysqld(my_server_abort()+0x7e) [0xfdfe1e]
/usr/sbin/mysqld(my_abort()+0xe) [0x2138e7e]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x33a) [0x243c48a]
/usr/sbin/mysqld(ib::fatal::~fatal()+0xc8) [0x243ed48]
/usr/sbin/mysqld() [0x232bf47]
/usr/sbin/mysqld(os_file_flush_func(int)+0x28) [0x232c1d8]
/usr/sbin/mysqld(Log_file_handle::fsync()+0xb4) [0x22df1f4]
/usr/sbin/mysqld(log_files_next_checkpoint(log_t&, unsigned long)+0x2d4) [0x22c8684]
/usr/sbin/mysqld(log_checkpointer(log_t*)+0x349) [0x22c97e9]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Detached_thread, void (*)(log_t*), log_t*> > >::_M_run()+0xce) [0x22e7b7e]
/lib64/libstdc++.so.6(+0xc2b23) [0x7f6217152b23]
/lib64/libpthread.so.0(+0x81ca) [0x7f62183c71ca]
/lib64/libc.so.6(clone+0x43) [0x7f621676ae73]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

How to repeat:
Has happened only once so far.

Note:  This is a very busy replica host.  It receives transactions pretty much continuously/constantly at a high rate from over a dozen source hosts via multi-source replication.

Hi Mr. Fenstermacher,

Thank you for your bug report.

This is a forum for the reports with fully repeatable test cases and you have not provided one.

However, we have found that we already have a bug that is verified and which has 100 % the same stack trace.

That bug is:

https://bugs.mysql.com/bug.php?id=117192

That bug is hidden from the public and private , because (unlike your report) it has a full test case.

We have added your bug to the original bug, so that you will be informed when the original bug is fixed.

Duplicate.