MySQL Bugs: #77286: Workbench crashes when updating objects through the gui

Bug #77286	Workbench crashes when updating objects through the gui
Submitted:	9 Jun 2015 20:08	Modified:	24 Jan 2017 18:17
Reporter:	Andrew Jurgenson	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S2 (Serious)
Version:	6.3.3.0 /6.3.4	OS:	MacOS (10.10.3 Yosemite)
Assigned to:		CPU Architecture:	Any

Description:
I am plagued by crashes of workbench when using the GUI tools for modifying objects or data in a database. 
For example, if I run a select on a table then update cells in the result set, Workbench will crash - usually on the second modification. 

There seems to be some correlation with the size of the table and the limit on rows returned. i.e. for a table with just a few columns and 100 rows it doesn't happen at all. If the table has 20 columns and several thousand rows it happens with a row limit of 10000 but not when the row limit is 100. 

I have no problems if I write sql to make the changes. 

How to repeat:
set row limit to 10000
select from a table with 5,000 rows and 20 columns. 
In the result set modify a field
Apply the change
In the result set modify the same field. 
Apply the change
Crash

Thank you for the bug report. Please provide the output of show create table table_name (table_name the real name of the table you are using) and print here the output of Help->System Info i.e:

MySQL Workbench Community (GPL) for Mac OS X version 6.3.3  revision 0 build 592 (32 bit)
Configuration Directory: /Users/miguel/Library/Application Support/MySQL/Workbench
Data Directory: /Volumes/MySQL Workbench/MySQLWorkbench.app/Contents/Resources
Cairo Version: 1.10.2
OS: OS X 10.10.x Yosemite
CPU: 4x Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz - 16.00GiB RAM

Here is the system info output:

Thread started
MySQL Workbench Community (GPL) for Mac OS X version 6.3.3  revision 0 build 592 (32 bit)
Configuration Directory: /Users/andrew/Library/Application Support/MySQL/Workbench
Data Directory: /Applications/MySQLWorkbench.app/Contents/Resources
Cairo Version: 1.10.2
OS: OS X 10.10.x Yosemite
CPU: 4x Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz - 32.00GiB RAM

Call Stack

Attachment: call_stack_bug77286.txt (text/plain), 96.20 KiB.

Thank you for the feedback. Verified as described.

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

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

Similar issue with configuration:
MySQL Workbench Community (GPL) for Windows version 6.3.4  revision 0 build 828 (64 bit)
Configuration Directory: C:\Users\Me\AppData\Roaming\MySQL\Workbench
Data Directory: C:\Program Files\MySQL\MySQL Workbench 6.3 CE
Cairo Version: 1.10.2
OS: Microsoft Windows 7 Enterprise Service Pack 1
CPU: 4x Intel(R) Core(TM) i5-4310M CPU @ 2.70GHz, 7.9 GiB RAM
Installed video RAM: 0 MB
Current video mode: 1680 x 1050 x 4294967296 colores
Used bit depth: 32
Driver version: 9.1.0.0
Installed display drivers: NULL
Current user language: Catalán (Catalán)

Still occurs in 6.3.5

Attachment: Workbench Call Stack 77286.txt (text/plain), 107.44 KiB.

bug 80130 is a duplicate of this one

One observation I have made shortly before a crash occurs is that the state of Workbench appears "confused."

To try and clarify, when running a query in the SQL Editor that meets necessary conditions for editing via the result set grid (has a PK, etc), Workbench will _mistakenly_ start reporting the result status as "Read-Only" 

I have seen this time and time again. I will be performing edits, and with little to no change in the query itself, suddenly I cannot perform edits per the false report of "read only" ...almost guaranteed, once Workbench has entered this "state", the next Result Set / GUI update will crash WB.

How close are we to a solution for this serious issue?

NOTE: This also affects latest GA v6.3.6.

MySQL Workbench Crash on OS X El Capitan

Attachment: MySQL Crash Log.rtf (text/rtf), 96.52 KiB.

Still happens on 6.3.6

I think I am getting the same bug. When I try to make changes via the Workbench GUI the GUI crashes. It happens more often with my larger tables, and setting the limit on rows to a smaller number (200 or less on the tables with 20+ columns) I can get it to work most of the time. I attached a crash log from OS X on this event.

Workbench crashing like this occurs multiple times a day for me, every day.

It is unfortunate because it is such incredible software enabling us the way that it does (when it works), but over the course of the last year, it has become the most reliably unreliable tool in my work belt.

Beyond submitting crash reports, I just wish there was something more we could do to help expedite a solution.

Totally agree, when new updates come out, am always very surprised a serious bug like this is not fixed, and, lesser ones are.

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

Looking forward to the next bug fix release!

The Workbench team confirmed today a fix for this issue has been reached: https://twitter.com/MySQLWorkbench/status/720149373578043392?s=09

That's great. I'm crossing fingers that this fix is something deep in there that and will also remedy all the other ways it's possible to make this thing crash.

When is this bug fix going to be release?  This is extremely frustrating to wait over a year for a fix.  If you have a fix, please push it out.

This application crashes on my about 4-10 times per day.

v6.3.7 was released today! Crossing my fingers. http://mysqlworkbench.org/2016/06/mysql-workbench-6-3-7-ga-has-been-released/

Changelog: https://dev.mysql.com/doc/relnotes/workbench/en/wb-news-6-3-7.html

Not sure which log entry specifically applies to this one, but it's supposedly been addressed.

I'm sorry, but the fix for this bug didn't make it through QA. So, I'm afraid this has to wait for the next release. Alternatively, WB is open source software and we are accepting patches via Github.

Ok, great.  I won't be waiting another year for a fix.  I can't recall a less reliable application in recent memory.  I'm done with WorkBench.

Is this perhaps fixed for upcoming 7.0.0 (RC1) ashtray, and just not applicable to 6.3.x?

What was the fix that "did not pass"? This would suggest the source problem was perhaps already identified somewhere, perhaps that is available for review somewhere (GitHub)?

If this can be shared with the community, there is a greater chance someone may be able to fix it than them having to start from scratch.

Please give us hope.

Oops, typo: ashtray = already

Yeah, I basically heard from Mike Lischke: "The fix didn't work, you can start from scratch with no information and try to fix it yourself"

Very helpful!

Posted by developer:
 
Fixed as of the upcoming MySQL Workbench 6.3.9 release, and here's the changelog entry:

Some routine database operations caused MySQL Workbench to fail and exit
intermittently.

Thank you for the bug report.

This is once again happening.  (Mac OS 10.14.1 using Workbench 8.0.13)

This bug remains on Mac iOS Mojave v10.14.2 and Workbench v8.0.13 (build 13780177 CE 64 bit).

- Updating data using the GUI result grid crashes workbench.
- Data is updated in the database, despite of the crash

This bug remains on Mac iOS Mojave v10.14.2 and Workbench v8.0.13 (build 13780177 CE 64 bit).

- Updating data using the GUI result grid crashes workbench.
- Data is updated in the database, despite of the crash