Can you delete dynamically allocated memory from a separate program?

Question

This question is out of pure curiosity. I recently learnt that it is very important to delete memory space if it is dynamically allocated in the Heap. My question, is it possible to delete the dynamically allocated memory space using a different C++ program (from the one with which the memory space was created) if the address of the memory space is known?

Here's an example:

CODE01.CPP

#include <iostream>
using namespace std;

int main() {
    int *a = new int;
    cout << a;
    int foo;
    cin >> foo;  // for blocking the program from closing.
    return 0;
}

Output for CODE01.CPP (say)

0x7c1640

CODE02.CPP

#include <iostream>
using namespace std;

int main() {
    int *a = (int*)0x7c1640;
    delete a;
    return 0;
}

Will this work? If I first run code01.cpp and then immediately code02.cpp will the memory in the Heap get deleted?

To be clear, in CODE01 the memory will be cleared when the program ends. If your object had a destructor, it might not clean up properly. But in this case, you are dealing with an `int` so it doesn't matter. If you are concerned about memory, allocated memory is always freed when the program ends. — François Andrieux, Oct 11 '19 at 15:08
Even if this was necessary, and even if this was possible, it would absolutely not be advisable. You would not ever want to have to worry if your objects might get spontaneously deleted by an external actor. — François Andrieux, Oct 11 '19 at 15:09
Would make more sense if you would add a blocking call e.g. `int foo; cin >> foo;` to the end of **code01.cpp**, so that the program wouldn't just end, thus freeing all of the memory it held. I would suggest that you edit that in, so that the question actually makes sense. — ruohola, Oct 11 '19 at 15:09
@FrançoisAndrieux but I learnt that if the memory space is allocated dynamically (using the ```new``` operator), it won't be deallocated when the program ends, which is why it is very important to delete the memory space. — Sujit, Oct 11 '19 at 15:10
then you learned it wrong. once the program terminates all memory is handed back to the OS — 463035818_is_not_an_ai, Oct 11 '19 at 15:10
programs not cleaning up properly on termination is a problem because once you use the code as part of a bigger program you will suffer from the leaks. Maybe thats where your misunderstanding is coming from — 463035818_is_not_an_ai, Oct 11 '19 at 15:12
A modern OS will give you a separate virtual address space for each process. The addresses are meaningless across processes. — drescherjm, Oct 11 '19 at 15:12
A memory address pointer is pointing to a virtual memory location which would mean nothing in the context of another executable surely ? So memory location 0x7c1640 in code02 wouldn't be pointing to the same block of memory as code01 — auburg, Oct 11 '19 at 15:13
THIS IS WRONG! Problem is to broad to discuss it on SO. Basically process do not share memory. Same address on one process usually points to different piece of memory on other process. Operating system manages how memory is mapped by address seen by specific process. — Marek R, Oct 11 '19 at 15:13
@MarekR I don't see why this is too broad? Just make an answer which states that the memory space is not shared. This is a fine question. — ruohola, Oct 11 '19 at 15:14
@ruohola Thanks for updating my question! So now am I correct to say this won't work if **code01.cpp** is closed and then **code02.cpp** is opened? — Sujit, Oct 11 '19 at 15:19
@Sujit Yes, running `code02.cpp` will not affect the objects in the memory of `cpp01.cpp`. — ruohola, Oct 11 '19 at 15:20
Common modern desktop platform do not support this capability. There are old platforms (that are not in common use today) which could do that (e.g., old Amiga with OS allocated memory blocks, old Mac with cooperative memory chunk management). There may be modern embedded platforms that also might provide that capability (executable overlays and shared memory pool). — Eljay, Oct 11 '19 at 15:29

ruohola · Accepted Answer · 2019-10-11T15:21:19.907

5

Any modern OS will create a separate virtual address space for both of the programs. Thus the address you are printing in code01.cpp is only relevant for that program and you cannot access the address space from code02.cpp.

So to answer your immediate question: running cpp02.cpp will not affect the state of the still running cpp01.cpp in any way.

edited Oct 11 '19 at 15:21

answered Oct 11 '19 at 15:18

ruohola

21,987
6
62
97

score 4 · Answer 2 · answered Oct 11 '19 at 15:24

4

One of the jobs assigned to opeating systems is the insure that one process can not harm another one. This mean preventing one process from affecting the memory used by another one directly in any way.

There are several mechanisms for this but they all defeat the idea

"If I know the value of a pointer used in that process, then I can do something to it's memory from this processes."

because that is exactly what the OS is suppose to prevent.

That said many OSs provide special channels (intended for interprocess communication) that you could abuse to allow something similar. But you'd have to work at it,and the details depend on the OS.

answered Oct 11 '19 at 15:24

dmckee --- ex-moderator kitten

98,632
24
142
234

Even if you were to be able to work around the OS memory protection, the two processes would still be using their own C++ heap with their own control structures. Freeing to the wrong process heap would be disaster. – Mark Ransom Oct 11 '19 at 15:30
To make it work you'd have to implement your own "heap" management seaprate from the new/delete mechanism of the language. Say both processes memory-map a common file, then use the memory for an object store. In that context "pointers" are file-offsets. As I say, you'd have to work at it, but in that context you could make process B responsible for releasing an object inserted by process A. – dmckee --- ex-moderator kitten Oct 11 '19 at 15:34

score 2 · Answer 3 · answered Oct 11 '19 at 15:21

The short answer, on most modern operating systems, is no. Most operating systems use virtual memory which means 0x7c1640 in program A is not necessarily 0x7c1640 in program B. In order for this to be possible, you would have to write a custom OS for this with no memory protection, at which point any program can overwrite any other program, which is a major security vulnerability.

A related question offers the diagram below of how virtual addresses are occupied. Each program gets a fake memory address the OS translates, so each program gets a different heap and cannot interact with each other through memory directly, at least on a common virtual memory system.

Can you delete dynamically allocated memory from a separate program?

3 Answers3