Question

在Linux系统上，我试图通过system()调用在运行时调用程序。系统调用以不等于零的返回码退出。

在错误代码上调用WEXITSTATUS会给出“127”。

根据系统的手册页，此代码表示无法调用/bin/sh：

如果/bin/sh无法执行，退出状态将是执行exit(127)的命令的退出状态。

我检查过：/bin/sh是指向bash的链接。 bash在那里。我可以从shell执行它。

现在，我怎样才能找出无法调用/bin/sh的原因？任何内核历史记录还是什么？

编辑：

在非常有用的提示（见下文）后{i} strace -f -p <PID>。这是我在system电话中获得的内容：

Process 16080 detached
[pid 11779] <... select resumed> )      = ? ERESTARTNOHAND (To be restarted)
[pid 11774] <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 127}], 0, NULL) = 16080
[pid 11779] --- SIGCHLD (Child exited) @ 0 (0) ---
[pid 11779] rt_sigaction(SIGCHLD, {0x2ae0ff898ae2, [CHLD], SA_RESTORER|SA_RESTART, 0x32dd2302d0},  <unfinished ...>
[pid 11774] rt_sigaction(SIGINT, {0x2ae1042070f0, [], SA_RESTORER|SA_SIGINFO, 0x32dd2302d0},  <unfinished ...>
[pid 11779] <... rt_sigaction resumed> {0x2ae0ff898ae2, [CHLD], SA_RESTORER|SA_RESTART, 0x32dd2302d0}, 8) = 0
[pid 11779] sendto(5, "a", 1, 0, NULL, 0 <unfinished ...>
[pid 11774] <... rt_sigaction resumed> NULL, 8) = 0
[pid 11779] <... sendto resumed> )      = 1
[pid 11779] rt_sigreturn(0x2 <unfinished ...>
[pid 11774] rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x32dd2302d0},  <unfinished ...>
[pid 11779] <... rt_sigreturn resumed> ) = -1 EINTR (Interrupted system call)
[pid 11779] select(16, [9 15], [], NULL, NULL <unfinished ...>
[pid 11774] <... rt_sigaction resumed> NULL, 8) = 0
[pid 11774] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 11774] write(1, "Problems calling nvcc jitter: ex"..., 49) = 49
[pid 11774] rt_sigaction(SIGINT, {0x1, [], SA_RESTORER, 0x32dd2302d0}, {0x2ae1042070f0, [], SA_RESTORER|SA_SIGINFO, 0x32dd2302d0}, 8) = 0
[pid 11774] rt_sigaction(SIGQUIT, {0x1, [], SA_RESTORER, 0x32dd2302d0}, {SIG_DFL, [], SA_RESTORER, 0x32dd2302d0}, 8) = 0
[pid 11774] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid 11774] clone(Process 16081 attached (waiting for parent)
Process 16081 resumed (parent 11774 ready)
child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7fff0177ab68) = 16081
[pid 16081] rt_sigaction(SIGINT, {0x2ae1042070f0, [], SA_RESTORER|SA_SIGINFO, 0x32dd2302d0},  <unfinished ...>
[pid 11774] wait4(16081, Process 11774 suspended
 <unfinished ...>
[pid 16081] <... rt_sigaction resumed> NULL, 8) = 0
[pid 16081] rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x32dd2302d0}, NULL, 8) = 0
[pid 16081] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 16081] execve("/bin/sh", ["sh", "-c", 0xdda1d98], [/* 58 vars */]) = -1 EFAULT (Bad address)
[pid 16081] exit_group(127)             = ?
Process 11774 resumed

当谈到/bin/sh的电话时，它说错误的地址。为什么？

编辑：

