MySQL Bugs: #65264: Workbench on Kubuntu is unusable after memory usage runs wild

Bug #65264	Workbench on Kubuntu is unusable after memory usage runs wild
Submitted:	9 May 2012 15:55	Modified:	5 Jul 2012 13:29
Reporter:	Sean Madsen	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S1 (Critical)
Version:	5.2.40	OS:	Linux (Ubuntu)
Assigned to:		CPU Architecture:	Any

Description:
1. Open Workbench
2. Using a system monitor, observe Workbench memory usage around 23 MB (good)
3. Execute a query that produces some results, like "select 7;"
4. Execute the same query a second time.
5. Observe memory is still the same (good). Everything is fine.
6. Execute the same query a third time.
7. Observe memory usage has now doubled! Everything still works though.
8. Execute the same query a fourth time.
9. Watch memory usage spiral out of control. On my system it reaches 1 GB in about 3 seconds. At this point Workbench will become unusable, and if you don't kill it soon, you might not be able to without a full hard reset on the machine! Big problem!

Running Workbench from the command line doesn't give much output except for the following message the first three times the query is executed:

(mysql-workbench-bin:14658): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `node != NULL' failed

I have the same behavior when using the latest 5.2.39 directly from mysql website as well as the 5.2.38 version from the Ubuntu repos. I've also deleted my ~/.mysql/workbench folder to clear out any personal settings that might be causing this issue. No luck.

The issue happens regardless of what database I have set as default.

The issue happens regardless of what connection I'm using -- local or remote.

As a workaround, I've tried playing around with opening a new tab to execute each new query. This buys me a few more queries before the problem arises, but it still happens.

Note that the problem does not arise when executing queries that do not produce results.

Here is the output of "Help" > "System info" :

MySQL Workbench CE for Linux/Unix version 5.2.38 revision 8753
Configuration Directory: /home/sean/.mysql/workbench
Data Directory: /usr/share/mysql-workbench
Cairo Version: 1.10.2
OS: Linux 3.2.0-24-generic-pae
CPU: 2x Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20Ghz 1200.000 Mhz, 3.8 GB RAM

Also I'm running in a KDE environment with Kubuntu, if that matters. It's Kubuntu 12.04. This problem happened to me when running 11.10 also though.

How to repeat:
1. Open Workbench
2. Using a system monitor, observe Workbench memory usage around 23 MB (good)
3. Execute a query that produces some results, like "select 7;"
4. Execute the same query a second time.
5. Observe memory is still the same (good). Everything is fine.
6. Execute the same query a third time.
7. Observe memory usage has now doubled! Everything still works though.
8. Execute the same query a fourth time.
9. Watch memory usage spiral out of control. On my system it reaches 1 GB in about 3 seconds. At this point Workbench will become unusable, and if you don't kill it soon, you might not be able to without a full hard reset on the machine! Big problem!

I couldn't repeat the described behavior on Centos 6.2 X86_64 running on VirtualBox. From 23 MB and doing several queries the memory is between 28-30 MB.

Tried reproducing on a vanilla Ubuntu install (without KDE) and I can not reproduce. 

Are any other Kubuntu or KDE users experiencing this problem?

I'm still able to reproduce by running Workbench from a blank environment with a totally new user, so I don't imagine this bug has to do with any of my personal settings. 

Is there anything else I can try to help identify what is causing this strange behavior? 

I really want to have Workbench back! I'm stuck using emma which is so inferior!

Hello Sean,

Can you please try with the newest version http://www.mysql.com/downloads/workbench/
and let us know if you could reproduce the bug?

Thanks in advance!

Thanks Rafael! 

I've tried the latest 5.2.40 version and I'm still experiencing just about the same behavior :( No luck. 

The one difference is that instead of the memory going wild after 4 query executions, now it takes 5 query executions. Interesting.

Duplicate of bug #64077