Управление процессами

ноль.

После этого можно запустить отлаживаемый процесс. В тот момент, когда

управление в отлаживаемом процессе перейдет на адрес по которому мы

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

программы и произойдет некоторое событие, связанное с известным нам

сигналом.

Для отладчика это будет видно так. Он запустил отлаживаемый процесс

(ptrace(7,...)), и обратился к функции wait (ждет события в отлаживаемом

процессе). Как только событие произошло (т.е. пришел сигнал), отладчик

смотрит, не совпадает ли этот сигнал с сигналом, который связан с приходом

в контрольную точку. Если не совпадает, то отладчик произведет действия

соответствующие этому сигналу (какие-то).

Если сигнал совпадает, то есть подозрение, что мы пришли в контрольную

точку. В этом случае отладчик читает из контекста процесса адрес, по

которому процесс был остановлен. Если этот адрес совпал с одним из адресов

контрольных точек в таблице отладчика, то это означает, что мы пришли в

контрольную точку (и деление на ноль на самом деле - контрольная точка).

Если отладчик не нашел соответствующего адреса, то это означает, что

действительно произошло деление на ноль и отладчик должен выполнить какие-

то действия (обработка АВОСТа).

Если отладчик зафиксировал контрольную точку, он может выполнить какие-

то действия по отладке программы. Когда-нибудь настанет необходимость

продолжить выполнение программы, и пусть при этом мы хотели бы сохранить

эту контрольную точку. Отладчик делает следующее. Он восстанавливает

оригинальное содержимое машинного слова, которое берет из таблицы. Затем

включает режим трассировки и запускает программу с прерванного адреса.

Выполняется одна эта команда и сразу после нее происходит остановка

процесса на следующей команде. После этого отладчик восстанавливает

контрольную точку (опять вписывает деление на ноль) и запускает выполнение

процесса с прерванной точки (отключив режим трассировки).

Снятие контрольной точки делается также просто: восстанавливается

содержимое по соответствующему адресу и из таблицы выбрасывается

соответствующая строка. Можно сделать контрольную точку так, чтобы она

работала, к примеру, только 10 раз. Для этого надо добавить в таблицу еще

счетчик, из которого при каждом приходе в контрольную точку будет

вычитаться единица, и как только он обнулится, контрольная точка будет

автоматически снята.

Чтение/запись обсуждать не будем - это понятно. Остановка

осуществляется через посыл сигнала, либо через возникновение события в

отлаживаемом процессе, продолжение - через функцию ptrace(7,...). Шаговый

режим отладки осуществляется через ptrace(9,...). Передача управления на

любую точку - нет проблем. Обработка аварийных остановок - с помощью wait.

Вот, с точностью до некоторых деталей, схема организации адресного

отладчика, т.е. отладчика, который оперирует адресами. Если возникает

необходимость отладки в терминах языка высокого уровня, то в отладчике

добавляются таблицы, из которых можно определить адреса и свойства

переменных и адреса операторов.

В этом случае, предположим, чтение содержимого языковой переменной

программы будет осуществляться следующим образом. Отладчик обращается к

своей таблице и ищет строчку переменной с именем Name. В том случае, если

эта переменная существует и находиться в области видимости и существования,

из таблицы выбираются атрибуты этой переменной. Если эта переменная

обыкновенная статическая, то выбирается ее адрес и мы обращаемся к ptrace с

чтением данных по адресу. Если эта переменная автоматическая, то с ней

связано смещение относительно вершины стека. Это означает, чтобы добраться

до содержимого автоматической переменной мы должны из контекста прочесть

вершину стека (это есть некий адрес), после этого к этому адресу прибавить

смещение, связанное с автоматической переменной, и уже по полученному

результату как адресу прочесть информацию из адресного пространства

процесса. Третий вариант: переменная - регистровая. В этом случае с именем

Name будет ассоциирована информация о том, что эта переменная регистровая,

а, в этом случае, там будет указан номер регистра, на котором она

размещена. Для чтения информации из регистров я обращаюсь к чтению