这里涉及失败的system的整个部分（这里已经是安全副本到位）：

  std::ostringstream jit_command;

  jit_command << string(CUDA_DIR) << "/bin/nvcc -v --ptxas-options=-v ";
  jit_command << "-arch=" << string(GPUARCH);
  jit_command << " -m64 --compiler-options -fPIC,-shared -link ";
  jit_command << fname_src << " -I$LIB_PATH/include -o " << fname_dest;

  string gen = jit_command.str();
  cout << gen << endl;

  char* cmd = new(nothrow) char[gen.size()+1];
  if (!cmd) ___error_exit("no memory for jitter command");
  strcpy(cmd,gen.c_str());

  int ret;

  if (ret=system(cmd)) {

    cout << "Problems calling nvcc jitter: ";

    if (WIFEXITED(ret)) {
      printf("exited, status=%d\n", WEXITSTATUS(ret));
    } else if (WIFSIGNALED(ret)) {
      printf("killed by signal %d\n", WTERMSIG(ret));
    } else if (WIFSTOPPED(ret)) {
      printf("stopped by signal %d\n", WSTOPSIG(ret));
    } else if (WIFCONTINUED(ret)) {
      printf("continued\n");
    } else {
      printf("not recognized\n");
    }

    cout << "Checking shell.. ";
    if(system(NULL))
      cout << "ok!\n";
    else
      cout << "nope!\n";

    __error_exit("Nvcc error\n");

  }
  delete[] cmd;
  return true;

输出：

/usr/local/cuda/bin/nvcc -v --ptxas-options=-v -arch=sm_20 -m64 --compiler-options -fPIC,-shared -link bench_cudp_Oku2fm.cu -I$LIB_PATH/include -o bench_cudp_Oku2fm.o
Problems calling nvcc jitter: exited, status=127
Checking shell.. ok!

编辑（代码的第一个版本）：

