Re: запуск автотестов с включенным asan (address sanitizer)
Методика "взять референсные тесты ... запустить ... включить санитайзер и запустить" оказалась неплоха. Не думали популяризовать её для сторонних модулей? Раньше по крайней мере в рассылке частенько сегфолты на сторонних модулях были. Если гонять тесты, оно ловится ещё на этапе тестирования On Sat, Sep 5, 2020, 9:14 AM Maxim Dounin wrote: > Hello! > > On Fri, Sep 04, 2020 at 11:12:30PM +0500, Илья Шипицин wrote: > > > для тестирования самодельного модуля, использовали такую методику > > > > взяли https://github.com/nginx/nginx-tests > > собрали nginx с самодельным модулем и gcc asan (не суть, могли бы взять > > clang asan). > > собрали кучу вариантов прохода по коду (это круто), нашли сколько-то > > дефектов в своем модуле. > > > > интересные вещи возникают с asan, причем, воспроизводятся на оригинальном > > nginx. > > это непонятно. можете прокомментировать ? > > > > 1. беру nginx из официальной репы. смотрю "nginx -V", добавляю > > -fsanitize=address к cc-opts > > 2. выставляю ASAN_OPTIONS="log_path=asan.log" > > 3. запукаю тесты, смотрю, что упало в asan.log (а там есть сработки, это > > немного неожиданно) > > LeakSanitizer любит ругаться при выходе процесса на любую > выделенную и не освобождённую явно память. В результате ругани > там достаточно в том числе на полностью корректном коде, причём > она заметно варьируется в зависимости от используемых библиотек и > операционной системы. На macOS, например, вызов localtime_r() > приводит к аллокациям в системных библиотеках и ругани при выходе > всегда. > > Ну и с учётом используемой nginx'ом модели выделения памяти через > пулы - поймать что-то реальное с помощью LeakSanitizer'а > практически невозможно. > > Так что тесты с санитайзером мы гоняем, но вот на ругань от > LeakSanitizer'а смотреть систематически даже и не пытаемся: мусора > много, а толку никакого. > > [...] > > > Indirect leak of 16384 byte(s) in 1 object(s) allocated from: > > #0 0x7f36e86dbaa5 in posix_memalign > > (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) > > #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 > > #2 0x5627781225ac in ngx_create_pool src/core/ngx_palloc.c:23 > > #3 0x562778169b2d in ngx_init_cycle src/core/ngx_cycle.c:69 > > #4 0x5627781188ae in main src/core/nginx.c:291 > > #5 0x7f36e7fa40b2 in __libc_start_main > > (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) > > Ругань в этом файле (вся, но тут вот наиболее наглядно) как бы > предполагает, что созданный в ngx_init_cycle() пул не освобождён. > Такое может быть при фатальных ошибках, скажем, если произошла > ошибка при инициализации какого-то модуля в ngx_init_cycle(). > > На вскидку я никаких подобных проблем в тестах не помню (даже при > использовании TEST_NGINX_UNSAFE, хотя там вообще-то может быть > всё, что угодно), и погоняв тесты на Ubuntu 18.04 никакой подобной > ругани от ASAN'а не наблюдаю (другую - наблюдаю, но там всё > понятно: неосвобождения пула init-цикла при ошибках парсинга > конфигурации, per-worker аллокации в random-балансировщике и > разное в OpenSSL). Если воспроизводится - то стоит посмотреть, > что конкретно за тест это триггерит, и что там происходит. > > Впрочем, шансов на то, что это таки утечка - никаких. Скорее > какая-нибудь проблема с конкретным тестом на конкретной платформе. > > -- > Maxim Dounin > http://mdounin.ru/ > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: запуск автотестов с включенным asan (address sanitizer)
On Sat, Sep 5, 2020, 9:14 AM Maxim Dounin wrote: > Hello! > > On Fri, Sep 04, 2020 at 11:12:30PM +0500, Илья Шипицин wrote: > > > для тестирования самодельного модуля, использовали такую методику > > > > взяли https://github.com/nginx/nginx-tests > > собрали nginx с самодельным модулем и gcc asan (не суть, могли бы взять > > clang asan). > > собрали кучу вариантов прохода по коду (это круто), нашли сколько-то > > дефектов в своем модуле. > > > > интересные вещи возникают с asan, причем, воспроизводятся на оригинальном > > nginx. > > это непонятно. можете прокомментировать ? > > > > 1. беру nginx из официальной репы. смотрю "nginx -V", добавляю > > -fsanitize=address к cc-opts > > 2. выставляю ASAN_OPTIONS="log_path=asan.log" > > 3. запукаю тесты, смотрю, что упало в asan.log (а там есть сработки, это > > немного неожиданно) > > LeakSanitizer любит ругаться при выходе процесса на любую > выделенную и не освобождённую явно память. В результате ругани > там достаточно в том числе на полностью корректном коде, причём > она заметно варьируется в зависимости от используемых библиотек и > операционной системы. На macOS, например, вызов localtime_r() > приводит к аллокациям в системных библиотеках и ругани при выходе > всегда. > > Ну и с учётом используемой nginx'ом модели выделения памяти через > пулы - поймать что-то реальное с помощью LeakSanitizer'а > практически невозможно. > > Так что тесты с санитайзером мы гоняем, но вот на ругань от > LeakSanitizer'а смотреть систематически даже и не пытаемся: мусора > много, а толку никакого. > Вывод приведен, кстати, с bionic. Да, я тоже подумал, что скорее всего тесты с санитайзером запускаете. Ну и была надежда на бинарную логику "есть сработки - ура, смотрим, нет сработок - смотреть нечего" > [...] > > > Indirect leak of 16384 byte(s) in 1 object(s) allocated from: > > #0 0x7f36e86dbaa5 in posix_memalign > > (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) > > #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 > > #2 0x5627781225ac in ngx_create_pool src/core/ngx_palloc.c:23 > > #3 0x562778169b2d in ngx_init_cycle src/core/ngx_cycle.c:69 > > #4 0x5627781188ae in main src/core/nginx.c:291 > > #5 0x7f36e7fa40b2 in __libc_start_main > > (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) > > Ругань в этом файле (вся, но тут вот наиболее наглядно) как бы > предполагает, что созданный в ngx_init_cycle() пул не освобождён. > Такое может быть при фатальных ошибках, скажем, если произошла > ошибка при инициализации какого-то модуля в ngx_init_cycle(). > > На вскидку я никаких подобных проблем в тестах не помню (даже при > использовании TEST_NGINX_UNSAFE, хотя там вообще-то может быть > всё, что угодно), и погоняв тесты на Ubuntu 18.04 никакой подобной > ругани от ASAN'а не наблюдаю (другую - наблюдаю, но там всё > понятно: неосвобождения пула init-цикла при ошибках парсинга > конфигурации, per-worker аллокации в random-балансировщике и > разное в OpenSSL). Если воспроизводится - то стоит посмотреть, > что конкретно за тест это триггерит, и что там происходит. > > Впрочем, шансов на то, что это таки утечка - никаких. Скорее > какая-нибудь проблема с конкретным тестом на конкретной платформе. > > -- > Maxim Dounin > http://mdounin.ru/ > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru