Re: NginX крошится с libperl-5.30

2019-07-02 Пенетрантность Maxim Dounin
Hello!

On Sat, Jun 29, 2019 at 08:00:59PM +0300, Vadim A. Misbakh-Soloviov wrote:

> Поправка: оно не падает в таком положении (даже на той машине) ТОЛЬКО если 
> цепляться по -p (без дебага, замечу, падает. Так что странно).
> 
> Попробовал запустить напрямую под gdb, получил такое:
> 
> ```
> #0  0x7492d0c7 in raise () from /lib64/libc.so.6
> #1  0x7492eaf9 in abort () from /lib64/libc.so.6
> #2  0x749242a9 in ?? () from /lib64/libc.so.6
> #3  0x74924331 in __assert_fail () from /lib64/libc.so.6
> #4  0x74e1d28f in S__invlist_len (invlist=0x55ea8078) at 
> invlist_inline.h:49

[...]

> #11 0x74e5d0d2 in S_reg (my_perl=0x55dd5c60, 
> pRExC_state=0x7fff8da0, paren=0, flagp=0x7fff8ad8, depth=1) at 
> regcomp.c:12088
> #12 0x74e3ebf7 in Perl_re_op_compile (my_perl=0x55dd5c60, 
> patternp=0x0, pat_count=1, expr=0x55dee908, eng=0x7532b9a0 
> , old_re=0x0, is_bare_re=0x0, orig_rx_flags=0, 
> pm_flags=1073741824) at regcomp.c:7705

Всё это по прежнему выгядит как падение собственно перла в 
процессе компиляции регулярного выражения.  Судя по:

> #16 0x7500f64e in S_require_file (my_perl=0x55dd5c60, 
> sv=0x55b9ce10) at pp_ctl.c:4322
> #17 0x7500f7aa in Perl_pp_require (my_perl=0x55dd5c60) at 
> pp_ctl.c:4346

и по:

> #26 0x7500f64e in S_require_file (my_perl=0x55dd5c60, 
> sv=0x55e35038) at pp_ctl.c:4322
> #27 0x7500f7aa in Perl_pp_require (my_perl=0x55dd5c60) at 
> pp_ctl.c:4346

в процессе загрузки какого-то модуля, видимо второго по 
вложенности.  С учётом того, что при создании perl-интерпретатора 
nginx автоматически загружает модуль nginx - видимо, падение 
вызывает что-то, что подтягивается из nginx.pm.  Там в свою 
очередь используются Exporter и XSLoader, но ничего нетривиального 
в них не видно.  Впрочем, это может быть и что-то из site-local 
загрузки.

Для начала, наверное, имеет смысл разобраться, что именно за 
регулярное выражение падает, и из какого именно файла.  Ну а 
дальше - смотреть соответствующие коммиты/тикеты в перле, 
воспроизводить и так далее.

Впрочем, если перл в nginx'е не используется - проще всего 
perl-модуль убрать из сборки и заб(ы|и)ть.  

[...]

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Vadim A. Misbakh-Soloviov
Gentoo.

Perl из собран из дистрибутивного пакета.
Nginx — я в своём репозитории мейтейню отдельный пакет (с поддержкой сборки с 
дополнительными модулями, и работаю над выносом их в динамические).


В соседней ветке я только что опубликовал вывод с дебагом.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Vadim A. Misbakh-Soloviov
Поправка: оно не падает в таком положении (даже на той машине) ТОЛЬКО если 
цепляться по -p (без дебага, замечу, падает. Так что странно).

Попробовал запустить напрямую под gdb, получил такое:

```
#0  0x7492d0c7 in raise () from /lib64/libc.so.6
#1  0x7492eaf9 in abort () from /lib64/libc.so.6
#2  0x749242a9 in ?? () from /lib64/libc.so.6
#3  0x74924331 in __assert_fail () from /lib64/libc.so.6
#4  0x74e1d28f in S__invlist_len (invlist=0x55ea8078) at 
invlist_inline.h:49
#5  0x74e48074 in Perl__invlist_intersection_maybe_complement_2nd 
(my_perl=0x55dd5c60, a=0x55ba4470, b=0x55ea8078, 
complement_b=true, i=0x7fff7c50) at regcomp.c:9752
#6  0x74e71842 in S_populate_ANYOF_from_invlist 
(my_perl=0x55dd5c60, node=0x558ee2c8, invlist_ptr=0x7fff7c50) at 
regcomp.c:14827
#7  0x74e8a3cb in S_regclass (my_perl=0x55dd5c60, 
pRExC_state=0x7fff8da0, flagp=0x7fff8454, depth=5, stop_at_1=false, 
allow_mutiple_chars=false, silence_non_portable=false, strict=false, 
optimizable=true, ret_invlist=0x0) at regcomp.c:19069
#8  0x74e672b7 in S_regatom (my_perl=0x55dd5c60, 
pRExC_state=0x7fff8da0, flagp=0x7fff8454, depth=4) at regcomp.c:13332
#9  0x74e604a0 in S_regpiece (my_perl=0x55dd5c60, 
pRExC_state=0x7fff8da0, flagp=0x7fff8570, depth=3) at regcomp.c:12457
#10 0x74e5fcd8 in S_regbranch (my_perl=0x55dd5c60, 
pRExC_state=0x7fff8da0, flagp=0x7fff8618, first=1, depth=2) at 
regcomp.c:12377
#11 0x74e5d0d2 in S_reg (my_perl=0x55dd5c60, 
pRExC_state=0x7fff8da0, paren=0, flagp=0x7fff8ad8, depth=1) at 
regcomp.c:12088
#12 0x74e3ebf7 in Perl_re_op_compile (my_perl=0x55dd5c60, 
patternp=0x0, pat_count=1, expr=0x55dee908, eng=0x7532b9a0 
, old_re=0x0, is_bare_re=0x0, orig_rx_flags=0, 
pm_flags=1073741824) at regcomp.c:7705
#13 0x74d43d43 in Perl_pmruntime (my_perl=0x55dd5c60, 
o=0x55dee948, expr=0x55dee908, repl=0x0, flags=1, floor=0) at op.c:
7130
#14 0x74e0e38f in Perl_yyparse (my_perl=0x55dd5c60, gramtype=258) 
at perly.y:1234
#15 0x750080ed in S_doeval_compile (my_perl=0x55dd5c60, gimme=2 
'\002', outside=0x0, seq=183, hh=0x0) at pp_ctl.c:3502
#16 0x7500f64e in S_require_file (my_perl=0x55dd5c60, 
sv=0x55b9ce10) at pp_ctl.c:4322
#17 0x7500f7aa in Perl_pp_require (my_perl=0x55dd5c60) at 
pp_ctl.c:4346
#18 0x74eb6c4a in Perl_runops_debug (my_perl=0x55dd5c60) at 
dump.c:2537
#19 0x74d7e142 in Perl_call_sv (my_perl=0x55dd5c60, 
sv=0x55b9cde0, flags=13) at perl.c:3043
#20 0x74d89318 in Perl_call_list (my_perl=0x55dd5c60, oldscope=6, 
paramList=0x55f9e480) at perl.c:5088
#21 0x74d586c0 in S_process_special_blocks (my_perl=0x55dd5c60, 
floor=171, fullname=0x55f70cd8 "BEGIN", gv=0x55f9e558, 
cv=0x55b9cde0) at op.c:10471
#22 0x74d57cac in Perl_newATTRSUB_x (my_perl=0x55dd5c60, 
floor=171, o=0x55ec8150, proto=0x0, attrs=0x0, block=0x55ec8110, 
o_is_gv=false) at op.c:10397
#23 0x74d458c2 in Perl_utilize (my_perl=0x55dd5c60, aver=1, 
floor=171, version=0x0, idop=0x55fac968, arg=0x558d5b08) at op.c:7592
#24 0x74e0a061 in Perl_yyparse (my_perl=0x55dd5c60, gramtype=258) 
at perly.y:335
#25 0x750080ed in S_doeval_compile (my_perl=0x55dd5c60, gimme=2 
'\002', outside=0x0, seq=4294967246, hh=0x0) at pp_ctl.c:3502
#26 0x7500f64e in S_require_file (my_perl=0x55dd5c60, 
sv=0x55e35038) at pp_ctl.c:4322
#27 0x7500f7aa in Perl_pp_require (my_perl=0x55dd5c60) at 
pp_ctl.c:4346
#28 0x74eb6c4a in Perl_runops_debug (my_perl=0x55dd5c60) at 
dump.c:2537
#29 0x74d7e142 in Perl_call_sv (my_perl=0x55dd5c60, 
sv=0x55f77f28, flags=13) at perl.c:3043
#30 0x74d89318 in Perl_call_list (my_perl=0x55dd5c60, oldscope=2, 
paramList=0x55f77fa0) at perl.c:5088
#31 0x74d586c0 in S_process_special_blocks (my_perl=0x55dd5c60, 
floor=45, fullname=0x55f70cd8 "BEGIN", gv=0x55f77fb8, 
cv=0x55f77f28) at op.c:10471
#32 0x74d57cac in Perl_newATTRSUB_x (my_perl=0x55dd5c60, floor=45, 
o=0x55f73970, proto=0x0, attrs=0x0, block=0x55f73930, o_is_gv=false) 
at op.c:10397
#33 0x74d458c2 in Perl_utilize (my_perl=0x55dd5c60, aver=1, 
floor=45, version=0x0, idop=0x55f9c978, arg=0x0) at op.c:7592
#34 0x74e0a061 in Perl_yyparse (my_perl=0x55dd5c60, gramtype=258) 
at perly.y:335
#35 0x74d7b4a3 in S_parse_body (my_perl=0x55dd5c60, env=0x0, 
xsinit=0x556a3ab6 ) at perl.c:2531
#36 0x74d791f8 in perl_parse (my_perl=0x55dd5c60, 
xsinit=0x556a3ab6 , argc=4, argv=0x55acf8c8, 
env=0x0) at perl.c:1822
#37 0x556a4988 in ngx_http_perl_create_interpreter (cf=0x7fffca70, 
pmcf=0x560b2c68) at 

