MySQL Bugs: #55719: Not enough storage available

Bug #55719	Not enough storage available
Submitted:	3 Aug 2010 18:55	Modified:	20 Jun 2011 18:51
Reporter:	Ben Sandberg	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S2 (Serious)
Version:	5.2.28	OS:	Windows (7 x64)
Assigned to:	Mike Lischke	CPU Architecture:	Any

Description:
Working with an EER diagram, the problem "Not enough storage is available to process this command" occurred.

How to repeat:
Unknown.
EER diagram has ~11 tables, with relationships diagrammed.
I was moving objects around the screen to appear in a certain way.

Could you please provide the model file (private if you wish). Thanks in advance.

Please, send the results of Help > System Info menu item.

MySQL Workbench CE for Windows version 5.2.25
Data Directory: C:\Program Files (x86)\MySQL\MySQL Workbench 5.2 CE
Cairo Version: 1.8.8
Rendering Mode: OpenGL is not available on this system, so GDI is used for rendering.
OS: Microsoft Windows 7  (build 7600), 64-bit
CPU: 4x Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz, 3.9 GiB RAM
Video adapter info:
Adapter type: ATI Radeon HD 4650
Chip Type: ATI display adapter (0x9498)
BIOS String: 113-B83401-102
Video Memory: 1048576 KB

I am not able to repeat this.

Also the error message is confusing me.

The error is not thrown from Workbench.
Its not thrown from MySQL server because server always throws errors with a number.

Seems its thrown from your OS.

Did you maybe translated the error message for us? Is the original message in different language?

Did you get it always or was it just one time?

We released Workbench 5.2.26 a few days ago. Please also test if you still get the error by using this version.

I must respectfully disagree.

I have installed 5.2.26, and, while I was unable to replicate the error, I was *not* able to consistently reproduce the error in 5.2.25 either. For example -- when I closed WB and re-opened the very same file, I would not get the error.

However, the error *was* thrown by MySQL WB.  At the time when I was getting the error, it was constantly recurring -- I'd select OK to 'clear' the error notice, and I would receive another, then another - etc.
The dialog was styled, with the WB logo-graphic (it was not a Windows error report).  It seemed to me that in working with a large-ish number of tables (30+) for an extended period (2+ hours) caused this memory overflow.

I understand that you're unable to reproduce the error.
If it comes up again, I will try to be more aware of the steps needed to reproduce, and will provide screenshots.

Verified on Win7 HP x64. Doesn't look like machine is running out of memory, nor out of disk space. More details will be added soon. Issue happened when handling Sakila model and copying/pasting a number of times (ctrl+a/ctrl+c/ctrl+v about 2-3 times), closing the model, re-opening the model, copying/pasting a number of times again, and repeat this (quite a few times, maybe 20 orso)

--------
Exception = System.ComponentModel.Win32
Exception
Message = Not enough storage is available to process this command