string gen = jit_command.str();
cout << gen << endl;
int ret;
if (ret=system(gen.c_str())) {
  ....

字符串创建的复杂性不是问题所在。由于strace显示“错误地址”是问题所在。它是合法的字符串。不应该出现“不良地址”。

据我所知，std::string::c_str()返回一个const char *，它可能指向libc ++的临时空间，其中可能保留了该字符串的只读副本。

不幸的是，错误不是真正可重现的。对system的调用在失败之前会多次成功。

我不想仓促，但它闻起来像是内核，libc或硬件中的错误。

编辑：

我为失败的strace系统调用生成了更详细的strace -f -v -s 2048 -e trace=process -p $!输出（execve）：

首先是一个接下来的电话：

[pid  2506] execve("/bin/sh", ["sh", "-c", "/usr/local/cuda/bin/nvcc -v --ptxas-options=-v -arch=sm_20 -m64 --compiler-options -fPIC,-shared -link /home/user/toolchain/kernels-empty/bench_cudp_U11PSy.cu -I$LIB_PATH/include -o /home/user/toolchain/kernels-empty/bench_cudp_U11PSy.o"], ["MODULE_VERSION_STACK=3.2.8", ... ]) = 0

现在失败者：

[pid 17398] execve("/bin/sh", ["sh", "-c", 0x14595af0], <list of vars>) = -1 EFAULT (Bad address)

这里<list of vars>是完全相同的。它似乎不是导致错误地址的环境变量列表。正如Chris Dodd所提到的，execve的第三个参数是原始指针0x14595af0，strace认为（并且内核同意）是无效的。 strace无法将其识别为字符串（因此它会打印十六进制值而不是字符串）。

编辑：

我从指针值cmd中插入了print，看看父进程中该指针的值是什么：

  string gen = jit_command.str();
  cout << gen << endl;
  char* cmd = new(nothrow) char[gen.size()+1];
  if (!cmd) __error_exit("no memory for jitter command");
  strcpy(cmd,gen.c_str());
  cout << "cmd = " << (void*)cmd << endl;
  int ret;
  if (ret=system(cmd)) {
    cout << "failed cmd = " << (void*)cmd << endl;
    cout << "Problems calling nvcc jitter: ";

输出（对于失败的呼叫）：

cmd = 0x14595af0
failed cmd = 0x14595af0
Problems calling nvcc jitter: exited, status=127
Checking shell.. ok!

它的指针值与strace的第3个参数相同。（我更新了上面的strace输出。）

关于cmd指针的32位查看：我检查了cmd指针的值以进行后续调用。看不出结构上的任何差异。当cmd调用成功时，这是system的值之一：

cmd = 0x145d4f20

因此，在system调用之前，指针有效。由于上面的strace输出表明子进程（在调用fork之后）收到正确的指针值。但是，由于某种原因，指针值在子进程中被标记为无效。

现在我们认为：

libc / kernel bug
硬件问题

编辑：

同时让我发布一个解决方法。它是如此愚蠢，被迫实施类似的东西...但它的工作原理。因此，如果system调用失败，则会执行以下代码块。它会分配新的命令字符串并重试，直到成功（而不是无限期）。

    list<char*> listPtr;
    int maxtry=1000;
    do{
      char* tmp = new(nothrow) char[gen.size()+1];
      if (!tmp) __error_exit("no memory for jitter command");
      strcpy(tmp,gen.c_str());
      listPtr.push_back( tmp );
    } while ((ret=system(listPtr.back())) && (--maxtry>0));

    while(listPtr.size()) {
      delete[] listPtr.back();
      listPtr.pop_back();
    }

编辑：

我刚看到在一次特定运行中的这种解决方法不起作用。它全程完成，1000次尝试，都使用新分配的cmd命令字符串。全部1000失败。不仅如此。我尝试了不同的Linux主机（相同的Linux /软件配置）。

考虑到这一点，可能会排除硬件问题。（必须在2个物理上不同的主机上）。仍然是一个内核错误??

编辑：

torek，我将尝试安装修改后的system电话。给我一点时间。

Answer 1

这很奇怪。 strace理解execve的参数是（指向）字符串，因此它打印出指向的字符串，除非指针无效 - 在这种情况下，它会打印出指针的原始十六进制值。所以strace line

[pid 16081] execve("/bin/sh", ["sh", "-c", 0xdda1d98], [/* 58 vars */]) = -1 EFAULT (Bad address)

非常有意义 - execve的第三个参数是原始指针0xdda1d98，strace认为（并且内核同意）无效。所以问题是，无效指针是如何到达此处的。这应该是cmd，它刚刚从new返回。

我建议把这行

printf("cmd=%p\n", cmd);

在系统调用之前，找出C代码认为指针是什么。

看看其余部分，它看起来像是在64位系统上运行（来自打印的指针），无效的0xdda1d98看起来像是32位指针，所以看起来似乎是某种32/64位的搞砸（有人只保存和恢复64位寄存器的32位，或者其他一些）。

Answer 2

捎带/延长@Chris Dodd的答案，考虑system本身看起来（故意过于简化），如下所示：

int system(char *cmd) {
    pid_t pid = fork();
    char *argv[4];
    extern char **environ;

    if (pid == 0) { /* child */
        argv[0] = "sh";
        argv[1] = "-c";
        argv[2] = cmd;
        argv[3] = NULL;
        execve("/bin/sh", argv, environ);
        _exit(127);
    }
    if (pid < 0) ... handle error ...
    ... use OS wait() calls to wait for result from child process ...
    return status; /* as provided by sh -c, or from _exit(127) above */
}

鉴于“64位系统”和“寄存器似乎以32位丢失”，可能值得对代码执行objdump并查看argv [2]是否从寄存器设置，其高位可能会以某种方式丢失在clone通话期间（我fork上方glibc正在使用clone提高效率）。

更新：根据strace输出，克隆调用没有使用CLONE_VM和CLONE_VFORK（不知道为什么不，这些应该使调用更有效率）所以孩子是一个“正常”的孩子（一个老式的Unix风格的fork）。一位同事建议，可能失败的地址位于一个不会被复制到子进程中的地图中。失败后/proc/self/maps的内容会很有趣;我们可以看看如何映射失败的地址。将这些地图与孩子中的地图进行比较会更有趣。但是，为了获得孩子中的那些，您需要覆盖glibc版system，并在/proc/self/maps失败后添加一些内容以便阅读execve做_exit。

为什么system（）失败并显示错误代码127？

2 个答案: