Темы не помогут. Если вам нужно отказаться от поиска утечки, то единственное решение, которое сдерживает ее эффект, - это время от времени запускать новый процесс (например, когда в результате теста общее потребление памяти слишком велико для вас - - вы можете легко определить размер виртуальной машины, прочитав /proc/self/status
в Linux и другие подобные подходы в других ОС).
Убедитесь, что общий сценарий принимает необязательный параметр, чтобы сообщить ему, с какого номера теста (или другого идентификатора теста) начинаться, чтобы, когда один экземпляр сценария решает, что он занимает слишком много памяти, он может сообщить своему преемнику, где перезапустить с.
Или, если быть более точным, убедитесь, что после завершения каждого теста его идентификация добавляется в некоторый файл с хорошо известным именем. Когда программа запускается, она начинается с чтения этого файла и, таким образом, знает, какие тесты уже были выполнены. Эта архитектура более надежна, поскольку она также охватывает случай, когда программа вылетает во время теста; конечно, чтобы полностью автоматизировать восстановление после таких сбоев, вам нужно, чтобы отдельная сторожевая программа и процесс отвечали за запуск нового экземпляра тестовой программы, когда он определит, что предыдущий сбой (он может использовать subprocess
для цель - ему также нужен способ сообщить, когда последовательность завершена, например, обычный выход из тестовой программы может означать, что при любом сбое или выходе со статусом! = 0 означает необходимость запуска нового нового экземпляра).
Если эти архитектуры привлекательны, но вам нужна дополнительная помощь в их реализации, просто прокомментируйте этот ответ, и я буду рад предоставить пример кода - я не хочу делать это «превентивно», если еще нет - невыраженные проблемы, которые делают архитектуры неподходящими для вас. (Это также может помочь узнать, на каких платформах вам нужно работать).