FullText = System.ComponentModel.Win32Exception: Not enough storage is available to process this command
   at System.Drawing.BufferedGraphicsContext.CreateCompatibleDIB(IntPtr hdc, IntPtr hpal, Int32 ulWidth, Int32 ulHeight, IntPtr& ppvBits)
   at System.Drawing.BufferedGraphicsContext.CreateBuffer(IntPtr src, Int32 offsetX, Int32 offsetY, Int32 width, Int32 height)
   at System.Drawing.BufferedGraphicsContext.AllocBuffer(Graphics targetGraphics, IntPtr targetDC, Rectangle targetRectangle)
   at System.Drawing.BufferedGraphicsContext.AllocBufferInTempManager(Graphics targetGraphics, IntPtr targetDC, Rectangle targetRectangle)
   at System.Drawing.BufferedGraphicsContext.Allocate(IntPtr targetDC, Rectangle targetRectangle)
   at System.Windows.Forms.Control.WmPaint(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.TabControl.WndProc(Message& m)
   at MySQL.Controls.FlatTabControl.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
--------

Though memory is not fully used it seems, it looks like at least some exhaustion is going on.

Attachment: bug_55719.png (image/png, text), 53.04 KiB.

Backtrace

Attachment: backtrace.txt (text/plain), 29.99 KiB.

See bug #43155: the Windows backtrace is identical, the in-Workbench-trace is different.

See bug #55904: the Windows backtrace is identical, the in-Workbench-trace is different.

Re-upload due to apparent bug in bugs db.

Attachment: Memory_exhaustion_and_cpu_req.png (image/png, text), 94.02 KiB.

Confirmed the following:

#1 There is memory exhaustion happening where there shouldn't be.
#2 There is an increased requirement for CPU power where there shouldn't be.

This operation: [open Sakila model, open eer diagram if not open already, 3 times ctrl+a/ctrl+c/ctrl+v, ctrl+w, ctrl+w, don't save] repeated 20-30 times should not cause memory exhaustion, nor increase cpu power requirements. It does (see last attached image above).

Increased processing time (cpu power) requirements: (this is measuring the third paste):

WBCTSEND: ControlSend(0x0046185A,EER Diagram,[NAME:mainMenuStrip],^v)
Waiting for WorkBench to finish [Additional: 10191msec]
WBCTSEND: ControlSend(0x0046185A,EER Diagram,[NAME:mainMenuStrip],^v)
Waiting for WorkBench to finish [Additional: 10562msec]
WBCTSEND: ControlSend(0x0046185A,EER Diagram,[NAME:mainMenuStrip],^v)
Waiting for WorkBench to finish [Additional: 11290msec]
WBCTSEND: ControlSend(0x0046185A,EER Diagram,[NAME:mainMenuStrip],^v)
Waiting for WorkBench to finish [Additional: 11591msec]
WBCTSEND: ControlSend(0x0046185A,EER Diagram,[NAME:mainMenuStrip],^v)
Waiting for WorkBench to finish [Additional: 12035msec]

Ben,

did the error happen while doing copy/paste? Did you use copy/paste often in the times you
repeated that error? Or did it always happen while you were arranging tables/objects in the diagram?

I *may* have performed a Copy & Paste operation, but if so, it wasn't more than a few times.  This issue centers mostly around complex diagrams.

Ben, also, the next time this happens, please copy a stack trace for us as follows:

In the "MySQL Workbench Unexpected Error" popup window, right-click on "MySQL Workbench has encountered a problem" (or on the error message directly below it), and select "Copy stack trace to clipboard". Then paste (CTRL+V) it into a comment in this bug.

will do.

Issue is easy to reproduce, and can be reproduced in many ways. Any transaction on the EER model will consume memory. For instance: looping the following: "auto arrange" > "undo" > "auto arrange" > "undo" etc. will cause memory exhaustion also. I also noticed the number of GDI objects kept increasing during the testing ( see http://msdn.microsoft.com/en-us/library/ms724291%28VS.85%29.aspx ).

Sorry that I haven't had diagnostic data yet -- work has kept me busy in other ways...

What Roel is saying about Auto Arrange -> Undo (repeat) -- I did this many times, trying to get a diagram layout that I was happy with.

Nice video, Roel.  Very good example of what I'm experiencing. (thanks!)

After investigation, this seems to be a similar issue to bug #46101
The ToolStripTextEntry control leaks a font GDI object every time the toolbar is refreshed.

Alfredo, I am seeing very large leaks of GDI objects when (from a freshly started WorkBench) opening the model editor and closing it. For instance, on creating a new (blank) model approx. 150-180 GDI objects are created, and most of these are not released when the model is closed. This seems quite significant (as per bug #46101). Should I report a new bug for this or rather re-open bug #46101 ?

I've also noticed the leaks when opening/closing the model. We will try to fix or at least reduce their count, but since it can be a very time consuming task, I'll be happy if we can just reduce their count. Opening/closing models does not happen very often, so it's not as critical as leaks that happen with very common tasks such as arranging the model or editing objects.

bug #56873 and bug #56896 are duplicates

I have encountered the same problem in the EER Diagram.  From the trail of this bug report, it is likely because of memory leak. I have this problem in Windows 7 x64 bit ultimate.

Around 30 tables with foreign key relationship.

Noted in 5.2.34 changelog.

A memory leak occurred during diagram manipulation.