MySQL Bugs: #69241: Mysql workbench not responding

Bug #69241	Mysql workbench not responding
Submitted:	15 May 2013 11:41	Modified:	6 May 2015 7:30
Reporter:	Bruce Lombardi	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Workbench	Severity:	S2 (Serious)
Version:	5.2.47 CE	OS:	Windows (V7 64 bit SP 1)
Assigned to:		CPU Architecture:	Any
Tags:	64bit, hangs, not responding, unresponsive, window7, workbench

Description:
At various times MySql Workbench will stop responding. Clicking anywhere in the program, for example in a SQL editor window or on a menu item, results in the application window going white and a circular busy icon appearing. This continues until Widows is used to force the program to close.

Uninstalling and Reinstalling Workbench and the entire MySql application suite did not help.

How to repeat:
It seems to happen more often when Workbench is left idle for a while when using another application. On returning to Workbench, the problem occurs.

Thank you for the bug report. What kind of use are you doing i.e: handling a large model, are you noticed the memory usage is increasing? etc. Thanks.

I am not doing anything in Workbench when it hangs, it is idle and I am returning to it from another program. I don't have a particularly large data set. It can hang if I start workbench and do nothing with it, then return to it from another program.

Thank you for the feedback. Even idle it's monitoring a busy server? (See Administration->Management->Server Status activity). Thanks.

Server is not busy either. Just seems to happen more when Workbench is idle for a while.

I'm using Workbench on Mac and have the problem on and of. I have now realized that I only have the problem when FireFox is running. If I close FireFox Workbench does not freeze.

Please try version 6.0.5

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I am experiencing a similar problem with workbench v6.0.7. I dont have to force it to stop, but it goes to not responding for about 5 seconds and then jerks back to life.

Please try version 6.0.8. Thanks.

I also noticed a similar situation to Lars Schmidt. Firefox was open and consuming a lot of memory. when i restarted firefox and freed up some system memory Workbench started working again.

Occurs on Windows 7 updated to 6.0.8.
It seems very much like something has decided that it absolutely must log into the SQL server before allowing you to type anything. It's frequent and terrible.
If working across multiple servers in multiple tabs, the entire app is frozen, not just a single tab.

I am having the same issue. Additionally, even when it doesn't lock/freeze/hang, as I am typing queries it is often horribly sluggish, as though it's trying to do heavy lifting in the background. It should never be doing expensive processing while typing text in the editor -- wait until I click a button or something.

I am on Windows 7 and MySQL Workbench 6.0.8.11354.

Please fix this. It's horrible and happens constantly. I would be happy to give someone at Oracle diag on my PC, let you remote in and see it, etc.

Please try version 6.0.9 or 6.1.1. Thanks.

Godofredo, I just upgraded to 6.0.9 and it is much worse. I wish I had stayed with 6.0.8. 608 was slow but at least didn't crash. 609 blows up. All I did was scripted one of my tables, then started editing the script. That's it. I wasn't running queries or anything.

I can't believe MySQL doesn't fix such a HUGE P1 bug that has been around for so long.

I'm on Windows 7.

I am also still seeing the issue in 6.0.9. Any idea when 6.1 will get out of beta?

I am experiencing this problem in version 6.0.9 and also version 5.2.  I'm running Windows 7, Service Pack 1, 64-bit.

Please try the following:

- find the WB data directory (use Help -> Locate Log Files)
- quit WB
- rename the data directory
- start WB and add your connection back (you can copy the connections.xml and server_instances.xml files to the new data directory to get your connection list)
- check if it continues freezing

If that does fix the issue, please considering sending the data directory to us so we can investigate in more detail. 

Also, we've fixed some issues related to this in version 6.1, please see if that makes it better. You can install the zip package so you can still fall back to the older version if it's not any better.

How do I identify the "WB Data Directory"?

"Help -> Locate Log Files" took me to this location:
C:\Users\Sarah\AppData\Roaming\MySQL\Workbench\log

I renamed the file "workbench_user_data.dat" in this location:
C:\Users\Sarah\AppData\Roaming\MySQL\Workbench
but that did not fix the problem.

