MySQL Bugs: #76909: Workbench 6.3 Crashes Frequently on Windows 7 PC

Bug #76909	Workbench 6.3 Crashes Frequently on Windows 7 PC
Submitted:	1 May 2015 7:40	Modified:	7 Sep 2016 8:00
Reporter:	IGG t	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Workbench	Severity:	S3 (Non-critical)
Version:	6.3.3	OS:	Windows (7)
Assigned to:	Mike Lischke	CPU Architecture:	Any

Description:
Having upgraded to Workbench 6.3 I now find it crashes ("workbench has stopped working and needs to close") quite frequently (4-5 times per day) on my Windows 7 PC.

I mainly use the SQL editor, so this is where I have seen it, but it may happen elsewhere.  

How to repeat:
The only thing I can see that may link these events is that it seems to happen when quickly switching between tabs. But as it doesn't happen everytime it is difficult to repeat. Sometimes it happens moments after starting up, before I've run any queries, sometimes it will be fine for some time and I will have multiple tabs open.

Nothing else has changed on my PC.

This seems to be happening more and more often. I have found that starting a long running query and then pressing the red 'stop' button quite often (but not always) has the affect of crashing workbench. Also as mentioned before moving quickly betwen tabs, or trying to open connections too quickly after restarting workbench has this affect.

This seems to be happenning with ever increasing frequency, up to 10-15 times a day now. Normally it seems to happen with multiple tabs open, or after switching quickly between tabs. However on some occasions it happens with one tab open, and no interaction on my part.

Thank you for the bug report. Which exactly 6.3.X version are you using? If prior to 6.3.3 please try this version. Thanks.

Hi, it is currently 6.3.3.0 build 592 (64 bits)

I'm using 6.3.3, and I'm experiencing crashes at an extremely high rate. Anytime I run a query and try to stop it, it crashes Workbench. Any time I click on the results table of a query with more than a few hundred rows, it crashes.

It's getting to the point where it's virtually unusable

I am having the same issue or at least one very similar.  If I execute a SQL query that has anything more than a couple hundred rows, Mysql Workbench just spins.  I can't open a new tab, I can't do anything, and I have to kill the program.

To be clear, in my earlier comment I said I have to kill the program.  That means I have to use Windows to kill the program.  If I try and end the program from within MySQL Workbench it does absolutely nothing.

Please try version 6.3.4. Thanks.

I'm using 6.3.4, build 828 on a 64-bit Windows 7 machine and Workbench crashes repeatedly on me while I'm editing a query. Sometimes I don't even get 10 characters typed in the query before it's dies.

I've upgraded to 6.3.4, and whilst it seems to crash less, it does still crash. It seems to be mainly just after opening a new connection with multiple tabs saved.

Upgraded to the new version 6.3.4 about 2 weeks ago... it's slightly more stable, but I'm still having major issues with it crashing.

Here's some actions that cause it to crash :

- Clicking in/on a query result set table (resizing columns, copying table, etc...)
- Terminating a query with the "Stop" button
- switching between tabs when several tabs are opened simultaneously

I upgraded to 6.3.4 about a week ago.  No difference at all.  Most of the time if I limit the query results to 300 rows it works fine. If I don't limit the result set it will lock up on a large query every time. Sometimes it locks up on a short query.  Queries against the information_schema views lock up frequently if I don't limit the results, regardless of the result set size.  One time I did not kill Workbench and came back to it ~30 minutes later.  It had a timeout error and was no longer locked up, but it would not re-connect to any databases so I had to restart it anyways.  Unfortunately I did not save the exact error.

Is there any update on this. The problem still exists. To be honest at this point I am seriously considering switching to another program such as SQLYog. MySQL Workbench locks up on me at least once a day, usually more, and it is completely useless for looking at any large result sets.

Upgraded to Workbench Commercial 6.3.3.0 Build 593 64bit recently, and any time I try to run any query which returns more than 100 rows, MySQL Workbench completely locks up and I ultimately have to kill the process via Windows Task Manager.

I am running Windows 7 Enterprise 64 bit. The same queries which worked fine in previous versions of MySQL Workbench all crash in 6.3.3.0 Build 593 for me, when the result sets are larger than 100 rows. Result sets larger than 100 rows used to return just fine.

I have tried everything from choosing a different limit from the drop down in the Query Tabs to explicitly specifying a LIMIT XXXX; clause in my queries directly, to changing the Limit Rows threshold in Edit > Preferences > SQL Execution to many different limits, as well as completely turning off the Limit Rows setting globally by unchecking the 'Limit Rows' checkbox.

