17

I have a broad question:

Suppose that I have a C++ program and I started to run it on a file in the background with some configuration which can be set internally. While it was running, I changed these internal configurations, compiled it and started to run it on another file.

Is this going to affect the previous instance which was already running in the background ? or since it was already up and running it won't ? Any ideas on this is appreciated.

Cemre Mengü
  • 18,062
  • 27
  • 111
  • 169
  • I would assume that if the first process is already completely loaded into memory it would not be affected by the source binaries changing. Commented instead of answered because I cant confirm that however – gbtimmon Aug 20 '12 at 15:56

3 Answers3

21

It is not safe to modify an executable that is running. As per What happens when you overwrite a memory-mapped executable?

Under Linux, if you replace an executable while it is running, the results are unpredictable and it may crash.

If you delete the file and compile a new version of the program then what will happen is very well defined. The already running instance will use the previous code, and that will be held in memory by the operating system until the program terminates. Any new instances will use the new code.

The summary: You should make sure your build system deletes the old executable before recompiling, and so long as that is true then the recompile will not take effect until you rerun the program, otherwise the behaviour is undefined (read SIGSEGV).

Appendix of sorts:

JamesKanze rightly pointed out that the linker itself may delete the file before writing its output, if this is the case then it will always behave as if you'd deleted the file yourself before recompiling (the sane scenario). Looking at bfd/cache.c from the binutils cvs head:

/* Create the file.

   Some operating systems won't let us overwrite a running
   binary.  For them, we want to unlink the file first.

   However, gcc 2.95 will create temporary files using
   O_EXCL and tight permissions to prevent other users from
   substituting other .o files during the compilation.  gcc
   will then tell the assembler to use the newly created
   file as an output file.  If we unlink the file here, we
   open a brief window when another user could still
   substitute a file.

   So we unlink the output file if and only if it has
   non-zero size.  */

So at least with GNU LD this is guaranteed to be fine. This does not necessarily extend to other linkers, however.

Community
  • 1
  • 1
jleahy
  • 16,149
  • 6
  • 47
  • 66
  • 3
    This depends on how the linker creates its output file. If it simply does an `open`, truncating an existing file, the executable which is running is in for some surprises if it needs to page in any code. If the linker deletes the file before opening a new one, however, the running program should be unaffected. – James Kanze Aug 20 '12 at 17:16
  • 1
    @JamesKanze That's a very good point. I went through the ld source to find out what happens and it does indeed unlink the file first, I'll update my answer. – jleahy Aug 21 '12 at 07:12
6

What can/will happen depends on the OS, but in general your old program will never start running with the new code. I say it is OS dependent since on Windows I believe the file will be locked and you simply can't overwrite it, whereas on Linux, you'll essentiall unlink the old file, but the program will still use that old version, and your new version will technically be a different file.

Now there is a caveat here. If you have dynamic libraries, or other dynamic code resources, then you might get the new version. In any case you load a library on demand the version you load will be the one that exists at the time of loading. In most cases all libraries are loaded directly at the start of the program. One common case where they are not however is a plugin architecture, where they are loaded as needed.

edA-qa mort-ora-y
  • 30,295
  • 39
  • 137
  • 267
4

No, it won't affect the original running instance - that's already loaded into memory and won't be changed.

Smi
  • 13,850
  • 9
  • 56
  • 64
  • 1
    So are we sure that a c program will always load completly into memory. Is it possible that the program would page in and out parts of the program if it were particularly large? Edit: I suppose if it did it would page between the phyiscal memory and the virtual memory space, not the soruce binaries, so i think H2CO3 is correct. – gbtimmon Aug 20 '12 at 15:57
  • Yes. You don't have to worry about this on any sane system (Windows, Linux, BSD, etc.) – Bill Lynch Aug 20 '12 at 15:59
  • @sharth, I'm sure I've experimented crashes on Linux when recompiling an executable. – AProgrammer Aug 20 '12 at 16:04
  • @AProgrammer I'm pretty certain you're correct, hence my answer. – jleahy Aug 20 '12 at 16:12
  • @sharth If I'm mistaken (for Linux at least) let me know and I'll update my answer. – jleahy Aug 20 '12 at 16:13
  • If I look at /proc/pid/maps, I can see that the application is loaded as MAP_PRIVATE, so copy-on-write. This would imply to me that any changes to that inode would not be reflected in the application's version. I guess I can't say I'm 100% on this, but having it any other way would make no sense at all to me. Think about sudo, if a user did `sudo ./executable`, that could be a security hole if that application was writable by a non-root user. – Bill Lynch Aug 20 '12 at 16:17