MySQL Bugs: #102341: Why handle_fatal_signal redirect stderr to binlog index file?

Bug #102341	Why handle_fatal_signal redirect stderr to binlog index file?
Submitted:	22 Jan 2021 8:45	Modified:	22 Jan 2021 15:03
Reporter:	peng gao	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.7.18	OS:	CentOS (6.6)
Assigned to:		CPU Architecture:	Any

Description:

why redirect stderr to binlog index file?

Hi：
  When my mysqld crash handle_fatal_signal funcation write err log to binlog index file。
  later，when mysqld restart, binlog index file is error，can't restart.
  
1、binlog index file:
.....  
/zxlog/my3311/log/mysql-bin.003410
/zxlog/my3311/log/mysql-bin.003411
23:22:03 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=33554432
read_buffer_size=2097152
max_used_connections=40
.....

2、err log

InnoDB: ###### Diagnostic info printed to the standard error stream
2021-01-21T07:22:03.612355+08:00 0 [ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2021-01-21 07:22:03 0x7fc3131fd700  InnoDB: Assertion failure in thread 140475816204032 in file ut0ut.cc line 916
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/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0xf3bf15]
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x4a4)[0x7b36e4]
/lib64/libpthread.so.0(+0xf710)[0x7fc7a616c710]
/lib64/libc.so.6(gsignal+0x35)[0x7fc7a4e17625]
/lib64/libc.so.6(abort+0x175)[0x7fc7a4e18e05]
/usr/local/mysql/bin/mysqld[0x113ee15]
/usr/local/mysql/bin/mysqld(_ZN2ib5fatalD1Ev+0xb3)[0x1143963]
/usr/local/mysql/bin/mysqld(srv_error_monitor_thread+0x98a)[0x10f041a]
/lib64/libpthread.so.0(+0x79d1)[0x7fc7a61649d1]
/lib64/libc.so.6(clone+0x6d)[0x7fc7a4ecd9dd]  
  

And it's very strange，why stderr is redirect to  binlog index file，write log to binlog index file。
have any bug relate this problem?
thanks!

How to repeat:
I down't kwon

Suggested fix:
I down't kwon

Hi,

Thank you for your bug report.

However, first of all, you are using a release that is very , very old. There are, literally, tens of thousands of bugs fixed between your release and current stable release, which is 5.7.33.

Next, the error you are observing could be a consequence of running out of file descriptors on your OS. Hence, you should also make sure that our server has maximum number of file descriptors available to it.

Last, but not least, we need a fully repeatable test case in order to process a bug. Let us know when you can assemble a proper test case that we can repeat on our installations.

thanks very much。
I will look at os file  descriptors problem。

You are truly welcome .....