MySQL Bugs: #95285: InnoDB: Page [page id: space=1337, page number=39] still fixed or dirty

Bug #95285	InnoDB: Page [page id: space=1337, page number=39] still fixed or dirty
Submitted:	7 May 2019 18:27	Modified:	9 Apr 2020 16:53
Reporter:	LUCA TRUFFARELLI	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S2 (Serious)
Version:	5.7.28	OS:	CentOS
Assigned to:		CPU Architecture:	Any

Description:
During last two days mysqld returned the following error during two different shutdowns.
We did more than two shutdowns so it seems that there is some situation that generate after some time of execution.

We first experienced this after we upgraded from version 5.7.25.

During startup no reference to the shutdown error was reported.

Could not find anything among existing bugs.

This is the message written into the log:

2019-05-06T21:31:08.584292Z 0 [ERROR] [FATAL] InnoDB: Page [page id: space=1337, page number=39] still fixed or dirty
2019-05-06 23:31:08 0x7f1d049a8780  InnoDB: Assertion failure in thread 139762608015232 in file ut0ut.cc line 942
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.
21:31:08 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=8388608
read_buffer_size=131072
max_used_connections=21
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338788 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

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 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xf07d6b]
/usr/sbin/mysqld(handle_fatal_signal+0x461)[0x7b97f1]
/lib64/libpthread.so.0(+0xf5d0)[0x7f1d045965d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f1d02f80207]
/lib64/libc.so.6(abort+0x148)[0x7f1d02f818f8]
/usr/sbin/mysqld[0x789b14]
/usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0xfd)[0x10dea2d]
/usr/sbin/mysqld[0x111e948]
/usr/sbin/mysqld(_Z13buf_all_freedv+0x4c)[0x111e9bc]
/usr/sbin/mysqld(_Z37logs_empty_and_mark_files_at_shutdownv+0x184f)[0xfa521f]
/usr/sbin/mysqld(_Z27innobase_shutdown_for_mysqlv+0x8df)[0x10853cf]
/usr/sbin/mysqld[0xf38a65]
/usr/sbin/mysqld(_Z22ha_finalize_handlertonP13st_plugin_int+0x2c)[0x805c4c]
/usr/sbin/mysqld[0xcf4c27]
/usr/sbin/mysqld(_Z15plugin_shutdownv+0x209)[0xcf7d09]
/usr/sbin/mysqld[0x7aed28]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x20ba)[0x7b51ca]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f1d02f6c3d5]
/usr/sbin/mysqld[0x7a95f4]
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:
It repeated two times in two days but we are not able to find the conditions to reproduce it.

Pretty printed stack trace:

0x0000000000f07d6b: my_print_stacktrace at stacktrace.c:227
0x00000000007b97f1: handle_fatal_signal at signal_handler.cc:150 (discriminator 3)
0x0000000000789b14: operator<< <std::char_traits<char> > at ostream:530
0x00000000010dea2d: ib::fatal::~fatal() at ut0ut.cc:942
0x000000000111e948: buf_all_freed_instance at buf0buf.cc:5940
0x000000000111e9bc: buf_all_freed() at buf0buf.cc:6920
0x0000000000fa521f: logs_empty_and_mark_files_at_shutdown() at log0log.cc:2314
0x00000000010853cf: innobase_shutdown_for_mysql() at srv0start.cc:2735
0x0000000000f38a65: innobase_space_shutdown at ha_innodb.cc:3336
 (inlined by) innobase_end at ha_innodb.cc:4198
0x0000000000805c4c: ha_finalize_handlerton(st_plugin_int*) at handler.cc:785
0x0000000000cf4c27: plugin_deinitialize at sql_plugin.cc:1028
 (inlined by) reap_plugins at sql_plugin.cc:1110
0x0000000000cf7d09: plugin_shutdown() at sql_plugin.cc:1984
0x00000000007aed28: clean_up at mysqld.cc:1327
0x00000000007b51ca: mysqld_main(int, char**) at mysqld.cc:5206

