В системе Linux я пытаюсь вызвать программу во время выполнения с помощью вызова system()
.
Системный вызов завершается с кодом возврата, отличным от нуля.
Вызов WEXITSTATUS
по коду ошибки дает «127».
Согласно справочной странице системы этот код указывает, что /bin/sh
не может быть вызвано:
В случае, если /bin/sh
не может быть выполнено,
статус выхода будет таким же, как у команды, которая выполняет exit(127)
.
Я проверил: /bin/sh
является ссылкой на bash
. bash
есть. Я могу выполнить его из оболочки.
Теперь, как я могу узнать, почему /bin/sh
нельзя было вызвать?
Любая история ядра или что-то в этом роде?
Изменить:
После очень полезного совета (см. ниже) i strace -f -p
процесс. Вот что я получаю во время вызова 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
, он говорит, что адрес неверный. Почему так ?
Редактировать:
Здесь вся часть, связанная со сбоем системы
(здесь уже имеется безопасная копия в буфер):
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)
Здесь <список переменных>
идентичен. Кажется, это не список переменных среды, которые вызывают плохой адрес.
Как упомянул Крис Додд, третий аргумент execve — необработанный указатель 0x14595af0, который strace считает (и с этим соглашается ядро) недопустимым. strace
не распознает его как строку (поэтому печатает шестнадцатеричное значение, а не строку).
Редактировать:
Я вставил распечатку значения указателя cmd
, чтобы увидеть значение этого указателя в родительском процессе:
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!
Это то же значение указателя, что и 3-й аргумент из strace
. (Я обновил вывод strace
выше).
Относительно 32-битного вида указателя cmd
: я проверил значение указателя cmd
для последующего вызова. Разницы в структуре не вижу.Это одно из значений cmd
, когда вызов system
завершается успешно:
cmd = 0x145d4f20
Итак, перед вызовом system
указатель действителен. Как видно из приведенного выше вывода strace
, дочерний процесс (после вызова fork
) получает правильное значение указателя. Но по какой-то причине значение указателя помечено как недопустимое в дочернем процессе.
Прямо сейчас мы думаем, что это либо:
Изменить:
А пока позвольте мне опубликовать обходной путь. Так глупо быть вынужденным реализовать что-то подобное... но это работает. Таким образом, следующий блок кода выполняется в случае сбоя вызова 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, я попробую установить модифицированный системный
вызов. Дайте мне немного времени для этого.