How exec can change the behavior of exec'ed

Question

I am trying to track down a very strange glitch. What is strange is the workaround that someone has discovered and which I cannot explain.

A workaround is a small program that I will call a "runner":

#include <stdio.h> #include <unistd.h> #include <string.h> #include <errno.h> int main(int argc, char *argv[]) { if (argc == 1) { fprintf(stderr, "Usage: %s prog [args ...]\n", argv[0]); return 1; } execvp(argv[1], argv + 1); fprintf(stderr, "execv failed: %s\n", strerror(errno)); // If exec returns because the program is not found or we // don't have the appropriate permission return 255; } 

As you can see, this entire program uses execvp to replace itself with another program.

A program crashes when it is directly called from the command line:

 /path/to/prog args # this crashes 

but works fine when it is indirectly called through my runner pad:

 /path/to/runner /path/to/prog args # works successfully 

Throughout life, I can understand how the presence of additional exec can change the behavior of an executable program (since you can see that the program does not change the environment).

Some background to the accident. The crash itself occurs during C ++ execution. In particular, when a program performs a throw , the erroneous version incorrectly thinks that there is no corresponding catch (although there is one) and calls terminate . When I call the program through the runner, the exception gets right.

My question is any idea, why does additional exec change the behavior of the exec'ed program?

Answer 1

Perhaps the .so files downloaded by the runner make the rudder work correctly. Try ldd'ing each of the binaries and see if any libraries are loading in different versions / locations.

Answer 2

The called program may have a memory leak. Try running it with valgrind or another memory check tool. Once you have a memory error, everything else is undefined behavior (and so anything can happen).

Answer 3

Like a shot in the dark: double-exec can change the order of environment variables in RAM.

The environment is a memory structure with pointers; the kernel copies this structure into the address space of the new process. The actual order of items in RAM may change during this copy (environment variables are not semantically ordered, but the addresses in RAM are in order). With two exec (), the order can be changed twice.

The fact that changing the line order in RAM detects an error is somewhat bizarre, but stranger things happened.

Answer 4

I wonder if you are passing something else to argv [0] for the shell. I do not see, obviously, from what you write above, but it is possible that you set argv [0] to the actual first argument to the program, while the shell sets it to its name (for example, a full or short path)

Answer 5

I assume that the two things you could compare between the working and crashing versions are to open file descriptors and signal handlers as they are passed to exec.

I don’t see how they are a problem / to be different, but it may be worth eliminating them.