472,090 Members | 1,270 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

home > topics > c# / c sharp > questions > over 4297000000 of gdi objects in a windows.forms application! listview's leak.

Join Bytes to post your question to a community of 472,090 software developers and data experts.

over 4297000000 of GDI objects in a Windows.Forms application! ListView's leak.

today we've found a critical issue regarding the ListView from
Windows.Forms. it was confirmed on several machines with Win2K and XP.

here's the problem: create a ListView with about 50000 rows. now use task
manager to see the GDI usage of the process. everything seems normal.

now catch the ListView's scroller and start to move it downwards. you have
to hold the constant speed so that the ListView is constantly repainted.
look at the GDI usage of the application. it starts to increase, starting at
21 and going through 1000-5000. if you get the bottom of the ListView,
immediately start to scroll it upwards so that the ListView is constantly
repainted. you'll see that the GDI objects count reaches the 10000 and then
jumps to over 4297000000! remember to keep the scrolling speed!

running from the IDE can even make the Windows GDI subsystem completely
broken and hang the whole system (this is what our application does when it
is misused!).

here's the simple code. compile it, press the button "button 1" and watch
the GDI usage.

in the attachment I've included the snapshot of the Task Manager showing the
GDI usage. I am really desperate to hear from anyone about that. could
anyone confirm the problem or point my mistake?

Regards,
Wiktor
-----------------------------------------------------
using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

namespace vicTestF
{
public class Form1 : System.Windows.Forms.Form
{
private System.Windows.Forms.ListView listView1;
private System.Windows.Forms.ColumnHeader columnHeader1;
private System.Windows.Forms.ColumnHeader columnHeader2;
private System.Windows.Forms.ColumnHeader columnHeader3;
private System.Windows.Forms.Button button1;
private System.ComponentModel.Container components = null;

public Form1()
{
InitializeComponent();
}

protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}

#region Windows Form Designer generated code
private void InitializeComponent()
{
this.listView1 = new System.Windows.Forms.ListView();
this.columnHeader1 = new System.Windows.Forms.ColumnHeader();
this.columnHeader2 = new System.Windows.Forms.ColumnHeader();
this.columnHeader3 = new System.Windows.Forms.ColumnHeader();
this.button1 = new System.Windows.Forms.Button();
this.SuspendLayout();
//
// listView1
//
this.listView1.Columns.AddRange(new System.Windows.Forms.ColumnHeader[] {
this.columnHeader1,
this.columnHeader2,
this.columnHeader3});
this.listView1.Dock = System.Windows.Forms.DockStyle.Fill;
this.listView1.GridLines = true;
this.listView1.Location = new System.Drawing.Point(0, 32);
this.listView1.Name = "listView1";
this.listView1.Size = new System.Drawing.Size(496, 289);
this.listView1.TabIndex = 0;
this.listView1.View = System.Windows.Forms.View.Details;
//
// columnHeader1
//
this.columnHeader1.Width = 143;
//
// columnHeader2
//
this.columnHeader2.Width = 115;
//
// columnHeader3
//
this.columnHeader3.Width = 229;
//
// button1
//
this.button1.Dock = System.Windows.Forms.DockStyle.Top;
this.button1.Name = "button1";
this.button1.Size = new System.Drawing.Size(496, 32);
this.button1.TabIndex = 1;
this.button1.Text = "button1";
this.button1.Click += new System.EventHandler(this.button1_Click);
//
// Form1
//
this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
this.ClientSize = new System.Drawing.Size(496, 321);
this.Controls.AddRange(new System.Windows.Forms.Control[] {
this.listView1,
this.button1});
this.Name = "Form1";
this.Text = "Form1";
this.ResumeLayout(false);

}
#endregion

[STAThread]
static void Main()
{
Application.Run(new Form1());
}

private void button1_Click(object sender, System.EventArgs e)
{
listView1.BeginUpdate();

ListViewItem li;
for ( int i=0; i<50000; i++ )
{
// ListViewItem li = listView1.Items.Add( "item" + i.ToString() );
li = listView1.Items.Add( "item" + i.ToString() );
li.SubItems.Add( "qwer" );
li.SubItems.Add( "qwer" );
}

MessageBox.Show( "before endupdate" );
listView1.EndUpdate();
}
}
}



