If I enumerate heaps in my process using GetProcessHeaps API, is there a way to tell which module(s) were those heaps created by?
Here's why I need this: For the purpose of my security application I need to lock virtual memory used by my process (i.e. memory used by the Windows common controls, anything allocated via the new operator, COM, etc.)
The reason I need to know which module created the heap is to eliminate any DLLs that can be loaded into my process that have nothing to do with it. Say, as an example, TeamViewer loads into running processes to add whatever-they-need-it-for, so I don't want to lock its private heap, if it has one, etc.
If you are only concerned with you own allocations then you can just use your own private heap and override the default new and delete handlers to use your heap.
Related
I have a C++ application to be run on Oracle Linux OS.
Consider, I have created few objects with new operator. Though I have used delete operator to deallocate it, but the force kill command would not reach this implementation.
But, if I force kill (kill -9) the process, will the dynamically allocated memory (using new operator) be de-allocated by the operating system? As I am not able to find the straightforward answer to this, I would like to have some information.
Thanks in advance.
But, if I force kill (kill -9) the process, will the dynamically allocated memory (using new operator) be de-allocated by the operating system?
Memory is tied to a process through the virtual memory system and the memory management unit (MMU). Thus yes, all memory (not just the one allocated through new) will be freed.
Exceptions to this are global inter-process communication (IPC) resources like shared memory, cached files, etc.
When a process dies by whatever means, all process resources including memory and file objects are cleaned up by the kernel. When you kill a process it stops running immediately so no cleanup code including destuctors is are run. So yes all memory is deallocated but is happens at a much lower level than heaps and stacks.
I have an application that consists of a host program and a few plugins. The plugins are implemented in dlls that can be dynamically loaded and unloaded. The code of the plugins (inside the dlls) allocate memory for objects and pass the pointers to the host program. These objects are allocated on the dll heap and there is no way to change the interface to use a specialized memory allocation function.
Is there a way for the host program to detect on which heap manager an object has been allocated? I want to implement some kind of reference counting for the dll. As long as the host program still uses memory from the dll, the dll cannot be unloaded. That means I would like to track from the host program who (which plugin) allocated a memory block (objects that are kept in various lists inside the host). The current interface includes a call to unload a dll. This call should schedule for unload, but only execute it once the host is finished using the memory.
Thanks for any suggestions.
I would like to have a variable to persist even after program termination. In other words, I'd like for a variable to remain in the memory even after an application exits from the main function. So, if my application is launched again, it could access that variable directly from the memory. Is this even possible? Would dynamic allocation, e.g. array=new int[size], do the trick?
No, all memory is reclaimed by the os on process termination. You have to save stuff you want to a file.
It's not possible. You have to store the data in a file or system preferences in order to access it on the next launch
Disclaimer: Storing the values to a file or using some framework functionality like QSettings should be preferred over the following approaches.
If You really want Your variables to remain in the memory and if You can risk to loose the values in a reboot, then ask the operating system for shared memory.
If You have a POSIX-compliant platform like Linux or Windows, then use the POSIX functions. To quote the manual:
POSIX shared memory objects have kernel persistence: a shared memory object will exist until the system is shut down, or until all processes have unmapped the object and it has been deleted with shm_unlink.
Be warned, that this introduces a kind of memory leak: Your variables will consume
memory even after the termination of the application.
I'm using VirtualQuery to go through virtual space of my application. But I'd like to identify everything allocated by application, not just my exe - something like SysInternals' VMmap application - And I need to know which pages belong to which file (I need to identify pages allocated for my application and dlls). How to achieve this?
You can use CreateToolhelp32Snapshot with TH32CS_SNAPMODULE to retrieve modules base addresses and sizes. For heap, you get use GetProcessHeaps() and HeapWalk() to get different heap regions (both committed and reserved).
Other things (thread stacks, mapped memory) seem harder to retrieve.
How does one create and launch process (i.e. launch an .exe file) with RAM limitation using c++ and the win32 API?
Which error code will be returned, if the proccess goes beyond the limit?
Job Objects are the right way to go.
As for an error code, there really isn't one. You create the process (with CreateProcess) and the job (with CreateJobObject), then associate the process with the job object (with AssignProcessToJobObject).
The parent process won't get an error message if the child allocates more than the allowed amount of memory. In fact, the limit will be enforced even if the parent process exits. If the child process tries to allocate more than the allowed amount of memory, the allocation will simply fail.
You can use CreateProcess() to spawn a process.
Once you have done that, you can use SetProcessWorkingSetSize() to attempt to control how much physical memory it uses, but this is more of a really strong suggestion to the VMM than some actual edict that will cause malloc() and new to start failing.
There is no way to say "this process will take 4mb of memory and after that all allocations fail". I mean, you're going to link to win32 dlls and you have no idea what sort of memory usage those things require. If you want your app to only take some certain amount of memory, don't allocate more than that. And don't do things that allocate memory.
Your question regarding the error code makes no sense at all.
NT Job objects ( SetInformationJobObject & JOBOBJECT_BASIC_LIMIT_INFORMATION )
By my knowledge there is no such possibility on windows. It would be very useful to have though, for testing and other things.
You have this on java as a JVM uses only a predefined amount of memory, but there its not a feature, but rather a problem ;-)
If you launch a process, you lose control over this process. Just the operating system can control its behavior (memory footprint i.e.) but even in that case I can't imagine how this could be achieved, as jeffamaphone stated, any limitation is at best a suggestion, not a instruction. A process can call external static libraries, COM instances, etc, so I don't imagine how this limit could be verified/enforced.