buf0buf.cc:5940:
----------------
(gdb) list buf0buf.cc:5940
5935            for (i = buf_pool->n_chunks; i--; chunk++) {
5936
5937                    const buf_block_t* block = buf_chunk_not_freed(chunk);
5938
5939                    if (UNIV_LIKELY_NULL(block)) {
5940                            ib::fatal() << "Page " << block->page.id
5941                                    << " still fixed or dirty";
5942                    }
5943            }
5944
(gdb)

buf0buf.cc:6920:
------------------
(gdb) list buf0buf.cc:6920
6915            for (ulint i = 0; i < srv_buf_pool_instances; i++) {
6916                    buf_pool_t*     buf_pool;
6917
6918                    buf_pool = buf_pool_from_array(i);
6919
6920                    if (!buf_all_freed_instance(buf_pool)) {
6921                            return(FALSE);
6922                    }
6923            }
6924

log0log.cc:2314:
----------------
(gdb) list log0log.cc:2314
2309            /* The call fil_write_flushed_lsn() will bypass the buffer
2310            pool: therefore it is essential that the buffer pool has been
2311            completely flushed to disk! (We do not call fil_write... if the
2312            'very fast' shutdown is enabled.) */
2313
2314            if (!buf_all_freed()) {
2315
2316                    if (srv_print_verbose_log && count > 600) {
2317                            ib::info() << "Waiting for dirty buffer pages to be"
2318                                    " flushed";

Hi,

Thank you for your bug report.

Our colleague Shane Bester has done all the heavy work in make the most from this bug. This definitely happens during the normal shutdown.

What happens here is some problem in memory, most likely your RAM. Simply, some blocks are not freed, but what causes a controlled exit is a problem of using C++ streams, which require additional memory.

Can you repeat this problem ???

Regarding RAM hardware problems, it could be a fault, but it also could be a minor passing glitch that will not happen in that piece of code for long time.

Hi,

Actually, I think that here we could change our code and not access fields of that particular block.

Instead we should just print its address. Then, in the case of memory corruption, we could at least prove that the value of the pointer makes no sense and that it was a glitch in RAM.

Verified as a feature request.

Just to inform that we reverted to version 5.7.25 and the error didn't happen again since 4 days ago.

Thank you Mr. Truffarelli,

This is an important information. Do let us know if you experience any other crashes with 5.7.25.

Another report on 5.7.26..
https://bugs.mysql.com/bug.php?id=95534

Hi,

This looks like a regression bug to me.

Particularly because we have more reports identical to this one, like:

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

Hence, bug # 95534 is a duplicate of this regression bug of the high severity.

Hi,

It turns out that we need stack traces from all the threads that were running when the problem occurred. 

Please, let us know if you can get what we require. The other option is to upload the core file and the binary that produced it.

Thanks in advance.

Hello, thank you for your update.

We don't have a core file cause we didn't configure my.cnf to generate it and neither we have stack traces cause the reboot was a scheduled task.

To get the core we need to upgrade again to version 5.7.26, configure mysql to generate the core and wait for the problem to raise again (since it happend once every couple of days)

If you need us to generate it we might schedule the activity but we might require some time since it is a production server.

Hi Mr. Truffarelli,

Thank you for your answer. 

Unfortunately, yes, we need you to upgrade to 5.7.26. Also, you do not need only to configure our server to dump core, but you also have to configure your Linux in order that it dumps core.

Thank you very much in advance and please take your time.

Hi, we just replicated the issue using a different machine setup to collect the core and with mysql 5.7.26.
I uploaded the core and log file to your sftp site.

Thank you

Thank you Signor Truffarelli,

Would you be so kind to let us know the name of the core files that you have uploaded, since we have a number of core files there.

Also, which mysqld binary have you been using. If it is from our download site, just let us know the package that you used. If you have built your own, then uploading compressed mysqld binary is a must.

You can use a hidden message to let us know the filename(s).

Thanks in advance.

Signor Truffarelli,

We have located your core file, but we are waiting for your input regarding the binary that dumped that core file.

Many thanks in advance.

Thank you, Mr. Truffarrelli ..

Any updates on this issue? We've also run into it. Is going back to 5.7.25 the only workaround?

Hi Mr. Vikram,

We are still examining data ourselves. Hence, we do not have any answers, yet ......

You could help by providing a core file with a binary that has dumped it ......

Or, even better, if you can remember what did you do to hit that assert. Does it happen to you every time when you shutdown MySQL server ????

I've usually seen it happen when there are a large number of databases. Apart from that, I haven't seen any pattern unfortunately. Haven't been able to reproduce it either. It happens intermittently.

Hi Mr. Vikram,

Can you supply us with a core file and a binary that produced it ...

Also, beside large number of databases and tables, can you let us know what exactly has our server being doing prior to the shutdown.

Hi Mr. Truffarelli,

Can you send us another core file, if you get a crash at shutdown again.

Also, which plugins are you loading at startup.

Last, but not least,  can you let us know what exactly has our server being doing prior to the shutdown.

Thanks in advance.

Hi Mr Milivojevic,

We downgraded the server cause it was a production one, and we didn't have any crash, so I won't be able to get a new crash from that server.

We can generate a new one using a test sever and asking the users to use it if needed.

Loaded plugins are:
mysql> show plugins;
+----------------------------+----------+--------------------+---------+---------+
| Name                       | Status   | Type               | Library | License |
+----------------------------+----------+--------------------+---------+---------+
| binlog                     | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| mysql_native_password      | ACTIVE   | AUTHENTICATION     | NULL    | GPL     |
| sha256_password            | ACTIVE   | AUTHENTICATION     | NULL    | GPL     |
| CSV                        | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| MEMORY                     | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| InnoDB                     | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| INNODB_TRX                 | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_LOCKS               | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_LOCK_WAITS          | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_CMP                 | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_CMP_RESET           | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_CMPMEM              | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_CMPMEM_RESET        | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_CMP_PER_INDEX       | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_CMP_PER_INDEX_RESET | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_BUFFER_PAGE         | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_BUFFER_PAGE_LRU     | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_BUFFER_POOL_STATS   | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_TEMP_TABLE_INFO     | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_METRICS             | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_FT_DEFAULT_STOPWORD | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_FT_DELETED          | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_FT_BEING_DELETED    | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_FT_CONFIG           | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_FT_INDEX_CACHE      | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_FT_INDEX_TABLE      | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_TABLES          | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_TABLESTATS      | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_INDEXES         | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_COLUMNS         | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_FIELDS          | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_FOREIGN         | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_FOREIGN_COLS    | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_TABLESPACES     | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_DATAFILES       | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| INNODB_SYS_VIRTUAL         | ACTIVE   | INFORMATION SCHEMA | NULL    | GPL     |
| MyISAM                     | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| MRG_MYISAM                 | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| PERFORMANCE_SCHEMA         | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| ARCHIVE                    | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| BLACKHOLE                  | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| FEDERATED                  | DISABLED | STORAGE ENGINE     | NULL    | GPL     |
| partition                  | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| ngram                      | ACTIVE   | FTPARSER           | NULL    | GPL     |
+----------------------------+----------+--------------------+---------+---------+

The server before the shutdown worked for at least a full day so did many different things even if they were mainly related to data manipulation rather then schema changes.
I can add something we noticed:
- the crash happen when a scheduled shutdown is executed at the end of the day. During the day abuot 6 users interact with the server thru a java applition
- the crash does not happen after few hours of normal work 
- the crash does not happen after a week with the server running but no user interacting with it
I'm not sure how to better answer to your question, do you need anything more specific?

Signor Truffarelli,

Thanks a lot, for the additional info.

What we would welcome very much is another core file.

Thanks in advance.

Hello Mr. Truffarelli,

We need the following information from you:

1. Your my.cnf file , for the version that crashes .....

2. The output of "SHOW ENGINE INNODB STATUS", before your server is shut down .....

3. Please, enable performance_schema instruments and share the performance stats:

Please, set the performance-schema-instrument 'wait/synch/mutex/innodb/%' to ON.

What we then require is the output from "SELECT * FROM performance_schema.events_waits_summary_global_by_event_name WHERE SUM_TIMER_WAIT > 0 AND EVENT_NAME LIKE 'wait/synch/mutex/innodb/%' ORDER BY COUNT_STAR DESC;"

Many thanks in advance ....

Hello,
   we reproduced the problem on a different machine running newer version 5.7.28.

I uploaded a file into the ftp space named mysql-bug-reuesteddata-95285.zip containing:
Abort.txt - the error generate
my.cnf - server conf file
PreAbort.txt - performace instruments before closing the server
Restart.txt - log after the restart
variables.txt - variables configured

Hope them will help

Thank you, Mr. Truffarelli,

This will come useful, although this bug is already verified.

Thanks again.

This hasn't been actually been repeatable yet.  If anybody can come up with compact testcase,  or synthetic workload that can be run for X minutes,  that leads to a crash at shutdown,  it'd be useful to have.

Hello,
    I'm writing to inform you that we identified a reproducible behaviour using our software that leads to the crash during the shutdown.

We are now working to isolate the queries that generate the issue and then we'll create the condition (table/queries) to let you reproduce it.

We'll update you once we have something helpful.

Signor Truffarelli,

We are eagerly waiting on the feedback from you .....

Hello,
    I just uploaded a zip file in you ftp space named mysql-bug-reproducescripts-95285.zip.

Using data into the archive you should be able to reproduce the problem.

We added a licence file into the archive cause data contained into the dump is an extraction of production db.

To reproduce the problem you need to have MySql server version 5.7.26 to 5.7.28 installed. Then you have to follow these steps:
- set the my.cnf as the one provided
- start MySql server
- run TestDumpLoadDB.sh
	replace user and pass into the script as needed
	the script will create a DB named TestDump and will fill it with data contained into TestDump.db
- run TestDumpQuery.sh
	replace user and pass into the script as needed
	the script will run a sigle querty contained into TestDump.sql the will then cause the problem
- shutdown the server
- you should now see the crash into the error.log file

Hope it helps

LUCA,  thank you for this.  I confirm the shutdown crash is repeatable!

2020-01-11T11:45:11.390013Z 0 [ERROR] [FATAL] InnoDB: Page [page id: space=63, page number=35] still fixed or dirty
2020-01-11 13:45:11 0x7ffff7a2e740  InnoDB: Assertion failure in thread 140737348036416 in file ut0ut.cc line 918
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.

Thread 1 "mysqld" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	  return ret;
Missing separate debuginfos, use: dnf debuginfo-install numactl-libs-2.0.12-2.fc30.x86_64
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7a55895 in __GI_abort () at abort.c:79
#2  0x00000000007ea40e in ut_dbg_assertion_failed (expr=0x0, file=<optimized out>, line=918) at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/storage/innobase/ut/ut0dbg.cc:75
#3  0x00000000011de013 in ib::fatal::~fatal (this=0x7fffffffb060, __in_chrg=<optimized out>) at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/storage/innobase/ut/ut0ut.cc:918
#4  0x0000000001219204 in buf_all_freed_instance (buf_pool=<optimized out>) at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/storage/innobase/buf/buf0buf.cc:5949
#5  0x00000000012192cc in buf_all_freed () at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/storage/innobase/buf/buf0buf.cc:6928
#6  0x00000000010d0cdb in logs_empty_and_mark_files_at_shutdown () at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/storage/innobase/log/log0log.cc:2322
#7  0x000000000119271f in innobase_shutdown_for_mysql () at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/storage/innobase/srv/srv0start.cc:2743
#8  0x0000000001071e90 in innobase_end (hton=<optimized out>, type=<optimized out>) at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/storage/innobase/handler/ha_innodb.cc:4205
#9  0x000000000084640c in ha_finalize_handlerton (plugin=0x229cc58) at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/sql/handler.cc:790
#10 0x0000000000d6697b in plugin_deinitialize (plugin=0x229cc58, ref_check=true) at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/sql/sql_plugin.cc:1035
#11 0x0000000000d6b509 in reap_plugins () at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/sql/sql_plugin.cc:1117
#12 0x0000000000d6f6a8 in plugin_shutdown () at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/sql/sql_plugin.cc:1991
#13 0x00000000007f09c8 in clean_up (print_message=true) at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/sql/mysqld.cc:1333
#14 0x00000000007f5a00 in mysqld_main (argc=13, argv=0x211c8f0) at /export/home/pb2/build/sb_0-36131509-1569573142.98/mysql-5.7.28/sql/mysqld.cc:5184
#15 0x00007ffff7a56f43 in __libc_start_main (main=0x7eb240 <main(int, char**)>, argc=13, argv=0x7fffffffd358, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd348) at ../csu/libc-start.c:308
#16 0x00000000007eb179 in _start ()
(gdb)

Also verified on:
Version: '5.7.30-asan' (Built on 11 January 2020 with g++ (GCC) 10.0.0 20191215 (experimental))

I am also affected with this issue and frequent MySQL restart issue due to this issue.

Hi Mr. A.,

You do not need to send comments that you are also affected. All you need to do is click on "Affects me" button in the upper right corner.

Anyway, this bug has got already sufficient internal priority for scheduling.

I received this message recently.  Can someone make the test files that reproduce the error public so I can see them (for testing purposes)?

When is this issue expected to be fixed?
Thank you.

Hi,

When this bug is fixed, this page will be updated with all the info required.

Hence, all that you have to do is to be subscribe to this report.

Thank you, Sinisa.  I am subscribed to this report.
- When is a fix expected to be available?  
- Also, please provide the script to reproduce the error so I can confirm that it is the same issue I am experiencing.  There is no reason for me to wait for this fix if it's not the same problem I am experiencing.

Hello Sinisa,
I do not see the steps to recreate the problem.  I see a comment on 1/11/2020 from another customer indicating a zip file named named mysql-bug-reproducescripts-95285.zip was uploaded to your ftp space that could be used to reproduce the error and a subsequent comment from Shane Bester indicating he was able to reproduce the error using the files included in the uploaded zip file.

Can you please share this zip file mysql-bug-reproducescripts-95285.zip?
Thank you.

Hi Greg,

Sorry, but we can not share anything that we get from reporters and contributors.

What ever they send us , we are bound by confidentiality not to share their info with anybody else, except by our own staff.

Hi Sinisa,
It is my understanding, based on reading the comments on page, that the error can be reproduced on demand.  What I am looking for are the steps I can execute on my end to reproduce the error.  

You stated yesterday:
[26 Feb 14:32] Sinisa Milivojevic
"
Hi,
Nobody knows when will fix be available, since the scheduling and fixing is done in another department.

All you need to repeat this bug is on this page.

I can not send you anything.
"

I am asking again, can you please provide the steps I can use to reproduce this bug?  There is no reason for me to wait for this fix if it's not the same problem I am experiencing.
Thank you.

Mr Yoas,

We have a simple test case that crashes the server. However, we can not make that public, as it would raise security concerns. We are simply prohibited to reveal the steps which would lead to the crash.

However, you can easily check whether you are affected by this bug. You can see a thread stack which is produced by this crash. If your thread stack is same, then you are affected. Otherwise , you are not affected.

https://bugs.mysql.com/bug.php?id=99016 is a duplicate.

Posted by developer:
 
Fixed as of the upcoming 5.7.31, 8.0.21 release, and here's the proposed changelog entry from the documentation team:

A fatal "page still fixed or dirty" error occurred during shutdown.

Workaround:
---------------

[mysqld]
internal_tmp_disk_storage_engine=MYISAM

newer versions of mysql don't have that configurable, though
(ref https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_d...)