Nov 15 '05 #1
15 3672
Well I dont know exactly whats going on here although you should probably
download a profiler and see exactly what is being used by your program.
Either way, 50,000 rows if far more than you should ever consider putting
into a ListView! No user is ever going to be able to take in all of these!

HTH
Kieran

"Wiktor Zychla" <ie****@microsoft.com.no.spam> wrote in message
news:%2*****************@TK2MSFTNGP09.phx.gbl...
today we've found a critical issue regarding the ListView from
Windows.Forms. it was confirmed on several machines with Win2K and XP.

here's the problem: create a ListView with about 50000 rows. now use task
manager to see the GDI usage of the process. everything seems normal.

now catch the ListView's scroller and start to move it downwards. you have
to hold the constant speed so that the ListView is constantly repainted.
look at the GDI usage of the application. it starts to increase, starting at 21 and going through 1000-5000. if you get the bottom of the ListView,
immediately start to scroll it upwards so that the ListView is constantly
repainted. you'll see that the GDI objects count reaches the 10000 and then jumps to over 4297000000! remember to keep the scrolling speed!

running from the IDE can even make the Windows GDI subsystem completely
broken and hang the whole system (this is what our application does when it is misused!).

here's the simple code. compile it, press the button "button 1" and watch
the GDI usage.

in the attachment I've included the snapshot of the Task Manager showing the GDI usage. I am really desperate to hear from anyone about that. could
anyone confirm the problem or point my mistake?

Regards,
Wiktor
-----------------------------------------------------
using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

namespace vicTestF
{
public class Form1 : System.Windows.Forms.Form
{
private System.Windows.Forms.ListView listView1;
private System.Windows.Forms.ColumnHeader columnHeader1;
private System.Windows.Forms.ColumnHeader columnHeader2;
private System.Windows.Forms.ColumnHeader columnHeader3;
private System.Windows.Forms.Button button1;
private System.ComponentModel.Container components = null;

public Form1()
{
InitializeComponent();
}

protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}

#region Windows Form Designer generated code
private void InitializeComponent()
{
this.listView1 = new System.Windows.Forms.ListView();
this.columnHeader1 = new System.Windows.Forms.ColumnHeader();
this.columnHeader2 = new System.Windows.Forms.ColumnHeader();
this.columnHeader3 = new System.Windows.Forms.ColumnHeader();
this.button1 = new System.Windows.Forms.Button();
this.SuspendLayout();
//
// listView1
//
this.listView1.Columns.AddRange(new System.Windows.Forms.ColumnHeader[] { this.columnHeader1,
this.columnHeader2,
this.columnHeader3});
this.listView1.Dock = System.Windows.Forms.DockStyle.Fill;
this.listView1.GridLines = true;
this.listView1.Location = new System.Drawing.Point(0, 32);
this.listView1.Name = "listView1";
this.listView1.Size = new System.Drawing.Size(496, 289);
this.listView1.TabIndex = 0;
this.listView1.View = System.Windows.Forms.View.Details;
//
// columnHeader1
//
this.columnHeader1.Width = 143;
//
// columnHeader2
//
this.columnHeader2.Width = 115;
//
// columnHeader3
//
this.columnHeader3.Width = 229;
//
// button1
//
this.button1.Dock = System.Windows.Forms.DockStyle.Top;
this.button1.Name = "button1";
this.button1.Size = new System.Drawing.Size(496, 32);
this.button1.TabIndex = 1;
this.button1.Text = "button1";
this.button1.Click += new System.EventHandler(this.button1_Click);
//
// Form1
//
this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
this.ClientSize = new System.Drawing.Size(496, 321);
this.Controls.AddRange(new System.Windows.Forms.Control[] {
this.listView1,
this.button1});
this.Name = "Form1";
this.Text = "Form1";
this.ResumeLayout(false);

}
#endregion

[STAThread]
static void Main()
{
Application.Run(new Form1());
}

private void button1_Click(object sender, System.EventArgs e)
{
listView1.BeginUpdate();

ListViewItem li;
for ( int i=0; i<50000; i++ )
{
// ListViewItem li = listView1.Items.Add( "item" + i.ToString() );
li = listView1.Items.Add( "item" + i.ToString() );
li.SubItems.Add( "qwer" );
li.SubItems.Add( "qwer" );
}

MessageBox.Show( "before endupdate" );
listView1.EndUpdate();
}
}
}


Nov 15 '05 #2
> Either way, 50,000 rows if far more than you should ever consider putting
into a ListView! No user is ever going to be able to take in all of these!


it also happens when you have 2000 items or even a 1000. this IS a
reasonable count. 50000 was only an example!

just try it and help me explain it if you can. the problem DOES NOT OCCUR if
you do the same in old VB for example. so it is a Windows.Forms issue.
Nov 15 '05 #3
You probably run the debug version, can you check this in release mode.

Willy.

"Wiktor Zychla" <ie****@microsoft.com.no.spam> wrote in message news:%2*****************@TK2MSFTNGP09.phx.gbl...
today we've found a critical issue regarding the ListView from
Windows.Forms. it was confirmed on several machines with Win2K and XP.

here's the problem: create a ListView with about 50000 rows. now use task
manager to see the GDI usage of the process. everything seems normal.

now catch the ListView's scroller and start to move it downwards. you have
to hold the constant speed so that the ListView is constantly repainted.
look at the GDI usage of the application. it starts to increase, starting at
21 and going through 1000-5000. if you get the bottom of the ListView,
immediately start to scroll it upwards so that the ListView is constantly
repainted. you'll see that the GDI objects count reaches the 10000 and then
jumps to over 4297000000! remember to keep the scrolling speed!

running from the IDE can even make the Windows GDI subsystem completely
broken and hang the whole system (this is what our application does when it
is misused!).

here's the simple code. compile it, press the button "button 1" and watch
the GDI usage.

in the attachment I've included the snapshot of the Task Manager showing the
GDI usage. I am really desperate to hear from anyone about that. could
anyone confirm the problem or point my mistake?

Regards,
Wiktor
-----------------------------------------------------
using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

namespace vicTestF
{
public class Form1 : System.Windows.Forms.Form
{
private System.Windows.Forms.ListView listView1;
private System.Windows.Forms.ColumnHeader columnHeader1;
private System.Windows.Forms.ColumnHeader columnHeader2;
private System.Windows.Forms.ColumnHeader columnHeader3;
private System.Windows.Forms.Button button1;
private System.ComponentModel.Container components = null;

public Form1()
{
InitializeComponent();
}

protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}

#region Windows Form Designer generated code
private void InitializeComponent()
{
this.listView1 = new System.Windows.Forms.ListView();
this.columnHeader1 = new System.Windows.Forms.ColumnHeader();
this.columnHeader2 = new System.Windows.Forms.ColumnHeader();
this.columnHeader3 = new System.Windows.Forms.ColumnHeader();
this.button1 = new System.Windows.Forms.Button();
this.SuspendLayout();
//
// listView1
//
this.listView1.Columns.AddRange(new System.Windows.Forms.ColumnHeader[] {
this.columnHeader1,
this.columnHeader2,
this.columnHeader3});
this.listView1.Dock = System.Windows.Forms.DockStyle.Fill;
this.listView1.GridLines = true;
this.listView1.Location = new System.Drawing.Point(0, 32);
this.listView1.Name = "listView1";
this.listView1.Size = new System.Drawing.Size(496, 289);
this.listView1.TabIndex = 0;
this.listView1.View = System.Windows.Forms.View.Details;
//
// columnHeader1
//
this.columnHeader1.Width = 143;
//
// columnHeader2
//
this.columnHeader2.Width = 115;
//
// columnHeader3
//
this.columnHeader3.Width = 229;
//
// button1
//
this.button1.Dock = System.Windows.Forms.DockStyle.Top;
this.button1.Name = "button1";
this.button1.Size = new System.Drawing.Size(496, 32);
this.button1.TabIndex = 1;
this.button1.Text = "button1";
this.button1.Click += new System.EventHandler(this.button1_Click);
//
// Form1
//
this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
this.ClientSize = new System.Drawing.Size(496, 321);
this.Controls.AddRange(new System.Windows.Forms.Control[] {
this.listView1,
this.button1});
this.Name = "Form1";
this.Text = "Form1";
this.ResumeLayout(false);

}
#endregion

[STAThread]
static void Main()
{
Application.Run(new Form1());
}

private void button1_Click(object sender, System.EventArgs e)
{
listView1.BeginUpdate();

ListViewItem li;
for ( int i=0; i<50000; i++ )
{
// ListViewItem li = listView1.Items.Add( "item" + i.ToString() );
li = listView1.Items.Add( "item" + i.ToString() );
li.SubItems.Add( "qwer" );
li.SubItems.Add( "qwer" );
}

MessageBox.Show( "before endupdate" );
listView1.EndUpdate();
}
}
}


Nov 15 '05 #4
Sorry Wiktor but I can't reproduce this on my .NET 1.1 machine, what version
are you using? Task manager reports just 4 GDI objects no matter how
fast/slow I scroll. Memory usage (At least as reported by TM) goes up but
this is to be expected and is absolutely normal. Jsut tried it on a 128Mb
machine as well and performance was still adequate.

Kieran

"Wiktor Zychla" <ie****@microsoft.com.no.spam> wrote in message
news:u%****************@TK2MSFTNGP11.phx.gbl...
Either way, 50,000 rows if far more than you should ever consider putting into a ListView! No user is ever going to be able to take in all of
these!
it also happens when you have 2000 items or even a 1000. this IS a
reasonable count. 50000 was only an example!

just try it and help me explain it if you can. the problem DOES NOT OCCUR if you do the same in old VB for example. so it is a Windows.Forms issue.

Nov 15 '05 #5
> You probably run the debug version, can you check this in release mode.

Willy, I've checked some compiler swiches (/debug+, /debug-) and it does not
help.
Nov 15 '05 #6
Check without /debug (debug+ or /debug- both generate a debug version).
I checked with your sample and the phenomenon you describe only occurs when a debug build is run. Note that the value 429700000 is
completely bogus, the max. number of GDI objects per process is 16384.

Willy.

"Wiktor Zychla" <ie****@microsoft.com.no.spam> wrote in message news:%2****************@tk2msftngp13.phx.gbl...
You probably run the debug version, can you check this in release mode.


Willy, I've checked some compiler swiches (/debug+, /debug-) and it does not
help.

Nov 15 '05 #7
> I checked with your sample and the phenomenon you describe only occurs
when a debug build is run. Note that the value 429700000 is
completely bogus, the max. number of GDI objects per process is 16384.


alas, it happens to me on both debug and release build of the application.
anyway, isn't it a bug then? it does not happen with the ListView itself -
I've checked the same code with VB6.0 and there's no problem there.

I think that the number 4297000000 could be a 16-bit negative value (given
by the system) converted to 32-bit unsigned value (seen by TM). it would
explain why I get the number just after 10000.

Regards, Wiktor
Nov 15 '05 #8
Wiktor,
Weird, I'm running your sample on XP using version 1.1 of the .NET runtime, running the release version I noticed the GDI handle
count going up to ~2000 starting from ~70 and dropping regularly to ~70 after a CG run. The debug build shows a different pattern,
just because non managed resources are not reclaimed so aggressively, this is considered normal behavior not a bug.
However, the TM GDI object counter seems to bug out when exceeding 10000.

