MySQL Bugs: #74390: Huge memory leak when ASCII char 127(dec) is pasted/typed into the editor window

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:	None
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

Description:

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

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?

Thanks,
Umesh

Hi,

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)

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

Thanks,
Umesh

Duplicate of Bug #74020.

Memory leak still present in Windows v6.2.5.0 build 397 (64 bits).

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:

SELECT 1

then press [Ctrl]+Q

which will change your query to:

SELECT 1[DC1]

Now watch as your HDD starts to smoke as an endless amount of gigabytes get written to your page file.

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.