Методика "взять референсные тесты ... запустить ... включить санитайзер и
запустить" оказалась неплоха. Не думали популяризовать её для сторонних
модулей? Раньше по крайней мере в рассылке частенько сегфолты на сторонних
модулях были. Если гонять тесты, оно ловится ещё на этапе тестирования

On Sat, Sep 5, 2020, 9:14 AM Maxim Dounin <mdounin@mdounin.ru> 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