Re: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Илья Шипицин
Какая у вас операционная система, perl из пакетов ставили? Пакет с
debuginfo можно доустановить?

On Sat, Jun 29, 2019, 4:39 PM Vadim A. Misbakh-Soloviov 
wrote:

> Уже в течение некоторого времени замечаю краши NgX при reload.
>
> Сегодня дошли руки глянуть в чём дело, и обнаружил что крошится оно в
> перловой
> либе.
>
> Попробовал подцепиться gdb'ом и получить трейс.
>
> Вот что вышло:
>
> 0x7f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd ()
> from
> /usr/lib64/libperl.so.5.30
> (gdb)  bt full
> #0  0x7f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd
> ()
> from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #1  0x7f59c0c46784 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #2  0x7f59c0c567b9 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #3  0x7f59c0c5c6a7 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #4  0x7f59c0c610f8 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #5  0x7f59c0c6156d in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #6  0x7f59c0c6647b in Perl_re_op_compile () from /usr/lib64/libperl.so.
> 5.30
> No symbol table info available.
> #7  0x7f59c0bfab3c in Perl_pmruntime () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #8  0x7f59c0c37851 in Perl_yyparse () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #9  0x7f59c0ce1912 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
>
>
>
> Если честно, не хочется пересобирать перл с дебагом (чтобы открыть символы
> от
> #1 до #5), так что, надеюсь, этого трейса хватит. Но, если нет - скажите.
> ___
> 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: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Vadim A. Misbakh-Soloviov
> Нет, регулярные выражения в конфиге nginx'а - nginx обрабатывает
> сам.  Надо смотреть именно на perl-код.  В том числе это может
> быть код в используемых perl-модулях.

Ну, в явном виде perl-модуль не используется нигде. Ни сайтов на нём нету, ни 
perl_*-директивы не используются...

> Для начала я бы попробовал получить простой способ воспроизведения
> проблемы - полный конфиг (включая perl-код) и последовательность действий,
> приводящие к падению.

Попробую выработать минимальный конфиг...

> 
> Возможно - при использовании чего-нибудь простого вроде junk:true
> в malloc.conf (MALLOC_PERTURB_ на линуксе со стандартным аллокатором,
> подробности см. в mallopt(3)) оно начнёт падать сразу, и возможно
> даже без nginx'а.

ну, при простых операциях сам по себе перл, вне NgX не падает с указанной 
директивой.

> А дальше - постараться вычленить, что именно вызывает проблему.
> Ну и неплохо бы проверить, не лечится ли всё банальным
> downgrade'ом на perl 5.28.x и/или upgrade'ом на 5.31.x.

Вообще, если честно, мне с дебагом пересобрать проще, чем обновить/
даунгрейднуть perl (потому что для последнего потребуется переустанавливать 
всё перлохозяйство, а это целая история с, в том числе, блокировками пакетов).

Ну и 5.31 в Gentoo пока не завезли.

А на 5.28 я (вроде (но это не точно)) не встречал этого.

Более того, на одной из машин я попробовал пересобрать с дебагом и оно 
перестало падать >_>

Сейчас вот собираю перл и NgX с дебагом на той, с которой трейс показывал...
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Maxim Dounin
Hello!

On Sat, Jun 29, 2019 at 03:24:35PM +0300, Vadim A. Misbakh-Soloviov wrote:

> > Судя по трейсу - Perl падает где-то в компиляции регулярных
> > выражений.  Это, конечно, может быть и какой-то проблемой в
> > nginx'е, но я бы поставил скорее на проблему в перле, которую
> > триггерят используемые в коде регулярные выражения.
> 
> Ну, в коде, вроде как, не используется никаких особо упоротых регулярок. В 
> основном - всякие `location ~* \.php$` и в таком ключе.

Нет, регулярные выражения в конфиге nginx'а - nginx обрабатывает 
сам.  Надо смотреть именно на perl-код.  В том числе это может 
быть код в используемых perl-модулях.

> Так что, по идее, не должно бы...
> 
> Ну и, я так понимаю, таки нужно пересобирать с дебагом и исходниками, чтобы 
> отсделить что где? :)