We have this problem too. We just upgraded to Workbench 6.1.4 and it is still there! The application says "Not Responding" for a few seconds and then comes back to life. Often when the application has been idle for a while.
When this happens CPU is not doing much.
We have this problem on several PC's running Windows 7 and Windows 8 and Windows 8.1.
We connect to a MySQL server on an azure server. The MySQL server is version 5.6.15.
We have tried to hide the 'context help' pane on the right side, but it didn't help either.

This has been a problem for many months and it is really annoying.

Since MySQL has no intention of fixing this huge bug, I have switched to the free HeidiSQL and I love it. No freezes. I guess Workbench freezing up and being sluggish all the time is considered acceptable. This has to be the biggest/worst bug they have, yet they don't fix it...

I'm using WB 6.1.6.11834
While opening databases which contains only several hundreds tables it just stutter a bit. But when I try to open database with around 70000 tables for the first time every time I start the workbench, it became not responding for 10~15 minutes until it can be used again, after that it works normally even though I'm changing the database to another and back (to the 70k one).
Hope that info could help

We have been having this problem for months at my company as well... several users on various OS and various versions of workbench.  Have tried upgrading folks to most recent releases, tried increasing timeouts, tried disabling auto-complete, etc.  Sometimes we get the spinning wheel and the process "comes back to life" after a few seconds up to a few minutes... other times it never comes back and we have to terminate the process.

In Windows Resource Monitor, I see the non-responsive process with 23 threads and 12% CPU usage.  If I right-click and "Analyze Wait Chain" it shows 5 threads of the 23 and says "One or more threads of MySQLWorkbench.exe are waiting to finish network I/O."

Please try version 6.1.7. Thanks.

We've tried upgrading to 6.1.7, but no real change of behavior.

Examples of when we've had it lock up (multiple users experiencing similar symptoms):
- When writing a query in the query window and Workbench appears to be attempting to generate an auto-complete list
- When expanding an item in the Schemas pane (say, to view the list of tables within a schema)
- When the Client Connections window is open and set to refresh periodically (to track query status while doing other work)... user will return periodically to the workbench window, and occasionally when he does so Workbench will be locked up (seems to have happened in background)
- When running a query that returns a lot of data to the client (hundreds of columns, thousands of rows)

