Author: Scott Gasch
Date: 12:52:00 01/10/02
Go up one level in this thread
On January 10, 2002 at 15:10:41, David Hanley wrote: > >No, look at the following page: > >http://www.greystoke.demon.co.uk/Documents/Services/Tuition/MCP/70-016/CreatingManagingCOMComponents.htm > >At the bottom of "creating objects" > >If you don't free a COM, it will be leaked into system space. How? When you create a COM object where is it created? I don't know much about COM. But if the object is created in your process' address space, when your process terminates the OS will reclaim the memory. Guaranteed. If, when you create the COM object, you are allocating it in the context of the "COM service" or something (that never terminates)... or if your process itself never terminates and you forget to release your interfaces... then you have problems. You are consuming system memory with junk. This is not window's responsibility, though. Write code that works. I can do the same thing on linux by writing a daemon process that has a memory leak... over time the memory resources of the machine will be consumed. My only point is that its not possible for a usermode process to allocate some memory, forget to free it, _terminate_, and "leak" the memory so that it can't be used again -- as long as that memory is in the usermode process' address space. That memory will be reclaimed and reused as it should be. >It's very easy >for a crashing app to not clean up all of it's COM's. That will typically lock >in the associated DLL as well. This is simply not true. Whether an app terminates normally or crashes the kernel routine MmCleanProcessAddressSpace will execute. Since the DLLs from that app are mapped into its address space they will not get "stuck" in memory. >There's a lot more examples of that, like the property atoms. You're right about atoms. It's possible to fill up the system atom table with garbage from a usermode app. The system atom tables are allocated from paged pool (kernel memory) so it will not get cleaned up when your app terminates. This is by design as the atom tables are used to implement the clipboard and you want junk you put on the clipboard to persist after the app that put it there has terminated. There's also a maximum size that the system atom tables can grow to before further calls (internally) to RtlpHashStringToAtom will fail with STATUS_NO_MEMORY. >>>You can also screw up shared in-process DLL's. Generally, those sorts of things>>>are much harder in linux, or not possible. >> >>I don't know what this means. > >Well, the only way to really do something like this in linux is to create a >named pipe or block of shared RAM and never free it. However, that's much less >common than COM's on which many windows progrms must rely. To do something like what? Get memory "stuck"? As I said before any memory allocated in the process' address space will be cleaned up when the process terminates. Period. Shared sections are just like com objects in a way -- they have a reference count. When the last process with a handle to the section terminates or closes the handle, the section will be destroyed. >>>I dual-boot NT and linux, and linux has crashed once on me, but i have to >>>restart windows every few days or else it will crash for sure ( it does crash if>i forget to reboot ). >> >>If you are running 2k or XP and you are seeing crashes once a week I would be >>willing to bet that the cause is a bad device driver. > >I see them several times a week... Almost daily. > >> Bugs in the NT kernel at >>this point do exist but they are very few and far between. In my experience the >>only difference between linux and windows in terms of stability now is the >>quality of the driver code running on each. It seems like the calibre of the >>driver writer on linux is higher than the calibre of the driver writer on >>windows for whatever reason. But put a bad driver on either one and there goes >>the system. > >Well, i'm 99% sure it's because of our buggy apps. If i don't run these apps >for awhile, the system is much better. > >dave > >> I try to stay with "signed" drivers (though this is hard to do >>sometimes). > >Probably a good idea. > >dave
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.