Почему пользовательский обработчик сигналов изменяет значение кода возврата Python subprocess.Popen ()? - PullRequest
Новая
       31

Почему пользовательский обработчик сигналов изменяет значение кода возврата Python subprocess.Popen ()?

0 голосов
/ 13 января 2019

Рассмотрим следующую программу: 

int main()
{
    *((int*)0) = 5;
    return 0;
}

Компиляция и запуск на bash производит: 

$ ./crash
Segmentation fault (core dumped)
$ echo $?
139

Если я запускаю программу из следующего скрипта Python, 

import subprocess as sp

p = sp.Popen('./crash')
p.wait()
print 'crash: %d' % p.returncode

это производит это: 

$ python retcode.py 
crash: -11

Возвращаемое значение -11, поскольку в документации 1016 * написано,

Отрицательное значение -N указывает, что ребенок был прерван по сигналу N (только Unix).

SIGSEGV является сигналом 11 (kill -l)

Если я установлю обработчик сигнала в исходную программу, 

#include<signal.h>
#include<stdlib.h>
#include<stdio.h>

void handler(int sig)
{
    printf("I am the handler\n");
    exit(128+sig);
}

int main()
{
    signal(SIGSEGV, handler);
    *((int*)0) = 5;
    return 0;
}

Компиляция и запуск из bash производит, 

$ ./crash_sighandle 
I am the handler
$ echo $?
139

Однако, если я запускаю ту же программу, используя приведенный выше скрипт Python, я получаю 

$ python retcode.py 
I am the handler
crash: 139

Короче говоря, Popen() видит возвращаемое значение, отличное от -11. Я попробовал другой вариант. Ни один не дает ожидаемый результат (-11). Как получить согласованное возвращаемое значение даже после установки обработчика сигнала

...