2

As we know, when we execute an executable file, this file will be loaded into RAM.

So I'm thinking that I can rm a.exe after ./a.exe.

In my opinion, after executing ./a.exe, this file has been loaded into RAM, so I should be able to remove it from the hard drive. I used an example to do a simple test:

#include <iostream>
#include <thread>
#include <chrono>

int main()
{
        while (true)
        {
                std::cout<<"hello world"<<std::endl;
                std::this_thread::sleep_for(std::chrono::milliseconds(2000));
        }
        return 0;
}

I compiled the code and executed it, I can see hello world keeps poping up.

Then I remove the executable file, and hello world still keeps poping up.

So I think I could remove an executable file while it is running.

But today I tried to do the same thing to another C++ project, and after I removing the executable file, it crashed.

Why? Which kind of reason can cause the crash?

Yves
  • 3,291
  • 2
    First your assumption in wrong. It is not necessarily loaded into RAM yet. However this does not matter. For all files, once opened, you can rm them, and continue reading them. Note I said rm, that is remove there directory entry. They do not disappear until there is no directory entries, and they are closed. However Why does the C++ prog crash? (does it try open its own file?) – ctrl-alt-delor Mar 30 '18 at 09:05
  • Note: Executables should not have an extension. It is not Unix, and will lead to problems (what if you re-write a script in C, should the extension change? Now you have to change all scripts that use it.) – ctrl-alt-delor Mar 30 '18 at 09:06
  • @ctrl-alt-delor I don't know. This is a huge c++ project. I don't know exactly what it's doing. Fow now I only want to know what kind of possibilities can cause this kind of crash. – Yves Mar 30 '18 at 09:07
  • @ctrl-alt-delor can you explain "It is not necessarily loaded into RAM yet"? – Yves Mar 30 '18 at 09:08
  • I just noticed that the 1st prog is C++. The question states that this is the difference, but it is a commonality. – ctrl-alt-delor Mar 30 '18 at 09:08
  • @ctrl-alt-delor In fact gcc compile will name it with the extension .out, such as a.out. I wrote .exe to make it clearer. – Yves Mar 30 '18 at 09:09
  • My program crashed. Why? is a poor question. We are not telepathic, and have no access to your machine, your core dumps, your debugger, or indeed the output and source of your program. – JdeBP Mar 30 '18 at 11:58
  • @ctrl-alt-delor Is it possible that a running application is (temporarily) swapped out from RAM? Imagine we are running so many bin files and the RAM and SWAP are all exhausted. If it's possible, I'm thinking that it could be crashed if a bin file is swapped out temporarily and later it can't be reswapped in because the bin file has been rm. – Yves Mar 31 '18 at 08:41
  • 1
    @yves but remember that rm is not delete. The file is open, because it is a running process, and therefore is not deleted (yet), event though it is removed. – ctrl-alt-delor Apr 01 '18 at 21:51

1 Answers1

1

Agreed with @ctrl-alt-delor.

I resume it. Maybe it's will be helpful for someone:

Program Loading

As the system creates or augments a process image, it logically copies a file's segment to a virtual memory segment. When—and if— the system physically reads the file depends on the program's execution behavior, system load, and so on.

Source: Book III: Operating System Specific (UNIX System V Release 4)

So, the program isn't no necessary fully loaded into RAM.


When some file will be deleted after other program opened and then mapped it, it will be accessible all time while program is being run. This happens because rm just remove inode entry, but file descriptor, that referenced to mapped (map) memory will be live until program unmap it and close file descriptor. Therefore if OS run (exec) some program, then OS may (more likely) map executable file. Finally, delete file via rm when program is being executed has no indent on it executing.


P.S. map or whole copy of executable file segments behaviour also depend on format of executable file.