In each case it seems like the Workbench client is making some form of query to the server (though I don't know what all is cached locally, such as table lists or auto-complete items), but sometimes whatever that process is seems to fail in a way that causes Workbench to crash (occasionally it just locks up for anywhere from a few seconds to a few minutes, but sometimes it never comes back, and usually after a few seconds users will just force quit and relaunch rather than sit around waiting to see what happens).

Also note that this occurs regardless of where the client is being run... on the server itself, on a desktop on the LAN, or a remote desktop connected to the server via VPN... doesn't seem to matter as we see this type of crashing behavior in all instances and on various flavors of Windows OS (notably Server versions 2008 R2 and 2012 R2, and Desktop all varieties of Win 7/8/8.1)

From the comments, it looks like different things cause unresponsiveness. 

One of them may be caused by code completion, which needs to retrieve the list of objects in the current default schema from the server. We can improve this, but to confirm that this is really the problem, you can disable Code Completion in Preferences and see if it helps.

There's also the population of the schema tree in the sidebar. This can only be made as fast as the time it takes to run SHOW DATABASES.

Another problem was the context sensitive help, which would kick in while typing, but in 6.1 this was fixed to work from a thread and additionally, to only kick in on demand.

If there's any case that is not covered by these scenarios and can't be explained by just how long it takes for the server to execute a query, please leave a comment explaining. Ideally, the server's general log would be monitored to see what's WB doing when it's slow, but that's not always possible. Another info that could be helpful tracking down the slowness is enabling verbose logging in WB (start it with -log-level=debug3) and monitor the WB log file (Help -> Locate Log File), to see if it will print what it's doing when the slowness happens.

Having the exact issue as described on Windows 8.1 64 bit with MySQL WOrkbench 6.2 CE.  When using Excel, etc. and then coming back to MYSQL WB, it just hangs and says "(Not Responding)" in the title bar.  I have to kill it with task manager at this point, it does not return even when waiting for over 30 minutes.  Seems to happen much more when PC has not been rebooted in a few days.

Please try version 6.2.3. Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Having the same problem with version 6.2.3

It just happened to me on Mac OS X. Im attaching the report from when I forced it to quit

Please try version 6.2.4. Thanks.

I don't mean to be rude, but this is ridiculous.

This bug is nearing 2 years old, and the status circles from
'No one has updated this bug in...'
to
'This is still occurring on the latest version'
followed by
'Please try again with the now-latest version'

Maybe a little pride in ownership?
Maybe actually having a developer attempt to track down THIS issue?

Anything...?

Personally, I've moved to dbForge Studio. It isn't perfect, but it also doesn't hang or crash while I'm using it.

Oracle:
Please stop disappointing me.
Please stop disappointing your community.
Please stop shaming yourselves.

I agree, this is disappointing.

It's something to do with the way an idle connection is re-established. It will freeze while trying to establish a new connection before it executes the query (Nothing shows in the Action Ouput window until after the connection is re-established if it ever is).

Had it in 5.2.X and upgraded to the latest today and its still so horrifically buggy. There was a time when this was a usable product.

ps. this page doesn't work on Chrome due to mixed HTTPS and HTTP (Captcha fails to load)

Oracle get it together! You suck.

Marked this as duplicate of Bug #73172. We will handle it in the context of the other bug.

I was ready to throw away workbench due to the frequent freezes every time I worked with. Found this thread, and noticing the timeout issue, tried this:

Edit > Preferences
SQL Editor > MySQL Session > DBMS connection keep-alive interval

The default here was set to 600 seconds. I've reduced that 30 seconds.

No issues so far.

In my case when I saw the "Cannot close SQL IDE while being used" I was using a my.cnf that was was located in my local user folder, not in the /usr/local/mysql/. This worked in WorkBench 6.1.7 in OS X. After upgrading to Workbench 6.37 build 1199 CE the message would occur whenever I made the slightest change to preferences, privileges or queries.

Windows 10, x64, same behavior.

Log Name:      Application
Source:        Application Hang
Date:          17.12.2016 13:52:32
Event ID:      1002
Task Category: (101)
Level:         Error
Keywords:      Classic
Description:
The program MySQLWorkbench.exe version 6.3.8.0 stopped interacting with Windows and was closed.

I have plenty of such events in my event log. Most from MySQLWorkbench.exe.

Workbench works when I perform SQL operations continuously (breaks between operations shorter than 5 minutes).

When I leave Workbench window for a couple of minutes and then get back - it stops responding on trying to start any SQL operation.

It's obvious it crashes when the connection is idled out. If the Workbench kept sending dummy queries once in a minute or so - I believe it would not stop responding at all.

Any code which touches the database connection should check its state, and if it's broken, all resources allocated to it should be safely disposed, then the connection object should be created again before the operation continues. The procedure of re-establishing the connection should be thoroughly tested.

The bug may occur in an exception handler - it's quite common case. The code retries the operation, but enters deadlocked state when the connection lock is not released as the first operation in the catch block. I guess the lock is implicit and it's released when the connection resources are released / connection object disposed. The bug may also exists in disposing code, so I would check it for deadlocks. I've seen critical errors in disposing code even in serious enterprise programs, so it's worth considering if all else fails.

The problem occurs not only on my computer, but also on my co-workers' machines.

I workaround this bug by closing the Workbench immediately as it crashes and reopen it a second later. It allows me to continue my work, however this bug is absolutely critical and makes us look for alternative tools.

Im having the same problem on 8.0 :( running windows 10

Im having the same problem on 8.0 :( running windows 10

Win 10, Workbench 8.0 still happening.
Incredibly frustrating to wait some minutes after changing a single letter in a WHERE clause! Then to wait again on the next letter, then to finally finish typing in some text and have to wait again before the execute button can be clicked!
Hard to believe you haven't isolated this bug in almost 10 years!