Posted 13 years ago by Korchagin Andrej
Avatar
Hi. We bumps into real problem. If one open sample project and just clicks root menu, for instance "File", USER and GDI objects grow without limits. When number of GDI objects reach 10000, application crash completely. We just shipped our software, and have a problem with that memory leakage. That's really urgent to us. Thanks!

Comments (6)

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Thanks for the report. This seems to be a .NET Framework bug. I've been working the past several hours on it. What is happening is that something in the framework is retaining a reference to an Icon on the menu popup forms. So each time you open a menu, a popup form is created behind the scenes, and something in Microsoft's code is retaining the Form.Icon reference in memory.

We have even been able to duplicate this bug with a regular Form like with this code:
Form f = new Form();
f.Show();
f.Close();
f.Dispose();
If you run that and check the user handles with a memory profiler, you'll see that an HICON is still referenced!

Oddly enough if you change the code to this, it doesn't retain any HICONs:
Form f = new Form();
f.FormBorderStyle = System.Windows.Forms.FormBorderStyle.FixedDialog;
f.Show();
f.Close();
f.Dispose();
So it seems like unless you use a FixedDialog, any Form you create in Windows Forms has a memory leak. I have been scouring the Internet for reports of this but am not finding much of anything.

Since our popup forms for the menus are being created often, that's why you see the resources going up.

We also located a second place that is a similar issue. When drawing the child MDI form's icon on the main menu bar, we are leaking there too. And again, it's not our code but is something internal to the .NET Framework.

Our code for that part is here:
// Need to do this to get the correct icon color depth
Icon icon = new Icon(form.Icon, bounds.Width, bounds.Height);
e.Graphics.DrawIcon(icon, bounds);
icon.Dispose();
We have to create a new Icon from the Form.Icon otherwise, we get the 32x32 size icon and not the 16x16 one and this is the only way we've found to get that size part of icon. As you can see we are properly disposing the icon but when you profile it, something in the framework is still retaining a reference to it.

Has anyone else run across these issues? We'll continue to try and come up with a way around them. Perhaps for the first one, we will have to change our code to retain the popup forms in memory instead of getting rid of them after the menus are closed. For the second one, we need to find a way to get the 16x16 size part of an icon so if anyone knows of another way to do it, please post how.


Actipro Software Support

Posted 13 years ago by Korchagin Andrej
Avatar
We tryed to reproduce leakage with regular Form. We don't use any memory profiler, but simple Windows Task Manager. And there is no growth of resources.
public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }
        int counter = 0;

    private void label1_Paint(object sender, PaintEventArgs e)
    {
        Icon icon = new Icon(this.Icon, 32, 32);
        e.Graphics.DrawIcon(icon, 0, 0);
        icon.Dispose();
        e.Graphics.DrawString(counter.ToString(), this.Font, SystemBrushes.WindowText, 1, 33);
            counter++;
    }

    private void timer1_Tick(object sender, EventArgs e)
    {
        this.Invalidate();
        label1.Invalidate();
        Form f = new Form();
        f.Show();
        f.Close();
        f.Dispose();
    }
}
May be you send us exactly how we can reproduce this. Thanks for your endeavour.

[Modified at 10/24/2006 05:42 AM]
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
I was thinking about this last night and was going to try the regular TaskMan approach today as well. We are using a beta of a profiler application (at memprofiler.com) that now does unmanaged resource tracking like HICON instances, etc. We have used their 2.x versions in the past which were for profiling managed code and we highly recommend the product. Their new 3.0 version adds unmanaged resource tracking but perhaps there are still some bugs in that tracking. :)

It's hard to believe that creating a simple Form would not release the HICON however when googling it yesterday I did see several reports of odd things similar to that where internally an HICON to a small icon is tracked by the Form and in certain circumstances not released.

We did make a couple other changes yesterday. Today we'll try and use regular old TaskMan to see if those changes helped resolve anything. That should also tell us if the beta profiler we're using still needs some work.


Actipro Software Support

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Ok, I'm now using both Task Manager and the PerfMon application. In Task Manager I'm looking at total handles. In PerfMon I loaded a counter for "Process/Handle Count".

I both cases I'm not seeing either one go up when running our main Bar sample and am clicking/hovering all over the place. Based on this information it appears the beta memory profiler we were using yesterday still needs some work in regards to monitoring handles.

Could you please give exact steps on what you are monitoring in our sample and what you are clicking/seeing that makes you think there is a memory leak?


Actipro Software Support

Posted 13 years ago by Korchagin Andrej
Avatar
Yes, int Task Manager you should look at USER and GDI Objects, and not click/hover all over the place, but simple click on "File" menu. Im sending you short swf clip showing the case. Pay attention to the right number showing GDI objects, when it reach 10000, application crashes. Thanks.
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
I see now, we were using a slightly different thing to measure in Taskman. This should now be fixed for the next maintenance release. We'll try and get it out shortly. It has a bunch of other great new enhancements as well.


Actipro Software Support

The latest build of this product (v2020.1 build 0400) was released 9 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.