информации из контекста и читаю соответствующий регистр.

Изменить содержимое переменной можно аналогичным путем в соответствии

с тремя рассмотренными вариантами. Кстати, в языке Си, объявление

регистровой переменной на самом деле есть пожелание программиста о том,

чтобы при хорошем стечении обстоятельств в программе и добром желании

системы программирования разместить эту переменную на регистре. Т.е. она

будет размещена либо на регистре, и тогда она будет реально регистровой,

либо она будет автоматической.

Давайте попробуем написать маленький пример. Мы будем писать программу

в нотации операционной системы Free BSD. Для других операционных систем

надо уточнить функцию ptrace в мануалах.

Отлаживаемый процесс

int main() /* эта программа находится в процессе-сыне SON */

{

int i;

return i/0;

}

Процесс - отладчик

#iinclude

#iinclude

#iinclude

#iinclude

#iinclude

#iinclude

#iinclude

int main(int argc, char *argv[])

{

pid_f pid;

int status;

struct reg REG;

switch (pid=fork()){ /* формируем процесс, в pid -

код ответа */

case -1: perror("Ошибка fork"); exit(25); /*

Обработка ошибки */

case 0: ptrace( PT_TRACE_ME, 0, 0, 0); execl("SON","SON",0);

/* В сыне: разрешаем отладку и загружаем процесс SON. При этом произойдет

приостановка сына перед выполнением первой команды нового тела процесса

(а точнее в нем возникнет событие, связанное с сигналом SIG_TRAP) */

default: break; /* В отце: выход из switch */

}

for(;;) {

wait(&status); /* ждем возникновения события в сыне

(сигнала SIG_TRAP) */

ptrace(PT_GETREGS,pid,(caddr_t)®,0); /* Читаем

регистры, например, чтобы их

распечатать */

printf("EIP=%0.8x\ + ESP=%0.8x\n",REG.r_eip, REG.r_esp); /*

печатаем регистры EIP и ESP */

if(WIFSTOPPED(status)||WIFSIGNALED(status)){ /* проверяем с помощью

макросов условия функции wait,

и если все нормально,

продолжаем разбирать причину

остановки программы */

printf("Сигналы: ");

switch(WSTOPSIG(status)){ /*анализируем код сигнала, по

которому произошла остановка

*/

case SIGINT: printf("INT \n"); break; /* выводим

причину остановки */

case SIGTRAP: . . . . . . break;

.

.

.

default: printf("%d", WSTOPSIG(status));

}

if (WSTOPSIG(status)!=SIGTRAP) exit(1); /* Если процесс

остановился не по

SIGTRAP тогда выходим */

if (WIFEXITED(status)){ /* проверяем случай, если

процесс завершился нормально */

printf("Процесс завершился, код завершения = %d \n",

WEXITSTATUS(status));

exit(0);

}

ptrace(PT_CONTINUE, pid, (caddr_t) 1, 0); /* Если был SIGTRAP,

продолжаем процесс */

} /* End for(;;) */

exit(0);

}

Мы обработали ситуацию остановки и ситуацию нормального завершения

процесса. При первой итерации цикла, мы остановимся и дождемся первого

сигнала SIGTRAP. По этому сигналу мы выведем нужную нам информацию. Затем,

проверим, не закончился ли наш процесс нормально, и т.к. он не может

закончиться нормально (он выполняет деление на ноль), то мы обратимся к

функции ptrace, которая продолжит процесс с прерванного места. Мы снова

попадем на wait. Здесь мы дождемся события, связанного с делением на ноль,

и обработаем это событие. В итоге, на стандартный вывод попадут две порции

данных: первая - вывод точки прерывания, вершины стека и сигнала для

начальной ситуации, и второе - мы получим блок той же информации и код

сигнала FPI (Float Point Interrupt) на делении на ноль.

Рекомендуется разобрать этот пример и адаптировать для ваших машин на

практикуме.

Лекция №16

Нелокальные переходы

На этой лекции мы с вами обсудим некоторые дополнительные возможности

по организации управления ходом процесса в UNIX. Возникает необходимость

предоставления в процессе возможности перезапуска в процессе каких-то его

веток при возникновении некоторых ситуаций.

Предположим, у нас есть процесс, который занимается обработкой

достаточно больших наборов данных, и мы хотим написать процесс, который

будет работать следующим образом. В начальный момент времени наш процесс

получает некоторый набор данных, и начинает каким-то образом выполнять

вычисления. Известно, что при некоторых наборах данных, возможно

возникновение внештатных ситуаций, например, переполнение или деление на

ноль. Мы бы хотели написать программу, которая обрабатывала бы внештатную

ситуацию, и после обработки ее переходила бы снова в начальную точку

процесса, загружала бы новые наборы данных и начинала работу с ними.

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

возникающие в процессе. Это можно сделать с помощью функции signal и ее

возможностей. Кроме того, нам бы хотелось возвращаться в некоторые

помеченные в программе точки, не через последовательность входов и выходов

из функции, а с помощью безусловного перехода (как бы goto N), потому что

механизм обработки сигналов не позволит корректно работать с такой задачей.

Можно в принципе написать функцию обработки сигнала, которая при

возникновении одного из сигналов делает повторный вызов всей программы. Но

это не совсем корректно, т.к. при вызове функции-обработчика сигнала

фиксируется состояние стека, и в общем случае система ожидает выхода из

функции обработчика через return (при этом система возвращает нас в

прерванное место и освобождает стек). Если не будет произведен выход через

return, в стеке будет накапливаться ненужная информация, и все это приведет

к деградации системы.

Для решения таких задач имеются т.н. нелокальные переходы. Достигаются

они с использованием двух функций, которые продекларированы в setjmp.h и

имеют следующий интерфейс:

int setjmp(jmp_buf env);

int longjmp(jmp_buf env, int val);

Функция setjmp фиксирует точку обращения к этой функции, т.е. в

структуре данных, связанной с переменной env сохраняется текущее состояние

процесса (все атрибуты и в т.ч. состояние стека) в точке обращения к

setjmp. При обращении к этой функции здесь, setjmp возвращает нулевое

значение.

При обращении к функции longjmp(env, val) происходит передача

управления на точку, атрибуты которой зафиксированы в структуре env, т.е. в

то место, где было обращение к setjmp(env). При этом, после этого перехода

setjmp вернет значение val.

Рассмотрим маленький пример.

# include

jmp_buf save;

void main(void)

{ int ret;

switch(ret=setjmp(save)){ /* при первой проверке ret будет равно

нулю */

case 0: printf("....."); /* этот printf выведет некоторую

строку */

a(); /* вызов функции a() */

printf("....."); /* этот printf не сработает никогда

*/

default: break;

}

}

void a(void)

{ longjmp(save, 1); /* длинный переход на setjmp, ret будет

равно 1 */

}

Нелокальный переход - это несколько некорректная возможность

операционной системы, потому что нехорошо входить в блочные структуры не

через начало и выходить не через конец. Здесь все нарушается. Однако для

некоторых ситуаций эти возможности бывают полезны. В частности эти функции

могут быть использованы для передачи управления из функции-обработчика

сигнала в некоторую точку программы.

Длинный переход корректно работает со стеком. При входе в точку,

установленную с помощью setjmp, он восстанавливает все то состояние (в том

числе и состояние стека), которое было при установке этой точки. Надо

заметить, что longjmp восстанавливает не сам стек, а лишь указатель стека.

Работа со стеком всегда должна удовлетворять правилу: перед обращением

к функции и после возврата из нее, уровень стека должен быть одинаковым.

Если уровень станет больше или меньше, это гарантировано приведет к

проблемам, потому что рано или поздно стек либо переполнится, либо

программа полезет за нижний его уровень, что тоже плохо.

Вопрос: предположим мы установили setjmp в некоторой функции, мы

вернулись из этой функции, и затем выполнили переход longjmp (т.е. вошли в

функцию не сначала). Куда при выходе из этой функции произойдет возврат,

потому что в общем случае содержимое стекового кадра этой функции будет

случайным (т.к. в буфере env содержится указатель стека, а не сам стек)?

Возврат произойдет корректно, т.к. в буфере env адрес возврата будет

сохранен, а вот значения автоматических и регистровых переменных этой

функции действительно окажется случайным, потому что стек в буфере не

сохраняется. Но это есть правила игры. Т.е. здесь на решение программиста

налагается ответственность.

До сих пор мы с вами рассматривали взаимодействия, связанные с

родственными процессами. Реально, система UNIX имеет набор средств,

поддерживающих взаимодействие произвольных процессов. Одно из таких средств

- Система Межпроцессного Взаимодействия IPC (InterProcess Communications).

Суть этой системы заключается в следующем.

Имеется некоторое количество ресурсов, которые называются в системе

разделяемыми. К одному и тому же разделяемому ресурсу может быть

организован доступ со стороны произвольного количества произвольных

процессов. При этом возникает проблема именования этих разделяемых

ресурсов. Если мы вспомним неименованные каналы, за счет того, что каналы

передавались по родственному наследованию, всегда в процессе были известны

дескрипторы, ассоциированные с каналом. Фактически, если процесс получал

доступ к каналу, он уже знал, как именовать этот канал. Здесь

использовалось свойство родственной связи, когда какая-то информация, какие-

то средства передаются по наследству при формировании сыновьего процесса.

В системе IPC ситуация другая. Есть некоторый ресурс, в общем случае

произвольный, и к этому ресурсу могут добираться все, кто может именовать

этот ресурс. Для именования такого рода ресурсов в системе предусмотрен

механизм генерации т.н. ключей. Суть его заключается в следующем. По

некоторым общеизвестным данным (это могут быть текстовые строки или

цифровые комбинации) в системе генерируется уникальный ключ, который

ассоциируется с разделяемым ресурсом. Если процесс подтверждает этот ключ и

созданный разделяемый ресурс доступен для него, то после этого он может

работать с указанным разделяемым ресурсом по своему усмотрению.

Разделяемый ресурс создается некоторым процессом-автором. Автор

определяет основные свойства ресурса (предположим, размер) и права доступа.

Права доступа к ресурсу разделяются на три категории:

1. Права доступа самого автора.

2. Права доступ всех процессов, имеющих тот же идентификатор что и

автор.

3. Права доступа остальных.

Итак, система позволяет некоторому процессу создать разделяемый

ресурс, защитить его некоторым ключом и забыть о его существовании. После

этого все те, кто знают ключ, который открывает этот ресурс, могут работать

с содержимым этого ресурса. Возникают проблемы синхронизации доступа к

разделяемому ресурсу. Решение этих проблем и другие концептуальные

возможности предоставляет система IPC. Начиная со следующей лекции, мы

будем рассматривать конкретные средства системы IPC.

Система IPC поддерживает три разновидности разделяемых ресурсов:

1. Разделяемая память. Концептуально - это возможность нескольких

процессов иметь общее поле оперативной памяти, и соответственно

работать с этим полем, как с неким массивом, на который имеется

указатель. Проблема синхронизации здесь стоит особенно остро, но

базово средства работы с разделяемой памяти никакой синхронизации не

предполагают.

2. Механизм передачи сообщений. Разделяемым ресурсом здесь является

очередь сообщений. Эта очередь может содержать произвольное

количество (в пределах разумного) сообщений разной длины и разного

типа. Тип сообщения - это некоторый атрибут сообщения. Очередь

сообщений может рассматриваться как единая очередь всех сообщений в

хронологическом порядке, и как множество очередей, содержащих

сообщения определенного типа, где в каждой очереди также есть

хронологический порядок. Здесь также возникают проблемы

синхронизации.

3. Семафоры. Семафоры - это нечто, что позволяет синхронизовать доступ

к разделяемым ресурсам.

Страницы: 1, 2, 3, 4