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

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.