MySQL Bugs: #102337: Workbench 8.0.23 crashes when attempting to show Client Connections

Bug #102337	Workbench 8.0.23 crashes when attempting to show Client Connections
Submitted:	21 Jan 2021 21:13	Modified:	8 Feb 2021 10:50
Reporter:	Robert Roland	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Workbench	Severity:	S2 (Serious)
Version:	8.0.23	OS:	Windows (10 x64)
Assigned to:		CPU Architecture:	Other (AMD 3900X)
Tags:	DISABLE REDO_LOG; Redo log

Description:
A new install of Workbench 8.0.23 x64 on Windows 10 crashes at the moment the application attempts to refresh the list of current Client Connections.

Downgrading to 8.0.22 resolves the issue.

After connecting normally to the MySQL server 8.0.23 using root everything appears normal and pages such as Server Status and Dashboard are working.

However, when the Client Connections page is selected the list of connections is initially blank rather than populated as is the case with prior versions.

If the Refresh button is clicked the application immediately crashes.

Similarly, if the refresh rate is set to some time frame such as 15 seconds then in exactly 15 seconds the application crashes.

How to repeat:
MySQL server upgrade from 8.0.21 to 8.0.23 was recently completed successfully on dedicated Win 10 x64 AMD 3900X 64GB machine. Fresh install of Workbench 8.0.23 x64 was installed using the 1.4.36.0 MySQL installer. Workbench was configured to connect using root/localhost with standard authentication. Connection to server was established in the normal manner using Workbench and the Client Connection page was selected from the navigation pane. The Refresh button was then clicked causing the crash. This occurs even if workbench is removed and reinstalled.

Suggested fix:
Downgrading to 8.0.22 resolves the issue.

Thank you for the bug report. I couldn't repeat. Which server version are you connecting? Please attach the wb.log. Thanks.

workbench log file for crashing v 8.0.23

Attachment: wb-logfile-v8.0.23-crashes.log (application/octet-stream, text), 6.24 KiB.

workbench log file for working v 8.0.22

Attachment: wb-logfile-v8.0.22-working-ok.log (application/octet-stream, text), 5.29 KiB.

As noted, the MySQL server is 8.0.23 standard authentication.

In the wb.log I noticed this entry is different in v8.0.23:

Unable to create db_mgmt_SSHConnectionRef object

i also can't repeat that issue. Entry in log is not releated with crash 
5:52:48 [ERR][SQL Editor Form]: Unable to create db_mgmt_SSHConnectionRef object

Can yoy create and paste debug log from Workbench? 

https://dev.mysql.com/doc/workbench/en/workbench-reporting-bugs.html
# Microsoft Windows
shell> cd "C:\Program Files (x86)\MySQL\MySQL Workbench CE 8.0.23\"
shell> MySQLWorkbench.exe -log-level=debug3

I created Bug 102315 for this as well, same issue... but older version of MySQL Community Server.

The issue occurs when the Performance Schema is disabled. When enabled on my server, the Client Connections page works as expected.

I'm having the same issue too after upgrading to 8.0.23, 8.0.22 it was working fine. Only difference is that i'm connecting to MariaDB 10.5.8. 
If i close the tab fast enough it won't crash

I will reply back with debug log after I recover from a server crash yesterday.

Although the following description of the crash is off topic I believe it is important to describe for anyone searching for information about redo logging.

--------------------- Event Description --------------------

I used ALTER INSTANCE DISABLE INNODB REDO_LOG just prior to an update on a very large table that I did not want to rollback in case I hit an error (since I did not want to use UPDATE IGNORE allowing me to observe the row causing any potential error to allow me to correct it).

During the update another connection was using a stored function that queries a small table hundreds of times to test permutations of a string and I got:
"mysqld got exception 0xc0000005"
with first line of trace:
"mysqld.exe!?set_compression_level@Zstd_comp@compression@transaction@binary_log"
(even though binlog is disabled).

Obviously I knew I had a serious problem and was prepared to restore the table I was updating from a backup. However, I quickly realized the problem was MUCH MORE SERIOUS than that as soon I saw this in the .err log:

"Server was killed when InnoDB redo logging was disabled. Data files could be corrupt. You can try to restart the database with innodb_force_recovery=6"

I tried innodb_force_recovery from 1 to 5 and the server would not start.
The Data Dictionary will not initialize in this situation.

Using innodb_force_recovery=6 I have had to dump terabytes of data across hundreds of tables and rebuild an entire new installation of MYSQL server from these backups.

Let this be a lesson to all who use "DISABLE INNODB REDO_LOG".

Even though there is shaded WARNING callout in the documentation that states...

"an unexpected server stoppage while redo logging is disabled can cause data loss and instance corruption"

...I implore the team to BOLD this sentence and add an additional line that is more explicit which essentially states that:

Recovery from this event requires a complete reinstallation/initialization of MySQL server and a restoration of ALL tables/schemes from backup.

If I read a sentence like that I would have never disabled the redo log.

Upgraded from 8.0.22 on MacOS and have a similar issue but for me it just crashes as soon as the app tries to open. Downgraded back to 8.0.22 and it worked. I'm using homebrew.

To repeat the issue upgraded to latest using 

    brew upgrade --cask mysqlworkbench

The app crashes on start.
Downgraded the app to 8.0.22 using homebrew

    brew remove --cask mysqlworkbench
    wget https://raw.githubusercontent.com/Homebrew/homebrew-cask/f0fcc022b603ae6ba4068857a87734d60...
    brew install --HEAD -s mysqlworkbench.rb

Hello,

Thank you for the bug report.
Imho this is duplicate of Bug #102465, please see Bug #102465.

Regards,
Ashwini Patil