Для начала я бы попробовал получить простой способ воспроизведения 
проблемы - полный конфиг (включая perl-код) и последовательность действий, 
приводящие к падению.

Возможно - при использовании чего-нибудь простого вроде junk:true 
в malloc.conf (MALLOC_PERTURB_ на линуксе со стандартным аллокатором, 
подробности см. в mallopt(3)) оно начнёт падать сразу, и возможно 
даже без nginx'а.

А дальше - постараться вычленить, что именно вызывает проблему.  
Ну и неплохо бы проверить, не лечится ли всё банальным 
downgrade'ом на perl 5.28.x и/или upgrade'ом на 5.31.x.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Vadim A. Misbakh-Soloviov

> Судя по трейсу - Perl падает где-то в компиляции регулярных
> выражений.  Это, конечно, может быть и какой-то проблемой в
> nginx'е, но я бы поставил скорее на проблему в перле, которую
> триггерят используемые в коде регулярные выражения.

Ну, в коде, вроде как, не используется никаких особо упоротых регулярок. В 
основном - всякие `location ~* \.php$` и в таком ключе.

Так что, по идее, не должно бы...

Ну и, я так понимаю, таки нужно пересобирать с дебагом и исходниками, чтобы 
отсделить что где? :)
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Maxim Dounin
Hello!

