how can exec change the behavior of exec'ed program

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: %sn", 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?

---

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.

---

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).

---

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.

链接地址: http://www.djcxy.com/p/45194.html

上一篇: Drupal查询生成器

下一篇: exec如何改变执行程序的行为