This is a complete bane, and for any DBA/Developer alike who needs to return a result set larger than 100 rows, basically renders SQL Execution useless.

PLEASE FIX THIS !!!!!!!!!!!!!

Further info continued from my comment above...

The problem does not seem to be related specifically to the number of rows in the result set, but rather the total size of the result set.

For example, I just ran one of my queries, with only one column of type Bigint in the SELECT list, and was able to run the query with a LIMIT of 300, exceeding my previous 'lock up' threshold of 100 rows. However, as soon as I add a few extra columns of type VARCHAR(256) into the SELECT list of the same query, and keep the same LIMIT 300 value, MySQL Workbench locks up again, as expected. 

So there seems to be some problem with the total size of the data packets in the result set being returned exceeding some internal threshold.

I have exactly the same problem with version 6.3.4.0 build 829 (64 bits) on Windows 7 Professional. I did some more research on this problem, because it did not seems like it happened all the time. I think I might have some information which could point you to the problem.

For a project we have 2 MySQL database, one production (5.6.19-0ubuntu0.14.04.1-log), one development (5.1.73-1). The versions do not match, because the production database got upgraded a few months ago. We connect to both servers over TCP/IP over SSH. I just want to provide this info, although I do not think it really matters.

The thing is, when connected to our development server everything seems to be running a lot better. MySQL Workbench crashes a lot less, if at all. The databases on those servers are identical, with one minor difference: the charset. On our development database i'm able to select 50.000 rows without any trouble. As soon as I'm selecting 1.000 rows from exactly the same table on our production server MySQL Workbench hangs. If I interrupt the query, MySQL Workbench crashes.

On our development server the default charset is latin1. Our schema defenition did not contain any charset definition (sadly). On our production server the default charset is utf8. I'm not sure, but I think the problem occurs when selecting data from a table with UTF-8 data.

As Chris Bishop said in comment before, he was able to select a Bigint without any trouble. As soon as he added a varchar to the select query Workbench started crashing. I'm guessing this is a varchar column with UTF-8, maybe he can verify this?

Maybe other users can check and verify as well what type of columns and charsets they are using, and when the problem occurs?

Nice catch Mr Dekker.  The majority of our MySQL databases and tables use either utf8 or utf8mb4.  I am also seeing the same symptom Chris Bishop pointed out - the fewer columns I select, and or if I select 'smaller' columns, I can get more rows before Workbench locks up.

I am having the same issues described here on all versions of 6.3 I've used so far on my windows 7 pc at work.  Currently 6.3.5 build 201 32 bit.  On my home computer running Arch Linux, I can connection to the exact same databases over VPN with no issues at all.  I am also running the same version and build, but 64 bit.  So this bug must be related to either something Windows specific or 32 bit specific.

Is anybody actually looking into this? I see the severity is set to Non-critical, but this bug actually makes MySQL Workbench pretty much unusable for me. I've tried other SQL Editors, but most of do not work as nice as Workbench is (supposed) to work.

Can any of the developers or other people involded in the project give us some feedback? If you need more information (like core dumps, etc.), I could possibly provide the required information.

I just updated to 6.3.5 a couple of weeks ago and noticed that it is crashing at least 10-15 times a day. I previously had 6.2 and it only crashed 1-2 times per day. This bug is NOT fixed and is a critical issue since it makes the program almost useless to use. It seems to happen when I have multiple tabs open and also when I cancel a query. When I cancel a query, it almost crashes 100% of the time.

I can only apply one change per table. If I have more changes, then it crashes every time. The software is unusable for me. Need to revert to an old version. Using 6.3.5 right now.

I've try it but released it is not the workbench instead mysql server itself. My crashes everytime i restard my machine. This so frustrating. Even if i lunch mysql command line the same happens

When I try to add a password to a connection it crashes. Software now useless to me.
One event log:

Faulting application name: MySQLWorkbench.exe, version: 6.3.6.0, time stamp: 0x56698b0d
Faulting module name: grt.dll, version: 0.0.0.0, time stamp: 0x566982c0
Exception code: 0xc0000005
Fault offset: 0x0000000000006b19
Faulting process id: 0x760
Faulting application start time: 0x01d14efad3b934a9
Faulting application path: C:\Program Files\MySQL\MySQL Workbench 6.3 CE\MySQLWorkbench.exe
Faulting module path: C:\Program Files\MySQL\MySQL Workbench 6.3 CE\grt.dll
Report Id: 490cd6c5-48d6-4469-b04c-32a73985a86d
Faulting package full name: 
Faulting package-relative application ID: 

