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
Re: запуск автотестов с включенным asan (address sanitizer)
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
запуск автотестов с включенным asan (address sanitizer)
Добрый день! для тестирования самодельного модуля, использовали такую методику взяли 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 (а там есть сработки, это немного неожиданно) скрипт #!/bin/bash set -e sysctl kernel.core_pattern=/tmp/core-%e-%s-%u-%g-%p-%t ulimit -c unlimited export version=1.19.2 mkdir t cd t wget http://nginx.org/download/nginx-${version}.tar.gz tar xf nginx-${version}.tar.gz cd nginx-${version} ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O0 -fdebug-prefix-map=/data/builder/debuild/nginx-1.19.2/debian/debuild-base/nginx-1.19.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC -fsanitize=address' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie -fsanitize=address -lasan' --with-debug make export ASAN_OPTIONS="log_path=asan.log" export TEST_NGINX_BINARY=`pwd`/objs/nginx export TEST_NGINX_GLOBALS='user root; ' export TEST_NGINX_GLOBALS_HTTP='error_log /tmp/e.log;' git clone https://github.com/nginx/nginx-tests prove -r nginx-tests сработки # locate asan.log /root/t/nginx-1.19.2/nginx-tests/asan.log.46464 /root/t/nginx-1.19.2/nginx-tests/asan.log.46728 /root/t/nginx-1.19.2/nginx-tests/asan.log.46866 /root/t/nginx-1.19.2/nginx-tests/asan.log.46876 /root/t/nginx-1.19.2/nginx-tests/asan.log.47784 /root/t/nginx-1.19.2/nginx-tests/asan.log.47931 /root/t/nginx-1.19.2/nginx-tests/asan.log.47957 /root/t/nginx-1.19.2/nginx-tests/asan.log.47983 /root/t/nginx-1.19.2/nginx-tests/asan.log.48005 /root/t/nginx-1.19.2/nginx-tests/asan.log.48760 /root/t/nginx-1.19.2/nginx-tests/asan.log.48770 /root/t/nginx-1.19.2/nginx-tests/asan.log.48818 /root/t/nginx-1.19.2/nginx-tests/asan.log.49079 /root/t/nginx-1.19.2/nginx-tests/asan.log.49329 пример первой # cat /root/t/nginx-1.19.2/nginx-tests/asan.log.46464 = ==46464==ERROR: LeakSanitizer: detected memory leaks 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 0x5627781231ef in ngx_palloc_block src/core/ngx_palloc.c:186 #3 0x562778123166 in ngx_palloc_small src/core/ngx_palloc.c:173 #4 0x562778122f91 in ngx_palloc src/core/ngx_palloc.c:127 #5 0x5627782744f4 in ngx_http_add_variable src/http/ngx_http_variables.c:449 #6 0x56277828046b in ngx_http_variables_add_core_vars src/http/ngx_http_variables.c:2622 #7 0x56277822fd37 in ngx_http_core_preconfiguration src/http/ngx_http_core_module.c:3262 #8 0x562778213c81 in ngx_http_block src/http/ngx_http.c:227 #9 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #10 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #11 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #12 0x5627781188ae in main src/core/nginx.c:291 #13 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) 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 0x5627781231ef in ngx_palloc_block src/core/ngx_palloc.c:186 #3 0x562778123166 in ngx_palloc_small src/core/ngx_palloc.c:173 #4 0