Predicting Method Crashes with Bytecode Operations
Sunghun Kim, Thomas Zimmermann, Rahul Premraj, Nicolas Bettenburg, and Shivkumar Shivaji. 2013. Predicting method crashes with bytecode operations. In Proceedings of the 6th India Software Engineering Conference (ISEC '13). ACM, New York, NY, USA, 3-12. DOI=http://dx.doi.org/10.1145/2442754.2442756
Описание
Современные системы мониторинга работы процессов* затрачивают большие вычислительные мощности. Например, Valgrind[1] может замедлять работу программы в 30 раз. Поэтому использование систем мониторинга в большинстве случаев возможно лишь при разработке программного продукта, но не при его работе у конечного пользователя. Корнем зла производительности систем мониторинга является анализ всего программного продукта целиком. Сокращение области потенциальной опасности увеличило бы скорость работы таких систем на порядок. Авторы статьи исследовали возможность определения crash-prone(падение подобным) и non-crash-prone(без падений подобным) методов по байткоду. Проверка результата на байткодах AspectJ[2] и Eclipse[3] показала, что авторы научились определять crash-prone методы с accuracy 80-85%.
Введение
В данной работе исследуется возможность предсказания методов программы, которые имеют наибольшую вероятность падения(crash-prone).
В качестве подопытных использовались последовательности операций в байткоде программ. Кажется интуитивным, что некоторые последовательности операций имеют больший риск падения, чем другие. Результаты исследования подтверждают данную гипотезу. Так 80-85% точности было достигнуто при проверке продуктов AspectJ и Eclipse.
Методы, в которых произошло падение(Crash-prone)
Рисунок 1(Figure 1) показывает в общих чертах построение классификатора для предсказания crash-prone и non-crash-prone методов. Этап А изображает, что авторы использовали баг треккеры исследуемых продуктов(AspectJ, Eclipse) для создания обучающей выборки. Из баг репортов интересовали те, которые содержали stack traces падений. Они обычно содержат информацию с типом ошибки, детальным сообщением и список методов, которые участвовали в падении.
Stake trace содержит множество фреймов(frame) отображающих детали падения. Авторы статьи считали упавшим методом тот, который находился в верхушке списка вызовов(call stack). Для рисунка 2(figure 2) таким методом является readClassInfo.
Crash-prone методом считался тот, который упал хотя бы раз. Для AspectJ получилось 209 уникальных методов, а для Eclipse – 8,621.
Извлечение фич
Пункт B рисунка 1 соответствует извлечению фич. Первым шагом на этом пути является определение кода упавшего метода. Тривиальная на первый взгляд задача является недооценённой. Проблемами на пути к её решению являются большое количество версий продуктов, а также перегрузка(overloading) и переопределение(overriding) методов.
Для извлечения фич из найденных участков байткода строились n-граммы из последовательностей определенной длины базовых блоков. Базовым блоком считалась последовательность операторов байткода, которая исполняется последовательно без использования прерывания(halting) и ветвения(циклы, if-конструкции). Авторы статьи использовали в качестве фич 1, 2 и 3 - граммы.
