how can exec change the behavior of exec'ed program

Question

I am trying to track down a very odd crash. What is so odd about it is a workaround that someone discovered and which I cannot explain.

The workaround is this small program which I'll refer to as '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, all this program does is use execvp to replace itself with a different program.

The program crashes when it is directly invoked from the command line:

/path/to/prog args  # this crashes

but works fine when it is indirectly invoked via my runner shim:

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

For the life of me, I can figure out how having an extra exec can change the behavior of the program being run (as you can see the program does not change the environment).

Some background on the crash. The crash itself is happening in the C++ runtime. Specifically, when the program does a throw, the crashing version incorrectly thinks there is no matching catch (although there is) and calls terminate. When I invoke the program via runner, the exception is properly caught.

My question is any idea why the extra exec changes the behavior of the exec'ed program?

Answer 1

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

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

That a change of the ordering of strings in RAM unearths a bug is somewhat freakish, but stranger things have happened.

Answer 2

It's possible that the .so files loaded by the runner are causing the runee to work correctly. Try ldd'ing each of the binaries and see if any libraries are loading different versions/locations.

Answer 3

I wonder if you're passing something different in argv[0] to what the shell is. I can't see obviously from what you're writing above, but it's possible that you're setting argv[0] to the actual first argument to the program, whereas the shell sets it to its called name (e.g. full or short path)

Answer 4

Perhaps the called program has a memory leak. Try running it with valgrind or some other memory checking tool. After you have a memory error everything else is undefined behaviour (and so everything can happen).

Answer 5

I guess two things you could compare between 'working' and 'crashing' versions - open file descriptors and signal handlers - as these do get passed on by exec.

I can't see how they are the problem / be different, but it might be worth eliminating them.