On Sat, Jun 29, 2019 at 02:39:20PM +0300, Vadim A. Misbakh-Soloviov wrote:

> Уже в течение некоторого времени замечаю краши NgX при reload.
> 
> Сегодня дошли руки глянуть в чём дело, и обнаружил что крошится оно в 
> перловой 
> либе.
> 
> Попробовал подцепиться gdb'ом и получить трейс.
> 
> Вот что вышло:
> 
> 0x7f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () from 
> /usr/lib64/libperl.so.5.30
> (gdb)  bt full
> #0  0x7f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () 
> from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #1  0x7f59c0c46784 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #2  0x7f59c0c567b9 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #3  0x7f59c0c5c6a7 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #4  0x7f59c0c610f8 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #5  0x7f59c0c6156d in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #6  0x7f59c0c6647b in Perl_re_op_compile () from /usr/lib64/libperl.so.
> 5.30
> No symbol table info available.
> #7  0x7f59c0bfab3c in Perl_pmruntime () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #8  0x7f59c0c37851 in Perl_yyparse () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #9  0x7f59c0ce1912 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> 
> 
> 
> Если честно, не хочется пересобирать перл с дебагом (чтобы открыть символы от 
> #1 до #5), так что, надеюсь, этого трейса хватит. Но, если нет - скажите.

Судя по трейсу - Perl падает где-то в компиляции регулярных 
выражений.  Это, конечно, может быть и какой-то проблемой в 
nginx'е, но я бы поставил скорее на проблему в перле, которую 
триггерят используемые в коде регулярные выражения.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru