I want to know, suppose I am debugging a code and at any point I allocated some memory and break point hits for example:
1: Statement to allocate 1 MB memory in **C**.
2: Any other statement where **BREAKPOINT HIT**.
Now my question is:
If I will kill my IDE (like visual studio) directly using task manager then allocated memory and resources will free or not.
If I will stop debugging then allocated memory and resources will free or not.
If yes then How can I confirm it whether memory and resources have freed.
On modern operating systems, all the memory for your program is returned to the system when the program is terminated, which will happen in either of those cases. This might not happen on some embedded systems, but you wouldn't be running an IDE on those.
For other resources than memory, e.g., open files, devices, etc., the OS will generally reclaim all resources (unless they're still in use by other processes), but for some systems and some resources, under some conditions, resources can be lost or locked (which should be considered a bug in the OS or the device driver).
As far as determining that the system actually freed the memory, it can be quite difficult because the system allocates memory to buffers and swap areas and doesn't necessarily have a count of free space that you can check. For other resources ... if you can't acquire them then they weren't released.
Related
I was wondering if for example. Windows completely lock all the available ram so that some really bored person with too much time on their hands cannot start deleting memory from another process (somehow).
The question originated from what was happening when using the delete function in C++ (was C++ telling the OS that the OS can now release the memory for overwriting or was C++ telling the hardware to unlock the memory)... and then spawned on to me thinking of specific hardware created to interface with the RAM at hardware level and start deleting memory chunks for the fun of it. ie a hacker perhaps.
My thoughts were: The Windows memory management program is told memory is free to be written to again, right? But does that also mean that the memory address is still set to locked at a hardware level so that the memory can only be taken control of by windows rather than another OS. Or is it like the wild west down at hardware level... If Windows isn't locking memory, anything else can use the part that is now free.
I guess the real question is, is there a hardware level lock on memory addresses that operating systems can trigger... so that the memory has locked itself down and cannot be re-assigned then?
I was wondering if Windows completely lock all the available ram
Windows, like any other operating system, uses all the available RAM.
so that some really bored person with too much time on their hands cannot start deleting memory from another process (somehow).
Non sequitur. It does it because that's what it's supposed to do. It's an operating system, and it is supposed to control all the hardware resources.
The question originated from what was happening when you mark memory for deletion in C++.
I don't know what 'mark memory for deletion in C++' means, but if you refer to the delete operator, or the free() function, they in general do not release memory to the operating system.
My thoughts were: The Windows memory management program is told memory is free to be written to again, right?
Wrong, see above.
But does that also mean that the memory address is still set to locked at a hardware level so that the memory can only be taken control of by windows rather than another OS.
What other OS? Unless you're in a virtual environment, there is no other OS, and even if you are, the virtual environment hands control over all the designated RAM to the guest operating system.
Or is it like the wild west down at hardware level... If Windows isn't locking memory, anything else can use the part that is now free.
Anything else such as?
I guess the real question is, is there a hardware level lock on memory addresses that operating systems can trigger?
In general yes, there are hardware definitions of what privilege level is required to access each memory segment. For example, the operating system's own memory is immune to appliucation processes, and application processes are immune to each other: but this is all highly hardware-dependent.
Your question doesn't really make much sense.
The concept you're looking for is mapping, not *locking.
The memory is just there. The OS does nothing special about that.
What it does is map chunks of it into individual processes. Each process can see only the memory that is mapped into its address space. Trying to access any other address just leads to an access violation (or segmentation fault on Unixes). There's just nothing at those addresses. Not "locked memory", just nothing.
And when the OS decides to (or when the process requests it), a page of memory can be unmapped from a given process again.
It's not locking though. The memory isn't "owned" by the process it is mapped to. And the same memory can be mapped into the address spaces of multiple processes at the same time. That's one way to exchange data between processes.
So the OS doesn't "lock" or control ownership of memory. It just controls whether a given chunk of memory is visible to any particular process.
It is not as simple as that, also Windows is not open-source, so exactly what it does may not be published. However all addresses in user space code are virtual and MMU protected - address X in one process does not refer to the same physical memory as address X in another, and one process cannot access that of another. An attempt to access memory outside of the address space of a process will cause an MMU exception.
I believe that when Windows starts a process, it has an initial heap allocation, from which dynamic memory allocation occurs. Deleting a dynamically allocated block simply returns it to the process's existing heap (not to the OS). If the current heap has insufficient memory, additional memory is requested from the OS to expand it.
Memory can be shared between processes in a controlled manner - in Windows this is done via a memory-mapped file, and uses the same virtual-memory mechanisms as the swap-file uses to emulate more memory that is physically available.
I think rather than asking a question on SO for this you'd do better to first do a little basic research, start at About Memory Management on MSDN for example.
With respect to external hardware accessing the memory it is possible to implement shared memory between processors (it is not that uncommon; for example see here for example), but it is not a matter of "wild-west" the mechanisms for doing so are implemented via the OS.
Even on conventional PC architectures, many devices access memory directly via DMA as a method of performing I/O without CPU overhead. Again this is controlled by the OS and not at all "wild west", but an errant device driver could bring down your system - which is why Microsoft have a testing and approvals process for drivers.
No, there isn't.
RAM is managed by software, RAM can't lock itself.
You asked the wrong question. There is no such thing as a hardware lock on memory. The trick is virtual memory management which makes only controlled amounts of memory available to a process. The OS controls all available memory, that's its job, and processes only ever see the memory that the OS has given to them.
As we know the heap is used for dynamic allocation of memory for an application. How is the heap memory cleared(and hence avoiding memory leaks) in case of abnormal application termination?
Consider the following scenarios:
Say an application crashes all of a sudden on Windows or Linux.
We force kill an application in linux: kill -9 <process_name>
A C++ program in Visual Studio throws an error in the middle of execution.
Is heap management and cleanup any different in the above cases? [Please add more use-case scenarios which might be of interest here]
This question came up in my mind since we always talk about ensuring no memory leak happens in our code. Now how do we handle scenarios where we force close an application which might result into a program exit without calling the memory free-up calls.
And if such memory leak happens repeatedly, is it possible that the OS becomes short of heap memory? Or does the OS have a way of handling it...
Assuming the OS is a typical implementation of Unix or Windows, the heap memory is released by the OS when the application is killed, no matter what method it is killed by.
Obviuously, other OS's may not do exactly this, and it's up to each OS to solve this problem in a meaningful way - I'm not aware of any OS that doesn't "clean up after killed processes", but I'm sure such a thing may exist in some corner of this world.
Edit: There may be OTHER resoources that aren't quite so easily released, such as shared memory or semaphores used by multiple. But most OS's tend to deal with those by releasing the reference of the application being killed, and letting other processes that wait for any "waitable object" (mutex, semaphore, etc) will be "let run".
"The heap is typically allocated at application startup by the runtime, and is reclaimed when the application (technically process) exits" so killing/closing an application abnormally/normally won't leak any memory.
As for dynamic memory management you should use RAII(smart pointers is one example) to take care of memory leaks and management during exceptions and so on.
In cases where your application exits, the OS simply reclaims back all the memory it gave to the process. The OS doesn't understand leaks, it simply takes back what it gave to a process. So there is no leak per se. All memory is reclaimed. You might leak other resources(file descriptors etc) but a clever use of RAII should guard you against that.
It doesn't matter how your process closes, any remaining memory allocated from that process is freed by the OS memory manager when it closes. It's good practice for you to free all the memory you allocate before your process dies, but the available heap for the OS/other applications is the same after your process closes either way.
Just for fun I created a project that created about 5 GB of memory and did not delete it. As long as the application is running that "memory leak" is there. The second I close my application the memory within 2 seconds is back down to normal as if my program never ran. So the questions have to be asked.
Does Windows 7 clean up memory leaks from bad programs when they are done?
Do all Windows versions do this?
Will Linux and Mac OS X environments do this?
When the program terminates, the operating system reclaims all the memory that had previously been allocated to it. Cleaning up memory leaks may be a perceived by-product of this, but the OS does not actually see it that way. It does not know that the program had been leaking memory, just that it had allocated it.
Once a process in which your application runs exits, the OS reclaims all the memory allocated to the process.
This is typically true for all operating systems not just Windows 7 or Windows for that matter.
Note that, you may observe different behavior for other leaking resources like file handles etc, usually OS'es dont reclaim those. So, it is usually(Yes,there are exceptions) a good practice to make your own application clear the mess(deallocate the allocated resource) that it made instead of delegating it to the OS.
Not only does the program manages memory but does the OS too. And it reclaims all the memory allocated to a program after it exist. It doesn't interfere in between the execution of the program (Other than for paging and swapping). This control over memory of the OS helps the OS from crashing from memory leaks to a point.
Memory management is the act of managing computer memory. The
essential requirement of memory management is to provide ways to
dynamically allocate portions of memory to programs at their request,
and freeing it for reuse when no longer needed. This is critical to
the computer system.
BSD Unix normally starts reclaiming memory when the percentage of free memory drops below 5% and continues reclaiming until the free memory percentage reaches 7%
Yes (Windows 7 does reclaim all memory allocated to a program when the program exits, regardless of how it exits — under control or when crashing).
Yes (for any version of Windows that's recent enough to be still running).
Yes (Unix, Linux, Mac OS X, BSD all reclaim all memory allocated to a program when the program exits, regardless of how it exits).
A few old operating systems did not reacquire resources when a program exited. I believe AmigaOS was one; another, I believe, was the old Mac OS (Mac OS 9 and earlier). However, substantially all true multi-tasking systems have to reclaim memory (and resources in general) when the process to which it was allocated exits.
This is not the case for all OS's, for example, I do not believe WinXP will behave this way.
Though for most modern OS's it is now the case. I believe all current versions of Linux, Windows and MacOS do this.
For windows, I'm pretty sure it was introduced in Windows Vista. At the time it was a rather exciting improvement as there were A LOT of dodgey windows applications out there that didn't manage their memory well. At the time it was a big win for windows, but it had come late to the party (as usual), as Linux and MacOS were already doing it long before.
Having said that, I'm sure you appreciate that you definitely still need to manage your memory properly within your application and not simply rely upon your OS to clean up after you. Applications need to be efficient and predictable with their memory use during their runtime as well.
When a C/C++ program containing the dynamically allocated memory(using malloc/new) without free/delete calls is terminated, what happens to that dynamically allocated memory?
Does the operating system takes back the memory or does that memory becomes unaccessible to other programs?
I don't think that there are any guarantees in the language standard, but modern operating systems which support sparse virtual memory and memory protection (such as MacOS X, Linux, all recent version of Windows, and all currently manufactured phone handsets) automatically clean up after badly-behaved processes (when they terminate) and free the memory for you. The memory remains unavailable, however as long as the program is running.
If you're programming on microcontrollers, on MacOS 9 or earlier, DOS, or Windows 3.x, then you might need to be concerned about memory leaks making memory permanently unavailable to the whole operating system.
Most modern operating systems employ a memory manager, and all userland processes only see so-called virtual memory, which is not related to actual system memory in a way that the program could inspect. This means that programs cannot simply read another process's memory or kernel memory. It also means that the memory manager will completely "free" all memory that has been assigned to a process when that process terminates, so that memory leaks within the program do not usually "affect" the rest of the system (other than perhaps forcing a huge amount of disk swapping and perhaps some "out of memory" behaviour).
This doesn't mean that it's in any way OK to treat memory leaks light-heartedly, it only means that no single program can casually corrupt other processes on modern multi-tasking operating systems (deliberate abuse of administrative privileges notwithstanding, of course).
Short answer: yes, the OS will free this memory.
Most operating systems will free this memory, however it is bad practice to rely upon this behaviour. Some operating systems will not free this memory. For example, embedded systems. For portability, always free all the memory you allocate.
C/C++ doesn't have garbage collection feature. If you allocate memory and doesn't free it up, it's of no use while the program execution continues. This is called memory leak. Once the execution finishes, OS takes back this memory and is again available for use.
During the program's execution, you cannot count on the operating reclaiming the memory. That would be a garbage collection feature found in many other languages such as Java and C#. While garbage collected c++ is possible, I don't believe any mainstream implementations use it.
On the other hand, once your program completes its execution, the OS should reclaim the memory used by the program. So during execution the memory remains off-limits, but is accessible again after the program exits.
If I programmed — without knowing it — a memory leak, and the application terminates, is the leaked memory freed?
Yes, a "memory leak" is simply memory that a process no longer has a reference to, and thus can no longer free. The OS still keeps track of all the memory allocated to a process, and will free it when that process terminates.
In the vast majority of cases the OS will free the memory - as is the case with normal "flavors" of Windows, Linux, Solaris, etc. However it is important to note that in specialized environments such as various Real-Time Operating Systems the memory may not be freed when the program is terminated.
The OS executing your program usually does cleanup memory that is not freed explicitly and handles that are not closed explicitly, but this is not guaranteed by the C++ standard. You may find some embedded device that do not free up your memory leaks.
That being said Windows and all distros of Linux that I've ever seen do free up memory leaks.
You can easily create a huge loop of memory leaks though to test it out yourself. Watch your RAM usage grow and then close your program. You will see that the RAM usage goes back down.
Another consideration when using C++ is that if you aren't deleting your heap allocated memory then your destructors are also not being called. Sometimes you will have other side effects as well if your destructors aren't called.
Are you running on a desktop OS (Windows, Linux etc.)? If so, yes, in general the system will free any memory associated with the program when the program exits.
Usually, yes. Some systems support things like shared memory blocks that aren't automatically freed when a program exits though. Most still keep a reference count and delete it when all the programs that opened it exit, but a few don't (e.g., 16-bit Windows had a few types of items that would remain allocated even when nothing referred to them -- though it usually crashed for other reasons before enough of this accumulated to cause a problem...)
As far as I know, a modern operating system will free this memory once the program terminates.
Depends on what memory you leaked. Some memory can't be reclaimed by the OS. Most memory on most OSes however will be automatically reclaimed when the process exits.