Я пытаюсь выследить очень странный сбой. Что странно, так это обходной путь, который кто-то обнаружил и который я не могу объяснить.Как может exec изменить поведение программы exec'ed
Обойти это небольшая программа, которую я буду называть «бегуна»:
#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;
}
Как вы можете видеть, все это делает программа использовать execvp заменить себя с другой программой.
программа падает, когда она непосредственно вызывается из командной строки:
/path/to/prog args # this crashes
но прекрасно работает, когда она косвенно вызывается через мой бегун прокладки:
/path/to/runner /path/to/prog args # works successfully
для жизни меня, Я могу понять, как наличие дополнительного exec может изменить поведение выполняемой программы (так как вы можете видеть, что программа не меняет среду).
Некоторые фоне аварии. Сама авария происходит во время выполнения C++. В частности, когда программа делает throw, ошибочная версия ошибочно думает, что нет соответствующего улова (хотя есть) и вызывает terminate. Когда я вызываю программу через бегун, исключение будет правильно поймано.
Мой вопрос - любая идея, почему дополнительный exec изменяет поведение программы exec'ed?
Я не знаю: Но работает ли execvp рабочий каталог? Какие аргументы вы передаете? –
@MartinYork - AFAIK, 'execvp' никогда не меняет рабочий каталог (для которого требуется вызов' chdir', а runner этого не делает). Конкретные аргументы не имеют значения; описанное поведение не зависит от конкретных аргументов, переданных программе. –
Это делает то же самое, если вы используете 'execv()' вместо 'execvp()'? – caf