Click here to Skip to main content
12,945,719 members (42,313 online)
Rate this:
Please Sign up or sign in to vote.
See more:
Hi All,

I have a doubt here. My application is built on C# Winforms in multi threaded application. Recently after a long run of my application, I am facing " Out of memory exception" from an active window and asserting. What might be the reason ? Here I am using PInvoke calls
. Will it causes issues ? Is GC will not work properly on PIO calls ? Please suggest.
Posted 22-Sep-11 19:40pm
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

GC works properly, but this question has nothing to do with the problem.
Do you think that with GC you don't have memory leaks? If so, this is completely wrong. Of course it eliminates memory leaks you would make due to forgetting to release some memory, but it cannot help if you have wrong design. It's pretty easy to design code which leaks managed memory.

As to forgetting to release some resources, this is still a source of other kind of memory leaks, of unmanaged resources. In particular, you need guarantee that you properly call Dispose for all types implementing System.IDisposable, because many of such objects allocate unmanaged resource and free them only if you call Dispose. This is the possibility Mehdi mentioned in his solution. Use using statement (not to be mixed up with using clause).

Of course you can have memory leaks by design. One typical case is putting objects in some application-global collection (for the sake of fast search, for example) and forgetting to remove references when object is not used anymore. By the way, think about using System.WeakReference, see[^].

So, first analyze your design for management of life cycle of all objects. Remember that an object is scheduled for destruction by GC only if all references to it in whole Application Domain becomes totally inaccessible form working code, but it does not apply to weak references. This mechanism if very cunning: if you have isolated path of circular reference, GC is clever enough to schedule all involving objects for destruction. Consider A referencing B, B referencing C and C referencing A. If all other references to each of these three objects are lost, they will be scheduled for destruction by GC anyway. [EDIT] The criteria for destruction is reachability, see[^].[END EDIT] Pretty neat, isn't it?

After that you may need to use the good advice by Mehdi and use a memory profiler. A good memory profiler is quite a powerful weapon.

Mehdi Gholam 23-Sep-11 2:46am
great advise a always, 5!
SAKryukov 23-Sep-11 2:49am
Thank you very much, Mehdi. "Always" is of course a great exaggeration...
SKOTAJI 14-Oct-11 4:11am
Thanks for your suggestions !
SAKryukov 14-Oct-11 12:30pm
My pleasure.
(I added one more link, see [EDIT] in the updated solution).
Good luck, call again.
Simon Bang Terkildsen 14-Oct-11 12:31pm
Good walkthrough, +5
SAKryukov 14-Oct-11 13:39pm
Thank you, Simon.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

Your best bet is to use a memory profiler (RedGate has a good one) to see where your memory leaks are, it is hard to say what it could be from your description.

Pinvokes could cause this if not disposed properly.
SAKryukov 23-Sep-11 2:41am
Yes those are good points, but it looks like you only suspect unmanaged memory to leak. This is not all. It's easy to leak even managed memory. I voted 4 and explain this problem in my solution, with some other advice, please see.
SAKryukov 23-Sep-11 9:44am
By the way, I added some important information to my solution and credited your solution which -- sorry about that! -- I forgot to do in first place. :-)
Mehdi Gholam 23-Sep-11 9:55am
Cheers man
SKOTAJI 14-Oct-11 4:11am
Thanks for your suggestions !
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

The best way to code while working on multi-threaded apps is to enclose your code blocks into 'using'. This is not ofcourse the best or fool-proof method, but will avoid most of the memory related problems.

Tell us if the suggestion works in your case

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

    Print Answers RSS
Top Experts
Last 24hrsThis month
OriginalGriff 4,899
CHill60 3,180
Maciej Los 2,453
Jochen Arndt 1,910
ppolymorphe 1,785

Advertise | Privacy | Mobile
Web02 | 2.8.170518.1 | Last Updated 22 May 2015
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100