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

Question

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

0

У нас есть библиотека IO файлов, которая в основном записывает данные в файл в причудливом формате, а затем читает файл обратно. Мы должны убедиться, что файл доступен для чтения, даже если библиотека (или компьютер) вылетает из-за середины записи.

Мы знаем, как писать программу, которая сама врезается. Мы можем использовать kill(getpid()) для имитации сбоя. Или мы можем использовать 1/0 и так далее. Поэтому мы напишем программу, которая открывает библиотеку, записывает некоторые данные, а затем убивает себя прямо посередине. Тогда у нас будет файл в его полупеленном состоянии, который мы можем открыть в читателе, чтобы узнать, может ли читатель обработать файл.

Вопрос: как сделать это автоматизированным?

Например, нам нужен наш тестовый пакет (который автоматически проверяет многие аспекты библиотеки и дает пропуск/сбой), чтобы создать новую программу/процесс, который начинает писать файл, а затем совершает самоубийство. Затем управление можно вернуть обратно к модульному тесту, который затем может открыть файл, созданный процессом перед seppuku. Затем блок-блок может выполнить некоторую проверку в файле, чтобы убедиться, удовлетворен ли наше требование "оставить допустимый файл после сбоя".

Я смотрел на функцию exec которая, похоже, делает то, что нам нужно. Однако мне не удалось выяснить, вернется ли exec обратно к программе/процессу вызывающего, если программа exec 'd сработает.

Joseph Malicke 13 апр. 2014, в 00:01

Источник

0

Нет, exec полностью переносит выполнение в новую программу. Вам нужно fork дочерний процесс.
Oliver Charlesworth 12 апр. 2014, в 21:30
0

Ах, ладно, похоже, вилка - это путь. Кажется хитрым :(
Elegant Codeworks 12 апр. 2014, в 21:32
0

Смотрите пример fork, exec, waitpid. Также простой скрипт bash может сделать это.
alexander 12 апр. 2014, в 21:43
0

Использование system может быть достаточным - это проще, чем явное использование fork() exec() и т. Д. Если программа запущена и знает, что она должна совершать seppuku, этого, вероятно, будет достаточно. Единственный раз, когда exec() возвращается, когда ядру не удается выполнить exec() программу. Если программа найдена, даже если она падает до входа в main() , то exec() не вернется.
Jonathan Leffler 13 апр. 2014, в 00:42

Показать ещё 2 комментария

Теги:

c++

c

linux

2 ответа

1

Это несколько соображений вне коробки - предлагаемый альтернативный способ проведения вашего тестирования.

Если ваше тестирование должно определить, как ваша основная программа работает с файлом, который усечен при сбое, то более детерминированным методом тестирования является получение копии действительного файла, усечение его с помощью truncate() или ftruncate() и затем запустите свою основную программу. Вы даже можете запустить тесты с размером файлов от 0 до полного размера.

Если вы обеспокоены тем, что первые 20 KiB являются первой частью некоторого нового содержимого файла, а остальные 30 KiB (ради аргумента) - это оставшаяся часть предыдущей версии, тогда вам нужно работать немного сложнее, но вы все равно можете генерировать такие файлы детерминированным образом, а затем запускать свою основную программу на намеренно созданных поврежденных файлах.

Jonathan Leffler 12 апр. 2014, в 23:19

0

Добавьте нечеткое тестирование, чтобы получить все остальные комбинации частично записанных данных. И потому, что если вы этого не сделаете, взломщики будут.
Ben Voigt 13 апр. 2014, в 01:17

Ещё вопросы

Нет, exec полностью переносит выполнение в новую программу. Вам нужно fork дочерний процесс.
Ах, ладно, похоже, вилка - это путь. Кажется хитрым :(
Смотрите пример fork, exec, waitpid. Также простой скрипт bash может сделать это.
Использование system может быть достаточным - это проще, чем явное использование fork() exec() и т. Д. Если программа запущена и знает, что она должна совершать seppuku, этого, вероятно, будет достаточно. Единственный раз, когда exec() возвращается, когда ядру не удается выполнить exec() программу. Если программа найдена, даже если она падает до входа в main() , то exec() не вернется.
Добавьте нечеткое тестирование, чтобы получить все остальные комбинации частично записанных данных. И потому, что если вы этого не сделаете, взломщики будут.

Mats Petersson · Accepted Answer · 2014-04-12T21-54-00.000Z

У меня есть "testrunner.cpp" для моего проекта компилятора, который отлично справляется с компилятором и сгенерированным сбой тестового кода (к сожалению, во время разработки вы обнаружите, что обе эти вещи могут произойти, когда вы сделал что-то не так, как в компиляторе, так и сам код для самого тестового кода - или оба!). Это довольно просто, он использует стандартную библиотечную функциональную system для создания нового процесса.

Вы можете, конечно, также использовать fork за которым следует exec, а затем использовать waitpid или другую функцию типа wait для получения результатов. system по существу такова, но она также запускает оболочку, поэтому вы можете легко использовать перенаправление (что делает мой "testrunner.cpp").

system (или wait) вернет результирующий код исполняемой программы. В моем случае любой "ненулевой" результат считается неудачным (мне все равно, ПОЧЕМУ он не прошел - все должно пройти!), Но вам может потребоваться проверить "он сработал или завершился нормально" в вашем коде.

Мой "testrunner.cpp" можно найти здесь (это полный код для запуска тестов, помимо компилятора и "diff" - и, конечно, для его использования, вам также нужны источники тестов в том же каталоге): https ://github.com/Leporacanthicus/lacsap/blob/master/test/testrunner.cpp

В частности, runcmd - это вызов вызова system.