|
BarV wrote: According to microsoft and all
my colleague .NET Applications DON'T leak.
True, to a point. A .NET app can only leak unmanaged resources or memory allocated through unmanaged means.
BarV wrote: Is that the reason my app is leaking?
What makes you think your app is leaking? Don't tell me you relied soley on the numbers you saw in TaskManager?
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
No. I relied on the Private Bytes counter in the prefmon.
b.v.
|
|
|
|
|
BarV wrote: Isn't that means that when a memory is freed a hole is created and not handled?
No, it doesn't.
The hole is created, all right, as the heap is not compacted, but it's handled. The memory will be used for allocating new large objects.
---
b { font-weight: normal; }
|
|
|
|
|
Ok, so the Large Memory Heap is defragmented?
|
|
|
|
|
No, it's not. Moving large blocks of memory around can take an eternity, so there is no compaction, or defragmentation as your calling it. The hole remains where it was created. But the CLR is smart enough to fill that hole with whatever it can, whenever it can. The memory is not "just wasted".
The memory stays allocated as far as an unmanaged view of the memory goes. Which is what you saw when you used the Process' Private Bytes counter. The memory is not used by your application, as far as Windows is concerned, it is. This is because the memory is reserved by the CLR in the Managed Heap. You MUST used the .NET CLR performance object counters if you want to see how much memory your app is REALLY using. What you're looking at, when using the Private Bytes counter, is the memory reserved for your application (allocated by your app or not) by the .NET CLR virtual machine your app is running in.
-- modified at 15:20 Monday 21st August, 2006
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Thank you.
|
|
|
|
|
Dave Kreskowiak wrote: No, it's not. Moving large blocks of memory around can take an eternity, so there is no compaction, or defragmentation as your calling it. The hole remains where it was created. But the CLR is smart enough to fill that hole with whatever it can, whenever it can. The memory is not "just wasted".
Not in bulk, but in small amounts, it can effectively be. The problem is that the large object heap can fragment in the same way as a standard heap in a native app. The risk of large scale fragementation is minimal though because you need frequent de/allocation on the heap to cause it, and you shouldn't be creating and destroying large objects very often.
|
|
|
|
|
Various pieces of a strcutre or class can be rearranged, but not something like an entire array. I've worked with HUGE arrays (250+MB) and those don't get compacted or moved. The holes they created stay in place until another array was allocated or an existing array expanded. Because the indexer is required to be contiguous, moving an array of that size after it's been swapped to disk can take forever and a day as far as your app is concerned.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Dave Kreskowiak wrote: Various pieces of a strcutre or class can be rearranged, but not something like an entire array. I've worked with HUGE arrays (250+MB) and those don't get compacted or moved. The holes they created stay in place until another array was allocated or an existing array expanded.
That was my point, which is how in theory the heap can fragment.
The following psudeocode will put a 10byte fragment on the large object heapthat will remain unused for the remainder of the app's runtime.
Allocate(TempObject, 1000) // in use, bytes 1-1000
Allocate(PremamantObject1, 1000) // in use, bytes 1-2000
Deallocate(TempObject) // in use, bytes 1001-2000
Allocate(PremamantObject2, 990) // in use, bytes 1-990, 1001-2000.
//Unallocated, and too small to use bytes 991-1000
In a well designed app, this won't happen often enough to be a problem, but with a sloppy design that's continually re and deallocating from the large object heap you could end up with a number of such fragments around objects that have long lifetimes. Worst case could be almost 50% loss with a sequence of minimum sized objects, and gaps one byte smaller than the minimum. If this is happening there's bad design to blame, but a heap fragmentation leak's possible in theory, which was my point.
|
|
|
|
|
Oh! I know how the heap can fragment! The trick is knowing how to defrag it yourself.
The app with the HUGE arrays allocated two arrays on the LOH. This app iterated over a set of data, over and over again, until a solution was found. The first array was the data from the last pass and the second was the data generated from the current pass. Well, pass after pass, the LOH grew and grew, faster than the amount of data that was generated. Weird - and very much like the OP's problem.
The solution to implementing LOH compaction in this case was surprisingly easy. Since I only had two objects only needed one of them the next pass, I simply serialized the generated array to disk, disposed of both arrays, forced a GC, then deserialized the array from disk to put it at the bottom of the LOH. A poor-man's memory manager, if you will. According to the CLR Profiler and a bunch of testing, it worked beautifully! It's not the best performing solution, but I didn't need the app to respond between passes. Most of the apps time was spent crunching on that ever growing pile of data...
Now, implementing something similar in the OP's case depends on his objects and requirements...
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
I am trying to install the .net ODBC data driver.
I have downloaded the ODBC_Net.msi and tried to run it but I keep getting the message:
"The system administrator has set policies to prevent this installation"
Trouble is I am logged in as administrator.
What am I doing wrong? What policies should I change?
I am using VS2005 and have Win XP SP2 with MDAC 2.8
Roy Thompson
|
|
|
|
|
IIRC, that download was for the .NET Framework 1.0 and Visual Studio .NET 2002. 2005 already has ODBC providers built into the BCL under the System.Data.Odbc namespace.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Dave
Many thanks - obvious really!
Regards
Roy
|
|
|
|
|
I have written a simple process killer, however it uses toolhelp so will not run on NT4.0. I have read a few articles on NT4.0 process killers but all seem to be too in depth. I would just like a simple way to pass a string (name of the executable) and then to cycle each process until i find the one that is associated, and then terminate it using the .NET framework. I wont have created this process so wont have the handle so i will need to enumerate the processes (this is where i need help).
If any one can point me in the right direction I would be very grateful.
Cheers
Dan
|
|
|
|
|
This is easily done using the Process[^] class. You can use it's GetProcessesByName static method to get the list of Process objects you want, then just call either the Close, CloseMainWindow, or Kill method on each of those objects.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
cheers that is most helpful
Dan
|
|
|
|
|
How can I get content (text) from “RichEdit20W” class. I want to use text from “RichEdit20W” class control of office word in my application in VC++.NET. Waiting for reply. Thanks
Priyank
|
|
|
|
|
Hi,
What required to run an application, which is coded in Microsoft Visual Studio 2005 VC++, on other system without Microsoft Visual Studio 2005 installed?
Regards,
Aniket
|
|
|
|
|
The .NET Framework version the application targets, as well as any library dependencies the application may have.
|
|
|
|
|
You need a .NET Framework Redistributable Package installed on target machines.
Best,
Jun
|
|
|
|
|
Hi,
- Can I see the COFF Format physically ?
- If It is 'YES', How Can I ?
Thankx in advance
|
|
|
|
|
What do you mean by seeing the format physically?
Is it a file in the format that you want to view?
As the file contains executable code, it really doesn't have any visual representation. How would you wish to view it?
---
b { font-weight: normal; }
|
|
|
|
|
The best tool for viewing COFF format data is dumpbin. Run it from the Visual Studio command prompt - newer versions will give more information.
|
|
|
|
|
Dear Friends
I migrated my project to .net 2005 which was in .net 2003(windows application using C# language)
When I run the solution the forms and the controls are as if it is still in .net2003
then I opened the files(all) and changed the versions from 1.0,1.3,etc to 2.0
till then I did not got the .net 2005 control appearance.
What should I do.
Please reply soon...
My mail Id is rabindrapatra@gmail.com
Thanks
Rabindra Patra
|
|
|
|
|
I beleive that is pretty much what you can get by migration.
Migration only makes your VS2003 project work on VS2005 compiler. It does not modify your source code, which means it doesn't remove obsolete calls or add new calls. It does not automatically upgrade to new GUI features that do not exist in the old IDE. You have to redesign the GUI to get the new features. Approximately, you could consider that the migration only happens at the level of project settings.
Best,
Jun
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
