Re: Memory Leak?
Stuart Dunkeld <[email protected]>
| Newsgroups | gmane.comp.windows.devel.dotnet.advanced |
|---|---|
| Message-ID | <[email protected]> |
Can you use unmanaged code in your app? If so, a keyboard hook like the one detailed at http://blogs.msdn.com/toub/archive/2006/05/03/589423.aspx could be the answer, especially if your environment has activate and deactivate events which allow you to only listen for keypresses when your app has focus.. --stuart On Tue, Dec 2, 2008 at 12:27 AM, Dave Vorgang <[email protected]> wrote: > Thank you for your response. > > I am at my wits end with this problem and I don't believe I've given enough information to the list to rectify my problem. > > I would love to send all the code to someone to help me resolve this. > > I'm not really looking for a free handout but on the other hand I don't have authorization to pay someone. > > If someone would like to help, perhaps for the benefit of learning themselves, I would appreciate hearing from you. > > Thanks, > > Dave Vorgang > Senior Programmer / Analyst > Medford School District - Information Technology > (541) 842-1021 > mailto:[email protected] > > > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:[email protected]] On Behalf Of Corneliu I. Tusnea > Sent: Monday, December 01, 2008 4:15 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Memory Leak? > > David, > > If you want to call properties/methods on windows control you need to marshal them back to the thread that created the control/window. > You need thought to proxy all your calls from a different thread via control.Invoke. > > If you need to wait for a keypress while the form is open just listen for the KeyPress event on the form. Your form has the focus so it will get the key. > Your memory goes up simply because you loop and you call do events that allocates some memory. Because of the CPU pressure you put via the loop cycle the GC does not kick in or it does not care about releasing memory. Your memory will be released once .Net decides it needs it for something else of it hits some specific memory usages. I would not be worried at all and I would consider that normal behaviour. GC will release when it considers it's worth it not when you want it or expect it. > Kicking GC in the *** with a GC.Collect does not help either as the math for memory pressure will not change so you will not force the GC to collect everything you think it should. > > My recommendation is to get rid of the loop cycle (they don't play well with the way Windows message pump work) and just listen for an event like KeyPress on the form. You might need to set the KeyPreview property to true for the window as well. > > > Regards, > Corneliu I. Tusnea > Readify | Senior Consultant > M: +61 410 835 593 | E: [email protected] | C: [email protected] > Please consider your environmental responsibility before printing this e-mail > > > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:[email protected]] On Behalf Of Dave Vorgang > Sent: Tuesday, 2 December 2008 11:00 AM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Memory Leak? > > My first go at this was to place it in a separate thread. I spent about a week on it and could never get it to work correctly. I kept get getting cross thread problems. > > The concept seems pretty simple. My main process brings up a form, changes certain attributes and initializes some fields, then the main process waits until the user presses the enter key or a function key. > > I can't use a dialog box because I want the form to remain once the user press Enter or a function key, but I want the main process to continue. > > So, I just need the ability wait until the user presses enter (or function key). > > Any more suggestions would be helpful. > > Dave Vorgang > Senior Programmer / Analyst > Medford School District - Information Technology > (541) 842-1021 > mailto:[email protected] > > > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:[email protected]] On Behalf Of Marc Brooks > Sent: Monday, December 01, 2008 3:48 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Memory Leak? > > You should NEVER be calling GC.Collect. For that matter, you really > shouldn't ever code for DoEvents. Rather, do whatever it is you need > to do in a loop in a separate thread from the UI. If I had more idea > who was calling this method, and who was changing the global > variables, then I could give better advice. > > On Mon, Dec 1, 2008 at 17:43, Dave Vorgang > <[email protected]> wrote: >> I changed it to: >> Do >> System.Windows.Forms.Application.DoEvents() >> Thread.Sleep(55) >> GC.Collect() >> Loop Until _KeyEntered >= 0 >> >> This helped but it still increased Mem Usage as time went on. >> >> Any help on fixing this would be greatly appreciated. >> >> Thanks, >> >> Dave Vorgang >> Senior Programmer / Analyst >> Medford School District - Information Technology >> (541) 842-1021 >> mailto:[email protected] >> >> -----Original Message----- >> From: Discussion of advanced .NET topics. [mailto:[email protected]] On Behalf Of Mark Hurd >> Sent: Monday, December 01, 2008 3:16 PM >> To: [email protected] >> Subject: Re: [ADVANCED-DOTNET] Memory Leak? >> >> On Tue, Dec 2, 2008 at 9:38 AM, Steve Johnson <[email protected]> wrote: >>> Likely, the problem is recursion. Each call to DoEvents pumps messages, >>> which causes your VREADFIELDS function to be called from within itself. >>> Each call allocates another stack frame. You'll eventually run out of stack >>> space and crash with a StackOverflowException. >> >> I agree that it is not due to the code sample provided in isolation. >> Whenever we need an idle loop we use a similar loop (with Sleep(55)), >> and when it is worth suggesting we know it would be a good time to do >> a GC.Collect we include that too. >> >> Regards, >> Mark Hurd, B.Sc.(Ma.)(Hons.) >> >> =================================== >> View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives >> >> =================================== >> View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives >> > > > > -- > Marc C. Brooks > http://musingmarc.blogspot.com > > NOT sent from an iPhone > > =================================== > View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives >