CC BY
158
Труды ИСП РАН, том 27, вып. 6, 2015 г..
Использование различных представлений java-программ для статического анализа
Е.А. Карпулевич <karvulevich(a)isvras.ru>
ИСП РАН, 109004, Россия, г. Москва, ул. А. Солженицына, дом 25.
Аннотация. При статическом анализе программ важную роль играет используемое представление программного кода. В статье рассматриваются различные варианты представления программ, которые строятся на различных этапах компиляции, и детекторы программных ошибок, работающие на этих представлениях .
Ключевые слова: статический анализ, java, FindBugs, SVACE
1. Введение
В настоящее время программный код в больших проектах исчисляется миллионами строк кода. Неудивительно, что в таких проектах присутствует огромное количество ошибок разной степени критичности. Обнаружить среди миллионов строк несколько строк кода, содержащих дефект, непросто, а отследить утечку ресурса или возможное разыменование нулевого указателя вручную иногда практически невозможно. Для автоматизированной проверки программ и выдачи предупреждений об ошибках необходим инструмент, специализирующийся на поиске ошибок - статический анализатор. Для языка программирования Java существует несколько известных статических анализаторов: FindBugs[l], SVACE[2], Jlint[3] и др.
Во время работы компилятор также может выдавать большое количество предупреждений о потенциальных дефектах, однако, большое количество из них не приводят к сбоям в работе программы (например, когда в новой версии компилятора функция объявлена устаревшей). Кроме того, анализ производимый во время компиляции ограничен по времени и ресурсам, так как основная задача java-компилятора - предоставить байткод максимально быстро.
Для получения адекватных предупреждений об ошибках при анализе программ важны быстрые и корректные алгоритмы поиска ошибок, продуманная архитектура анализатора и информативное промежуточное
151
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
представление исходного кода программы, на котором строится весь анализ[4].
Различные промежуточные представления подходят для выявления в коде программы определенных типов ошибок. В статье проводится сравнение нескольких внутренних представлений в контексте статического анализа.
2. Получение различных внутренних представлений
Построение промежуточных представлений статического анализатора схоже с построением промежуточных представлений при компиляции исходного кода. На этапе лексического анализа исходного кода компилятор разбирает исходный код на последовательность лексем, из которых формирует абстрактное синтаксическое дерево. После этого происходят оптимизации на уровне абстрактного синтаксического дерева. На этапе кодогенерации по абстрактному синтаксическому дереву генерируется java-байткод. Для проведения анализа программы и дальнейшей её оптимизации по байткоду строится граф потока управления, граф вызовов.
Для статического анализа программ используются все перечисленные представления. На основе анализа байткода работают детекторы поиска ошибок по шаблонам, на абстрактном синтаксическом дереве - детекторы клонов кода и поиск ошибок несоответствия отступов. Построение графа потока управления не является необходимым этапом статического анализа. Но существует класс ошибок, которые неудобно искать, анализируя абстрактное синтаксическое дерево. Такие ошибки как утечки памяти и разыменование нулевых указателей позволяет обнаружить анализ графа потока управления.
3. Поиск ошибок через анализ байткода и абстрактного синтаксического дерева.
Большая часть предупреждений FindBugs является результатом работы алгоритмов поиска ошибок на байткоде по характерным шаблонам. С помощью библиотеки ASM[5] происходит обход инструкций байткода. Библиотека ASM позволяет работать с байткодом, она позволяет считывать байткод, а также предоставляет возможность по генерации и модификации байткода классов на лету.
Простой пример поиска по байткоду - детектор FindBugs ICAST_INTEGER_MULTIPLY_CAST_TO_LONG. Этот детектор проверяет на возможное переполнение типа integer до расширения до long. Такая ошибка содержится, например, в следующем фрагменте кода: long convertDaysToMilliseconds(int days) {return 1000*3600*24*days;}
Чтобы найти ошибку такого рода достаточно проверить наличие в байткоде последовательности из двух инструкций IMUL (умножение двух целых) 12Цпреобразование в long). Исправленный код может выглядеть так: long convertDaysToMilliseconds(int days) {return 1000L*3600*24*days;}
152
Труды ИСП РАН, том 27, вып. 6, 2015 г..
Сигнатурный поиск по байткоду позволяет найти достаточно простые ошибки, такие как проверка знака битовой операции и ошибка форматирования строки и пр. Алгоритмы поиска шаблонов таких ошибок хорошо работают на внутреннем представлении в виде последовательности команд байткода. Но существуют ошибки, для поиска которых анализ байткода не является достаточным или является крайне неэффективным. Например, для поиска ошибок повторного использования (клонов) кода лучше подходит абстрактное синтаксическое дерево. Для работы алгоритмов поиска утечек ресурсов необходима информация, которую можно восстановить из байткода, но которая в нем не содержится: где ресурс выделяется и освобождается, функция какого объекта вызывается. Также, для поиска утечек ресурсов требуются пользовательские спецификации, полная или частичная девиртуализация и межпроцедурный анализ.
Алгоритмы, реализованные на байткоде можно успешно реализовать на абстрактном синтаксическом дереве, однако реализация алгоритмов может стать значительно сложнее.
Рассмотрим детектор ICAST INTEGER MULTIPLY CAST TO LONG. Для того чтобы найти ошибку переполнения в абстрактном синтаксическом дереве необходимо проверять типы, значения и эмулировать арифметические операции, требуется значительно больше усилий.
Задачи из класса обнаружения клонов кода наоборот проще решаются на основе анализа абстрактного синтаксического дерева или анализа графа программных зависимостей[6]. Например, поиск ошибки повторного использования на байткоде затруднен необходимостью восстанавливать структуру условных операторов и операторов цикла, отсутствием информации об отступах и позициях идентификаторов.
Ошибки повторного использования возникают при дублировании кода копированием с внесением последующих изменений. Один из вариантов такой ошибки - копирование условного оператора с последующей заменой одной переменной на другую. Иногда программист успешно меняет копию фрагмента кода в пяти местах, а в одном забывает.
Чтобы найти ошибку повторного использования необходимо проверить похожесть двух фрагментов кода и провести анализ идентификаторов на наличие неполных замен. Замена идентификатора А будет неполной если везде, кроме одного места, идентификатор А заменен на идентификатор В. Кроме того, необходимо каким-то образом выявить похожие фрагменты кода, на которых и будет работать алгоритм. Для поиска похожих фрагментов кода в лоб можно использовать суффиксные деревья для поиска двух одинаковых подстрок в последовательности лексем, полученных из исходного кода. Но такой поиск достаточно медленный (сложность построения суффиксного дерева О(и), проверка похожих частей О(т)), так как поиск идет по всему коду файла.
153
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
Около 40% случаев копирования кода - копирование базовых блоков и функций[7]. Программист копирует небольшую функцию, условный оператор целиком, одно из условий условного оператора, заголовок цикла или весь цикл, заменяя один или несколько идентификаторов. К тому же чаще всего вставка происходит рядом копированием. Полная информация о таких фрагментах кода и о порядке их следования содержится в абстрактном синтаксическом дереве. В статическом анализаторе SVACE поиск повторного использования кода реализован через поиск похожих частей кода на абстрактном синтаксическом дереве (сложность обнаружения фрагментов для проверки 0(1), проверка похожих частей 0(ш)) с последующим анализом на повторное использование. В поиске повторного использования в анализаторе SVACE учитывается не только похожесть соседних фрагментов кода, но и соответствие отступов строк в них.
4. Анализ графа потока управления
Для поиска ошибок разыменования нулевого указателя или поиска утечки ресурса требуется анализировать пути исполнения программы. В таком случае можно использовать граф потока управления. Алгоритмы поиска ошибок на графе потока управления похожи на алгоритмы компиляторного анализа. Анализ графа потока управления используется в статическом анализаторе SVACE, что позволяет анализатору находить утечки ресурсов. Для корректной работы алгоритма поиска утечек необходима возможность хранения и передачи межпроцедурной информации, так как часто ресурс выделяется в одной функции, а используется и освобождается в других. В статическом анализаторе SVACE после анализа функции составляется и сохраняется её аннотация (информация о поведении функции). Кроме того пользователю необходимо указать какие функции выделяют, а какие закрывают ресурсы. Для этих целей в SVACE существует возможность добавлять пользовательские спецификации, описывающие поведение функций.
Поиск утечки ресурса идет в процессе обхода графа управления. Фиксируются моменты выделения и освобождения ресурса и, если было выделение ресурса а после не было его освобождения, выдается предупреждение об утечке.
В языке java все нестатические неприватные (то есть, protected, package и public) методы являются виртуальными. Для анализа графа потока управления на предмет ошибок нужно понимать метод какого класса вызывается в коде. Провести точную девиртуализацию не всегда представляется возможным. В таком случае можно прибегнуть к частичной девиртуализации. При частичной девиртуализации вместо одного кандидата методу соответствует некоторый набор кандидатов. Точность анализа при частичной девиртуализации для ряда детекторов снижается, но и время необходимое для девиртуализации сокращается. Понимать какой метод вызывается нужно, в том числе, для поиска утечек. В java возможна ситуация, когда базовый класс не выделяет
154
Труды ИСП РАН, том 27, вып. 6, 2015 г..
ресурс в отличие от своих потомков. В этом случае необходима девиртуализация, чтобы понять был ли выделен ресурс.
5. Поиск ошибок в многопоточных программах
Многие программы выполняются в несколько потоков с использованием примитивов синхронизации. При таком выполнении в процессе работы программы могут возникать взаимные блокировки или состояние гонки. Для задачи поиска взаимных блокировок граф потока управления является слишком громоздким и содержит информацию, которая не пригодится для поиска ошибок синхронизации. В инструменте Jlint много внимания уделили многопоточности. В качестве внутреннего представления Hint использует граф зависимостей блокировок[8], для того чтобы алгоритмы поиска ошибок синхронизации были проще и точнее.
6. Объединение представлений
Существуют и другие внутренние представления программ, например граф программных зависимостей и граф вызовов. Они подходят для других задач, например, граф программных зависимостей удобен для поиска клонов кода. Наличие нескольких представлений, на которых можно реализовать анализы различных классов ошибок заставляет задуматься о создании статического анализатора с несколькими внутренними представлениями. И действительно, многие анализаторы работают с несколькими представлениями. Например, статический анализатор SVACE ищет ошибки с помощью алгоритмов работающих на представлениях в виде байткода, графа вызовов, графа потока управления и др.
Кроме простого наличия нескольких представлений важна возможность безболезненного перехода от одного внутреннего представления к другому. При наличии такого перехода возможно не только повысить информативность навигации и сообщений об ошибках, но и делать несколько анализов на предмет одной ошибки на различных представлениях, а потом объединять результаты.
Очень важна связь между исходным кодом и внутренними представлениями программы. В процессе компиляции исходного кода в байткод происходит потеря некоторой части полезной информации о программе, например, полностью пропадает информация о наличии и количестве пробельных символов. Анализ ошибок такого рода можно проводить только на этапе компиляции.
В компиляторе javac есть внутреннее представление исходного кода в виде абстрактного синтаксического дерева. В таком случае достаточно интересной выглядит идея построить статический анализатор кода на основе компилятора, добавив в него несколько дополнительных внутренних представлений и реализацию алгоритмов для поиска ошибок.
155
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
В код компилятора javac успешно добавлены детекторы, работающие на абстрактном синтаксическом дереве, обнаруживающие ошибки повторного использования, ошибки выбора объекта для синхронизации, одинаковые ветки в условном или тернарном операторе. Полнота (отношение количества обнаруженных ошибок к общему количеству предупреждений) анализа для этих детекторов составила около 80%.
Список литературы
[ 1 ]. FinBugs - http://fmdbugs.sourceforge.net/fmdbugs2.html
[2] . В.П. Иванников, А.А. Белеванцев, А.Е. Бородин, В.Н. Игнатьев, Д.М. Журихин,
А.И. Аветисян, М.И. Леонов. Статический анализатор Svace для поиска дефектов в исходном коде программ. Труды Инстшута системного программирования РАН Том 26. Выпуск 1. 2014 г. Стр. 231-250.
[3] . Cyrille Artho. Finding faults in multi-threaded programs. March 15, 2001.
(http://artho.com/jlint/mthesis.pdf)
[4] . Nick Rutar, Christian B. Almazan, Jeffrey S. Foster. A Comparison of Bug Finding
Tools for Java, (http://www.cs.umd.edu/~jfoster/papers/issre04.pdf)
[5] . ASM framework - http://asm.ow2.org/index.html
[6] . Sevak Sargsyan, Shamil Kurmangaleev, Vahagn Vardanyan, Vachagan Zakaryan. Code
Clones Detection Based on Semantic Analysis for JavaScript Language. October 1, 2015 (https://csit.am/2015/9a.html)
[7] . Zhenmin Li, Shan Lu, Suvda Myagmar and Yuanyuan Zhou. СР-Miner: A Tool for
Finding Copy-paste and Related Bugs in Operating System Code. (http://opera.ucsd.edu/paper/OSDI04-CPMiner.pdf)
[8] . Jurgen Graf, Martin Hecker, Martin Mohr, and Benedikt Nordhoff. Lock-sensitive
Interference Analysis for Java: Combining Program Dependence Graphs with Dynamic Pushdown Networks. 2013.
(https://pp.ipd.kit.edu/uploads/publikationen/pdgwithdpn2013id.pdf)
156
Труды ИСП РАН, том 27, вып. 6, 2015 г..
Using different views java-programs for static analysis
К A. Karpulevitch <[email protected]>
ISP RAS, 25 Alexander Solzhenitsyn Str., Moscow, 109004, Russian Federation
Absract. A program representation plays an important role in static analysis of software. The article discusses options for program representations built on various stages of compilation, and software bugs detectors working on these representations.
Keywords: static analysis, java, FindBugs, SVACE
References
[1] . FinBugs - http://fmdbugs.sourceforge.net/fmdbugs2.htnil
[2] . V.P. Ivannikov, A.A. Belevancev, A.E. Borodin, V.N. Ignat'ev, D.M. Zhurikhin, A.I.
Avetisjan, M.I. Leonov. Staticheskij analizator Svace dlja poiska defektov v iskhodnom kode programm [Svace: static analyzer for detecting of defects in program source code] Trudy ISP RAN [The Proceedings of ISP RAS], volume 26, issue 1, pp. 231-250. DOI: 10.15514/ISPRAS-2014-26( 1 )-7. (in Russian)
[3] . Cyrille Artho. Finding faults in multi-threaded programs. March 15, 2001.
(http://artho.com/jlint/mthesis.pdf)
[4] . Nick Rutar, Christian B. Almazan, Jeffrey S. Foster. A Comparison of Bug Finding
Tools for Java, (http://www.cs.umd.edu/~jfoster/papers/issre04.pdf)
[5] . ASM framework - http://asm.ow2.org/index.html
[6] . Sevak Sargsyan, Shamil Kurmangaleev, Vahagn Vardanyan, Vachagan Zakaryan. Code
Clones Detection Based on Semantic Analysis for JavaScript Language. October 1, 2015 (https://csit.am/2015/9a.html)
[7] . Zhenmin Li, Shan Lu, Suvda Myagmar and Yuanyuan Zhou. СР-Miner: A Tool for
Finding Copy-paste and Related Bugs in Operating System Code.
(http://opera.ucsd.edu/paper/OSDI04-CPMiner.pdf)
[8] . Jurgen Graf, Martin Hecker, Martin Mohr, and Benedikt Nordhoff. Lock-sensitive
Interference Analysis for Java: Combining Program Dependence Graphs with Dynamic Pushdown Networks. 2013.
(https://pp.ipd.kit.edu/uploads/publikationen/pdgwithdpn2013id.pdf)
157