Second error from event log.

Application: MySQLWorkbench.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
   at MformsButton.OnClick(System.EventArgs)
   at System.Windows.Forms.Button.WndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
   at System.Windows.Forms.UnsafeNativeMethods.SendMessage(System.Runtime.InteropServices.HandleRef, Int32, IntPtr, IntPtr)
   at System.Windows.Forms.UnsafeNativeMethods.SendMessage(System.Runtime.InteropServices.HandleRef, Int32, IntPtr, IntPtr)
   at System.Windows.Forms.Control.SendMessage(Int32, IntPtr, IntPtr)
   at System.Windows.Forms.Control.ReflectMessageInternal(IntPtr, System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.Control.WmCommand(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
   at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)
   at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)
   at System.Windows.Forms.NativeWindow.DefWndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32)
   at System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.ButtonBase.WndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.Button.WndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
   at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
   at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
   at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
   at System.Windows.Forms.Form.ShowDialog(System.Windows.Forms.IWin32Window)
   at <Module>.MySQL.Forms.FormWrapper.run_modal(mforms.Form*, mforms.Button*, mforms.Button*)
   at <Module>.mforms.MenuItem.callback(mforms.MenuItem*)
   at <Module>.mforms.MenuItem.callback(mforms.MenuItem*)
   at MenuItemEventTarget.MenuItemClick(System.Object, System.EventArgs)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(System.Object, System.EventArgs)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(System.EventArgs)
   at System.Windows.Forms.ToolStripItem.HandleClick(System.EventArgs)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(System.Windows.Forms.MouseEventArgs)
   at System.Windows.Forms.ToolStrip.OnMouseUp(System.Windows.Forms.MouseEventArgs)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(System.Windows.Forms.MouseEventArgs)
   at System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32)
   at System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.ToolStrip.WndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.ToolStripDropDown.WndProc(System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
   at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
   at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
   at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
   at MySQL.GUI.Workbench.Program.Main(System.String[])

Hopes this points developers in right direction.

This keeps happening to me using version 6.3.6 build 511.  I have managed to use a workaround - if you have an existing connection - and that is to duplicate the existing connection and then reconfigure from there.  It seems to be working for me.  Hope this might help other users, although it doesn't resolve why the issue is occurring in the first place.

Has there still not been a fix for this?

This still happens and it's June 20, 2016 and I use 6.3.6. 

Will a developer please actually respond and look into this? Workbench is utterly useless with this bug.

Please try version 6.3.7. Thanks.

Hi Miguel,

I have downloaded 6.3.7 and it still crashes. The bug still remains.

It looks like it's some sort of "connection lost" handling problem.

We use a VPN to connect to our datacenter.

If i open MySQL Workbench, connect to a MySQL server and IMMEDIATLY execute a query, it will crash most of the time.
Log file will show "09:26:07 [ERR][     AutoCCache]: Exception while running refresh task: Lost connection to MySQL server during query"

However if i wait a few seconds it works.

This NEVER happens with a connection to a local MySQL server (in Office, no VPN).

Maybe the "connection ready" check is not working 100%?

What seems to lower the crash-frequence a little bit is "Use compression protocol".

The crashes can also happen at a later time but it's most noticable when i start Workbench fresh and open a new connection.

I have the same problem on latest MySQL Workbench (6.3.7) on Win 7 64bit and found similar line in log as Christian:

[ERR][     AutoCCache]: Exception while running refresh task: Lost connection to MySQL server during query

So, it is definately related to autocompletion cache (looks like the connection is reset while workbench tries to load data it needs for autocompletion) so as a workaround I disabled autocompletion completely in settings so far it works for me!

I have a same issue with 6.5.7. I could not even run a query. it get crashed frequently when connecting with external server. Horrible to work. Please let me know if you have any fix.

I am on Workbench version 6.3.7 on Mac OSX 10.11.5.  I use workbench primarily to connect to an external server, which is an Amazon RDS instance of mysql, and we use a VPN client to connect to our RDS instance (OpenVPN client on OSX).

My workbench app crashes at least 5-10 times per day.  When this happens, sometimes the app totally quits on its own, other times I have to force quit the app.

Most frequent cause of crashes are:
- Applying the changes after editing one or more values in a single row of a table
- Applying changes when changing fields (adding/removing/updating) of a table
- Applying changes when adding an index to a table (especially for large tables)

In all of these cases, the change I am applying ALWAYS propagates to the external server even when workbench force quits, so my changes are never lost, just very annoying to have the app crash so often.

If anyone needs additional information, I am happy to provide it to help debug.

I have stopped using Workbench, I found the crashing and usage to be unusable. I have tested several platforms and find Heidi to be the best free software out there. I hope this helps.

Based on the comments above, it seems the heading of this bug should be changed, since the problem(s) appear to be OS independent (not just affecting Windows).

Thanks for the info Cody Robinson.  I will take a look at Heidi.  Workbench has become practically unusable for my organization.  I upgraded to 6.3.7 and still experienced the bug although in our case I think it has to do with the fact that we are using UTF8 and UTF8MB4 character sets. We are still having to support Workbench 5.2 since version works for our users.

The amount of time this bug has been unresolved is completely unacceptable. We have an Enterprise Level license which we will very likely not renew when it expires.  Why pay for support when bugs don't get fixed.  Worst case scenario we put a fraction of that money into purchasing SQLYog licenses and we get a stable client app and save money.

Thanks again for the info Cody.

yes it is absolutely useless. tried many alternatives before and settled on nothing so far :(

This affects me too & makes it very difficult for me to work with our remote databases.

Oddly enough though I have other friends running MySQL Workbench that it does not affect: same configuration, same workbench version.

this is horrible and I have not found any good alternative. I don't like navicat. would be ready to pay but not happy with the gui

MySql Workbench v.6.3.7 stop to work very often when I work with a remote database (today 7 times in less than one hour).

I have given up on Workbench and am now using HeidiSQL per a recommendation in this thread. It is actually working quite well and has a nice feature set.  Most importantly it does not lockup on big result sets.  Not sure how support will be but it can't be worse that the support on this bug.

I have the same problem when execute a select query without limit. I use a remote connection to AWS RDS.

I'm using Workbench 6.3.7 on Windows 7 Enterprise.

Crashes very frequently since 6.2 upgrade.  THAT'S A DOWNGRADE REQUIREMENT.

Looses connection frequently too, and doesn't let you know, it just returns cached results.  THAT'S BAD!

http://bugs.mysql.com/bug.php?id=82612 marked as duplicate of this one.

Any update on when/if this will be fixed? Each morning I waste a measurable amount of time waiting for MySQL Workbench to stop crashing after I run simple select statements. Once it stabilizes then all is well.

Stabilizes and then works well? :) Please tell me the secret!
It looks like workbench tries to cache tabs... so instead of "waiting", its faster to open new tabs. At least for me if a query (SELECT * FROM tablewithzerorow eg) crashes, then it crashes every time until I copy the query to a new tab. SSD is recommended for this version (for faster workbench restarts ofc)!

I haven't yet figured out steps to reproduce but I think if I call a few procedures that return result sets and give MySQL Workbench a few minutes I have success and can use it all day long. If I'm impatient and run "select * from <mytable>" as soon as I connect to a database I'm 99.9% sure to get a crash. I wish there were more to go on in the log files.

Same error to me (Windows or Mac). Unbeliaveble no one fixed this yet !!! Hello Oracle ????? Knock Knock !!!

crash on the smallest queries (every 2-3 quires)
windows server 2012 64 bit 
6.3.7 (64 bit)

Crashes constantly on Windows 10, running any type of query it crashes seemingly on every other query; whether on a local or remote DB. Literally unusable at this point.

Here is how I've avoided the crash. These steps might sound weird but they do indeed work for me. I follow them first thing every morning then don't shutdown the app until I'm ready to go home.
1. Connect to the desired DB
2. Wait a bit (say 15 seconds)
3. Run one or two stored procedures that return result sets
4. Wait a bit (same as step 2)
5. Start running queries

I'm shocked that the source of the crash isn't logged in such a way that fixing this bug is hard, but I'm not a Java developer.

Hello Charlie Firth,

Thank you for your feedback.
Could you please send us full stack trace to confirm this issue at our end?
steps to get stack trace:

# Microsoft Windows - Please make sure WB path is adjusted per installation.
C> cd "C:\Program Files (x86)\MySQL\MySQL Workbench CE 6.3.7\"
..> MySQLWorkbench.exe -log-level= debug3

Thanks,
Chiranjeevi

Have same problem, cannot run any query on remote server (aws RDS). Am using workbench 6.3.7 and windows 10. Have run the commands to change debug to level 3 as you suggest but am unsure how to then obtain the stack trace, please advise.

Version 6.3.7 build 1199 CE (32 bits)
Constant crashes when running a query against AWS RDS mysql. Crashes do not occur when running against a local mysql instance. Crashes did not occur with version 5.2

Crashes happen with simple queries, returning less than 100 rows.

Same observations as others, that starting and running queries soon after causes it to crash. Waiting-once it is stable, it tends to stay stable.

I ran with the suggested debug flag. I'll upload the complete file, but these are the last entries:

21:59:46 [DB2][        WQE.net]: Switching main content tab
21:59:46 [DB2][        WQE.net]: Done switching main content tab
21:59:46 [DB3][  GRTDispatcher]: GRT dispatcher, running task execute sql queriesStart splitting
21:59:46 [DB3][   MySQL editor]: Splitting ended after 0.000000 ticks
21:59:47 [ERR][     AutoCCache]: Exception while running refresh task: Lost connection to MySQL server during query

PS This issue really should be marked as critical. Workbench is unusable!

My experience has been more of the same. Frequent crashes from MySQL Workbench. I have identical schema on 3 installations; Amazon, Google and local MySQL servers. Workbench crashes constantly when I'm on the remote servers (MySQl 5.x On Amazon Linux AMI and Ubuntu)...it's fine on the local instance (MySQL 5.x on Windows 10 64 bit). I've had to be using HeidiSQL. I can't imagine why this bug persists after so many updates. Workbench is literally unusable.

Hello  Hans,

Thank you for your feedback.
Could you please provide the configuration file (my.ini/my.cnf) from your environment to test this issue at our end?

Thanks,
Chiranjeevi.

Once I have access to the remote server, if I wait a period of time (approx 10 mins) before executing any queries, then workbench is stable.

AWS RDS does not give you direct access to the config file, only a GUI to edit parameters. 

As far as I know, I am running with the default configuration provided from AWS.

I seriously doubt that it is setting related though. My guess is that it is timing related. Localhost: fast; remote: slower

I wonder if this is possibly related to the protocol used for connection in any way? Folks report that running similar queries against a local copy of a database (looking at this objectively putting latency/bandwith aside in this context, given most people are going to be connecting to remote databases through a pretty big pipe...) work just fine, and conversely the same queries against a remote copy of the database make Workbench crash (all whom commented above to that effect, please feel free to confirm or deny the similarities between your local and remote database's result sets, please). I call this out, because likely when connecting to a local database, most generally one would do this through a socket, whereas when connecting to remote, you would normally at minimum connect over TCP, or SSH Tunnel. Worth considering, I suppose.

Hey Hans 

Just an FYI - AWS doesn't let you access the config file, but they do allow you to override the config variables via DB parameter groups. 

In any case, you can always do a SHOW VARIABLES command in Workbench and get the variable values, which should suffice in place of the config file, as the settings can then be replicated.

With AWS RDS or Aurora, you should also be able to output those variables in json format using the AWS CLI or SDK from another accessbile EC2 instance, or program, in addition to issuing a SHOW VARIABLES statement in Workbench as previously noted. Using the AWS CLI or SDK could help in the event that Workbench crashes so frequently that you can't even issue the DB command within it. See the AWS docs below:

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html

I added a file to this bug, with the output of the "SHOW VARIABLES" command.

John: thanks for pointing out the Show Variables command.

Chris: I connect using TCP/IP, both local as well as to AWS RDS.

Hello  Hans,

Thank you for your feedback.
This is most likely duplicate of Bug #82778, please see Bug #82778.

Thanks,
Chiranjeevi

Hi Chiranjeevi

The link you gave (https://bugs.mysql.com/bug.php?id=82778) is just another bug with a list of duplicates.

Is there a fix?

Thanks.

This bug is no longer assigned to anyone. 

Bug #82778, which is supposedly a duplicate (reported in Aug 2016, while this bug was reported in May 2015), does not have anybody assigned either...

Any suggestions anyone?

Does anyone know which the last stable version of workbench is?

I've never used a stable version, and I've been using Workbench for 4+ years. Good luck with that one!

For remote dbs the most stable is 5.2.5 I think (I downgraded to this and have no problems - I just use the query part, no models). If you dont need keep-alive, then some 6.3.* could work, but dont really sure on that, cause for me all 6.3 were buggero and crashed too many times and always had to downgrade to 5.2.5.

Ha! Thanks, will downgrade, quickest way out of this it seems.

What helps a little bit for me is:
 - after you open a connection
 - open PERFORMANCE - Dashboard
 - keep that tab open

yes Christian Meisinger seems to help

Not helping me. Attempted to get it going 15 times this morning over 20 minutes and finally gave up. Out of sheer frustration I installed 5.2.47 along side my existing install so I could get to work.

I'm running 6.3.7 on two machines (windows 10), was fine until I tried to stop a long query. On that machine the workbench now crashes frequently to the unusable levels.

Yep spoke to soon, now unusable again. Totally random. Installing 5.2.5 now ditching latest release as useless.

I'm having this issue as well.  Has anyone been able to solve it?

The severity of this bug should be raised to Critical

Installed mysql-workbench-community-6.3.7-winx64.msi, it crashed a lot, some queries would work on a restart, but one query would crash all the time (connected to an AWS RDS MySQL server with encryption):
select * from mysql.slow_log

I switched to the 32bit version, did not crash immediately or during first 30 min of use.

MySQL Workbench 6.3.8 has been released today (2016-10-21)

They claim to have fixed the issued: http://dev.mysql.com/doc/relnotes/workbench/en/wb-news-6-3-8.html

Francesco, a much better feedback would have been your confirmation that the problem is gone for you (or not) :-)

Hello - Sorry, I am not seeing an improvement in 6.3.8. Been following this issue for some time. For me, last known good on basic query is v 6.2.5 - tg

Query: SELECT * FROM mydb.items LIMIT 0, 100

W O R K S :
  Using: 
    mysql-workbench-community-6.2.5-winx64.msi

  Message: "Fetching"
  Result: SUCCESS 

F A I L S :
  Using either:
    mysql-workbench-community-6.3.8-winx64.msi
    mysql-workbench-community-6.3.8-win32.msi

  Message: "Running"
  Result: Hangs on very first query to AWS RDS

Hope this is helpful. - TG

Thanks for the feedback. What you are seeing is a different issue we are still working on. There's a problem with paramiko (which we upgraded after 6.2.5) and SSH access to certain servers, most notably Amazon AWS. We are in the process of replacing paramiko to solve this issue. We also need a fix in the C++ connector, so this takes a bit longer than the fix for the plain query crash reported here.

Got it! Thanks Mike. You wouldn't happen to have that bug # handy...? - tg

We first found this problem internally and hence had no public bug report for it, but just recently such a report was created (Bug #81019), so will use this as the main tracker for SSH -> AWS problem.

No crashes so far in 6.3.8. Good job :)

Initial testing against my AWS RDS servers is looking good, so far no crashes.

Seems to be fixed for me

Running 6.3.8 on a Mac. Not working at all. Same on my MacBook Pro and an iMac. Both running the latest OS X 10.12.2 Sierra. Tabs can't be closed, queries don't run, and the app cannot be quit.

I see a reference to another bug report but that does not relate to issues outlined here. Basically, this product does not work. On any level. If you launch it you can not quit it. If you open a tab you cannot close it. If you force quit the application and relaunch your work environment will look the same as before and nothing works. If you reboot the same. Thinking this is a cache issue I deleted the /Users/username/Library/Application Support/MySQL/Workbench. On restart it rebuilt but I lost all my connection settings. However, the same thing happened. This app used to work well. Not anymore.

This bug was on Windows, and now on Windows it works perfectly...  You should open another bug for your Mac issue

Hello to everyone,

I have the same Duane Mitchell issue. I use Workbench 6.3.8 on Mac OS X 10.12.2 but i cannot be quiet relaxed when I work with sql, because every input I lauch can be useful to crash and freeze Workbench. On Mac it doesn't work anymore

Please don't hijack this issue for Windows. There is already a new bug report about the freezes on macOS 10.12 and we are on it already.

I think this could be closed. I use 6.3.8 since it came out and those crashes are gone. Feels very stable. On Windows ofc.

Sorry for the mistake. Can you give me the right bug issue, please?

Thank you in advance

It is actually closed (set to duplicate), but we usually keep also old bugs open. The one about macOS is Bug #83658.

I am using MySQL Workbench 6.3.8 together with WIN 7 64 bit.
I connect to a AWS RDS instance via a bastion host.
Running queries and limiting the output to under 10000 rows is quick and always returns a result. The moment you increase the limit to 1000 and above, MySQL WorkBench hangs in Running... mode and eventually displays Not Responding.

Using SQLDeveloper with MySQL interface (and still using a bastion host) also has hang issues but at least it returns failure messages. eg.

"GC overhead limit exceeded" - when specifying no limit

"Packet for query is too large (4,543,056 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable." - when specifying a high limit