Bug #74390 Huge memory leak when ASCII char 127(dec) is pasted/typed into the editor window
Submitted: 15 Oct 2014 5:54 Modified: 17 Mar 2015 2:06
Reporter: michael plavins Email Updates:
Status: Duplicate Impact on me:
Category:MySQL Workbench: SQL Editor Severity:S5 (Performance)
Version:6.2.3 OS:Windows (Microsoft Windows 7 Enterprise Service Pack 1)
Assigned to: CPU Architecture:Any
Tags: WBBugReporter

[15 Oct 2014 5:54] michael plavins

Huge leak: it claims all memory available - in my case 30GB within less than 10 seconds and Workbench becomes unresponsive.

This is without actually running anything - it seems to be simply the editor trying to parse the ASCII character

Oct	Dec	Hex	Abbr	[a]	[b]	[c]	Name
177	127	7F	DEL	␡	^?		Delete[k][e]

How to repeat:
* Open workbench
* Connect to any server
  (Open a system memory viewer, taskmanager/process explorer etc)
* In the editor window, hold down ALT and type 0127 (on windows anyway)
  (notice memory being consumed until none left)

Note that if there is a comment indicator # before the character, the memory leak does not occur - i.e. if the editor is not trying to parse the sql syntax there is no error/leak
[15 Oct 2014 12:42] MySQL Verification Team
Hello Michael,

Thank you for the report.
Please note that we couldn't repeat this issue when tried on couple of Win7(64bt) boxes and with ALT+0127 or even copying a list of ascii chars...
Could you please check if there is any issue with h/w? Is this happening on all boxes or just one machine? Anything else that help us to trigger this issue?

[16 Oct 2014 1:40] michael plavins

Thanks for testing.

I have repeated on 2 other desktop machines but failed on one laptop.  Note that the ALT method of creating unprintable characters requires you to use the digits on a numberpad, not the top row of digits.  You can see if the character has been created if a small rectangle is produced in the editor rather than nothing.  You can try the same thing with a normal text editor.

Although you may find copying the following to work:
^ In my testing copying that text from this post & pasting will transfer the character between the parenthesis and cause the issue.

I have only found that one ASCII character to cause the issue: DEL (127d 7Fh)
[16 Oct 2014 7:42] MySQL Verification Team
Thank you for the feedback.
Indeed, just copying the the text () into the SQL Editor caused WB/OS to hang for long.

Confirmed on Win7(64) with WB 6.2.3

[16 Oct 2014 13:52] Mike Lischke
Duplicate of Bug #74020.
[17 Mar 2015 2:06] michael plavins
Memory leak still present in Windows v6.2.5.0 build 397 (64 bits).
[13 Apr 2015 19:34] Aaron Newcomer
This is actually even a bigger issue because it is MUCH simpler to trigger.

Keyboard Shortcut [Ctrl]+W closes tab. 

Mistyping that and instead pressing [CTRL]+Q has no associated keyboard shortcut so instead gives me the Ascii control code DC1

[DC1] or any control code in the query window by itself does nothing. However at then end of a query it completely uses all available memory and all available page file until it completely crashes the computer.

To reproduce every time:

in a Query window type in:


then press [Ctrl]+Q

which will change your query to:


Now watch as your HDD starts to smoke as an endless amount of gigabytes get written to your page file.
[19 Apr 2017 12:32] Chris Hafsahl
This bug is still present in Workbench 6.3.9 64-bit on Windows 10 Enterprise, and also on 6.3.3 on Linux. 

To reproduce: Open a new query tab in Workbench, an active connection is not required. Insert a DEL character as described above, and watch Workbench consume all available resources. 

This is a problem, especially if you are dealing with stuff such as binary blobs which haven't been encoded to base64 for various (legacy) reasons.