What version of the framework of the runtime are you running on?

Willy.

"Wiktor Zychla" <ie****@microsoft.com.no.spam> wrote in message news:e7**************@TK2MSFTNGP11.phx.gbl...
I checked with your sample and the phenomenon you describe only occurs

when a debug build is run. Note that the value 429700000 is
completely bogus, the max. number of GDI objects per process is 16384.


alas, it happens to me on both debug and release build of the application.
anyway, isn't it a bug then? it does not happen with the ListView itself -
I've checked the same code with VB6.0 and there's no problem there.

I think that the number 4297000000 could be a 16-bit negative value (given
by the system) converted to 32-bit unsigned value (seen by TM). it would
explain why I get the number just after 10000.

Regards, Wiktor

Nov 15 '05 #9
> What version of the framework of the runtime are you running on?

tried on 1.0 and 1.1. the same result. the GDI handles count is never
decreased. it starts at 21 and then when I scroll the listview, it increases
up to 10000 and then jumps to this big number.
Nov 15 '05 #10
Ive just tried on a 1.0 machine and I get the same behaviour as Willy. Very
strange. The debug build doesn't kill my PC but does less aggressively GC.
This is inexplicable, anyone got any ideas?

Kieran

"Wiktor Zychla" <ie****@microsoft.com.no.spam> wrote in message
news:el*************@TK2MSFTNGP11.phx.gbl...
What version of the framework of the runtime are you running on?
tried on 1.0 and 1.1. the same result. the GDI handles count is never
decreased. it starts at 21 and then when I scroll the listview, it

increases up to 10000 and then jumps to this big number.

Nov 15 '05 #11
nonsense

in one of my application, whole accounting book can be loaded into listview
(if user selects dates 1.1 to 31.12).When I was testing I used 100000 rows
and tested on celeron 466,same as customer has. There were no slowdowns
while scrolling, only a lag of about 3 seconds to load everything (using
addrange).

Nov 15 '05 #12
Hmm .... Who's talking about slowdows?

Willy.

"martin" <fa********@yahoo.com> wrote in message news:bk**********@ls219.htnet.hr...
nonsense

in one of my application, whole accounting book can be loaded into listview
(if user selects dates 1.1 to 31.12).When I was testing I used 100000 rows
and tested on celeron 466,same as customer has. There were no slowdowns
while scrolling, only a lag of about 3 seconds to load everything (using
addrange).

Nov 15 '05 #13
> nonsense

in one of my application, whole accounting book can be loaded into listview (if user selects dates 1.1 to 31.12).When I was testing I used 100000 rows
and tested on celeron 466,same as customer has. There were no slowdowns
while scrolling, only a lag of about 3 seconds to load everything (using
addrange).


I do not have any slowdowns, either. I even did not mention any slowdowns.
So, what is your point? Did you check the GDI objects leakage in your
application?
Nov 15 '05 #14
Anyone found a solution to this problem?

From http://www.developmentnow.com/g/36_2...iews-leak-.htm

Posted via DevelopmentNow.com Groups
http://www.developmentnow.com
Nov 17 '05 #15
Anyone found a solution to this problem?

From http://www.developmentnow.com/g/36_2...iews-leak-.htm

Posted via DevelopmentNow.com Groups
http://www.developmentnow.com
Nov 17 '05 #16

This discussion thread is closed

Start new discussion

Replies have been disabled for this discussion.

Similar topics
The Command Prompt during my Windows Forms Application
1 post views Thread by Visually Seen # | last post: by
Host a Web Service in a Windows Forms Application
2 posts views Thread by Ludovic DE FREITAS | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.

BYTES.COM © 2023
About Bytes
Advertise
Terms Of Use
Privacy Policy
Contact Us
Sitemap

Follow us! Get the Latest Bytes Updates