LINUX.ORG.RU

coredump httpd

 , ,


0

1

начал падать дочерний процесс, в логах

[pid 17507] AH00051: child pid 12110 exit signal Segmentation fault (11), possible coredump in /tmp/coredump

смотрю файла coredump

gdb httpd core.12110
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/httpd...Reading symbols from /usr/lib/debug/usr/sbin/httpd.debug...done.
done.
[New LWP 12110]

warning: .dynamic section for "/lib64/libkrb5.so.3" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/lib64/libk5crypto.so.3" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/lib64/libkrb5support.so.0" is not at the expected address (wrong library or version mismatch?)

warning: Could not load shared library symbols for %0*Zx, 0x%0*Zx).
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/httpd -DFOREGROUND'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f2526da6073 in sljit_remove_free_block (free_block=0x7f2517a44a10, free_block=0x7f2517a44a10) at sljit/sljitExecAllocator.c:165
165                     free_block->next->prev = free_block->prev;
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.3.x86_64 krb5-libs-1.15.1-37.el7_6.x86_64 sssd-client-1.16.2-13.el7_6.5.x86_64 systemd-libs-219-62.el7_6.3.x86_64
(gdb) bt
#0  0x00007f2526da6073 in sljit_remove_free_block (free_block=0x7f2517a44a10, free_block=0x7f2517a44a10) at sljit/sljitExecAllocator.c:165
#1  sljit_free_exec (ptr=0x7f2517a44010) at sljit/sljitExecAllocator.c:273
#2  0x00007f2526dc3a5a in sljit_free_code (code=<optimized out>) at sljit/sljitLir.c:397
#3  _pcre_jit_free (executable_funcs=0x558b56187240) at pcre_jit_compile.c:8542
#4  0x00007f2526dc55dc in pcre_free_study (extra=0x558b56187580) at pcre_study.c:1581
#5  0x00007f25199c1333 in php_free_pcre_cache (data=<optimized out>) at /usr/src/debug/php-7.1.26/ext/pcre/php_pcre.c:125
#6  0x00007f2519b16bf6 in zend_hash_destroy (ht=0x7f2519f10d60 <pcre_globals>) at /usr/src/debug/php-7.1.26/Zend/zend_hash.c:1246
#7  0x00007f25199c12b9 in zm_globals_dtor_pcre (pcre_globals=<optimized out>) at /usr/src/debug/php-7.1.26/ext/pcre/php_pcre.c:145
#8  0x00007f2519b0bdbd in module_destructor (module=module@entry=0x558b55e4d090) at /usr/src/debug/php-7.1.26/Zend/zend_API.c:2512
#9  0x00007f2519b0450c in module_destructor_zval (zv=<optimized out>) at /usr/src/debug/php-7.1.26/Zend/zend.c:633
#10 0x00007f2519b176f1 in _zend_hash_del_el_ex (prev=<optimized out>, p=<optimized out>, idx=<optimized out>, ht=<optimized out>) at /usr/src/debug/php-7.1.26/Zend/zend_hash.c:997
#11 _zend_hash_del_el (p=0x558b55e32180, idx=4, ht=0x7f2519f15380 <module_registry>) at /usr/src/debug/php-7.1.26/Zend/zend_hash.c:1020
#12 zend_hash_graceful_reverse_destroy (ht=ht@entry=0x7f2519f15380 <module_registry>) at /usr/src/debug/php-7.1.26/Zend/zend_hash.c:1476
#13 0x00007f2519b0a1dc in zend_destroy_modules () at /usr/src/debug/php-7.1.26/Zend/zend_API.c:1978
#14 0x00007f2519b050f1 in zend_shutdown () at /usr/src/debug/php-7.1.26/Zend/zend.c:876
#15 0x00007f2519aa0bfb in php_module_shutdown () at /usr/src/debug/php-7.1.26/main/main.c:2445
#16 0x00007f2519aa0cb9 in php_module_shutdown_wrapper (sapi_globals=<optimized out>) at /usr/src/debug/php-7.1.26/main/main.c:2413
#17 0x00007f2519bac091 in php_apache_child_shutdown (tmp=<optimized out>) at /usr/src/debug/php-7.1.26/sapi/apache2handler/sapi_apache2.c:435
#18 0x00007f2525ef91ae in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2352
#19 apr_pool_destroy (pool=0x558b56047738) at memory/unix/apr_pools.c:814
#20 0x00007f251d4641dc in clean_child_exit (code=code@entry=0) at prefork.c:221
#21 0x00007f251d464687 in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:728
#22 0x00007f251d4649f5 in make_child (s=0x558b55d56350, slot=0) at prefork.c:810
#23 0x00007f251d46568e in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:912
#24 prefork_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized out>) at prefork.c:1100
#25 0x0000558b54105ffe in ap_run_mpm (pconf=pconf@entry=0x558b55d2d138, plog=0x558b55d5a358, s=0x558b55d56350) at mpm_common.c:96
#26 0x0000558b540fed76 in main (argc=2, argv=0x7fff171a34d8) at main.c:783

но из этого вывода не понятно кто виновник падения процесса, что надо установить/поправить/добавить, что бы понять кто виновник падений


Обновления ставились? Похоже на результат неполного обновления — одни пакеты новые, другие ещё старые.

Moondancer
()
Ответ на: комментарий от Moondancer

да были обновления, уже запланировали ребут, но на тестовом сервере ставились такие же обновления, но там не падает апач с Segmentation fault (11)

Garcia
() автор топика
Последнее исправление: Garcia (всего исправлений: 1)
Ответ на: комментарий от Garcia

Тестовый от прода отличается? Хорошо иметь ещё staging-сервер, на котором всё точь-в-точь как на проде, на случай непредвиденных проблем после деплоя, которые не воспроизводятся на тестовом.

Moondancer
()
Ответ на: комментарий от Moondancer

вот как раз stage и обновлялся с продакшеном, на продакшене апач падает, а на stage все ок

Garcia
() автор топика
Ответ на: комментарий от Moondancer

после ребута, ничего не поменялось, точно так же подает апач

[core:notice] [pid 26162] AH00051: child pid 30982 exit signal Segmentation fault (11), possible coredump in /tmp/coredump

gdb httpd /tmp/coredump/core.30982
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/httpd...Reading symbols from /usr/lib/debug/usr/sbin/httpd.debug...done.
done.
[New LWP 30982]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/httpd -DFOREGROUND'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f7263cee073 in sljit_remove_free_block (free_block=0x7f726403f360, free_block=0x7f726403f360) at sljit/sljitExecAllocator.c:165
165                     free_block->next->prev = free_block->prev;
(gdb) bt
#0  0x00007f7263cee073 in sljit_remove_free_block (free_block=0x7f726403f360, free_block=0x7f726403f360) at sljit/sljitExecAllocator.c:165
#1  sljit_free_exec (ptr=0x7f726403f0a8) at sljit/sljitExecAllocator.c:273
#2  0x00007f7263d0ba5a in sljit_free_code (code=<optimized out>) at sljit/sljitLir.c:397
#3  _pcre_jit_free (executable_funcs=0x556f76997110) at pcre_jit_compile.c:8542
#4  0x00007f7263d0d5dc in pcre_free_study (extra=0x556f7665d4a0) at pcre_study.c:1581
#5  0x00007f7256909333 in php_free_pcre_cache (data=<optimized out>) at /usr/src/debug/php-7.1.26/ext/pcre/php_pcre.c:125
#6  0x00007f7256a5eb94 in zend_hash_destroy (ht=0x7f7256e58d60 <pcre_globals>) at /usr/src/debug/php-7.1.26/Zend/zend_hash.c:1254
#7  0x00007f72569092b9 in zm_globals_dtor_pcre (pcre_globals=<optimized out>) at /usr/src/debug/php-7.1.26/ext/pcre/php_pcre.c:145
#8  0x00007f7256a53dbd in module_destructor (module=module@entry=0x556f76633550) at /usr/src/debug/php-7.1.26/Zend/zend_API.c:2512
#9  0x00007f7256a4c50c in module_destructor_zval (zv=<optimized out>) at /usr/src/debug/php-7.1.26/Zend/zend.c:633
#10 0x00007f7256a5f6f1 in _zend_hash_del_el_ex (prev=<optimized out>, p=<optimized out>, idx=<optimized out>, ht=<optimized out>) at /usr/src/debug/php-7.1.26/Zend/zend_hash.c:997
#11 _zend_hash_del_el (p=0x556f765b0310, idx=4, ht=0x7f7256e5d380 <module_registry>) at /usr/src/debug/php-7.1.26/Zend/zend_hash.c:1020
#12 zend_hash_graceful_reverse_destroy (ht=ht@entry=0x7f7256e5d380 <module_registry>) at /usr/src/debug/php-7.1.26/Zend/zend_hash.c:1476
#13 0x00007f7256a521dc in zend_destroy_modules () at /usr/src/debug/php-7.1.26/Zend/zend_API.c:1978
#14 0x00007f7256a4d0f1 in zend_shutdown () at /usr/src/debug/php-7.1.26/Zend/zend.c:876
#15 0x00007f72569e8bfb in php_module_shutdown () at /usr/src/debug/php-7.1.26/main/main.c:2445
#16 0x00007f72569e8cb9 in php_module_shutdown_wrapper (sapi_globals=<optimized out>) at /usr/src/debug/php-7.1.26/main/main.c:2413
#17 0x00007f7256af4091 in php_apache_child_shutdown (tmp=<optimized out>) at /usr/src/debug/php-7.1.26/sapi/apache2handler/sapi_apache2.c:435
#18 0x00007f7262e411ae in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2352
#19 apr_pool_destroy (pool=0x556f76840218) at memory/unix/apr_pools.c:814
#20 0x00007f725a3ac1dc in clean_child_exit (code=code@entry=0) at prefork.c:221
#21 0x00007f725a3ac687 in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:728
#22 0x00007f725a3ac9f5 in make_child (s=0x556f764db4d0, slot=0) at prefork.c:810
#23 0x00007f725a3ad68e in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:912
#24 prefork_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized out>) at prefork.c:1100
#25 0x0000556f74975ffe in ap_run_mpm (pconf=pconf@entry=0x556f764aa138, plog=0x556f764d7358, s=0x556f764db4d0) at mpm_common.c:96
#26 0x0000556f7496ed76 in main (argc=2, argv=0x7ffd0fb2e978) at main.c:783

по этим логам ничего непонятно, что надо еще сделать, что бы найти виновника падения апача?

Garcia
() автор топика
Ответ на: комментарий от Garcia

Падения в аллокаторах обычно означает повреждение памяти. Что-то пишет не туда, портит указатели, которые потом разыменовываются. В таком случае бектрейс мало что говорит, ведь ошибка была за некоторое время до падения, где-то в другом месте.

Попробуй запускать под Valgrind'ом. Или пересобери всё с включенным AddressSanitizer'ом.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

запустил на пару минут

valgrind -v --log-file=valgrind.log --trace-children=yes --leak-check=full httpd -k start

вот лог

можно что-то сказать из этого лога кто виновник или какие-то другие тесты надо еще запускать?

Garcia
() автор топика
Ответ на: комментарий от Garcia

В этом логе не видно никаких ошибок. Скорее всего, за время работы ошибок не происходило. Нужно попробовать поймать ошибку, пока httpd всё ещё работает под Valgrind'ом.

У тебя процесс падает с SIGSEGV, когда всплывает баг. Скорее всего, под Valgrind он тоже упадёт с SIGSEGV, но перед этим в лог попадут детали. То есть, в логе нужно искать «SIGSEGV», «signal 11», «Invalid read», «Invalid write».

На случай, если до этого с Valgrind'ом не приходилось взаимодействовать: работа в 20 раз медленнее — это нормально для Valgrind.

i-rinat ★★★★★
()
Ответ на: комментарий от DELIRIUM

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Твоя правда. Голосую за валгринд. Ну и gdb + метод_пристального_взгляда.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от i-rinat

оставил на ночь

valgrind --leak-check=full --show-reachable=yes --tool=memcheck --log-file=val.log /usr/sbin/httpd -DFOREGROUND
и поймал падения апача, вот первое из них
==16179== Invalid read of size 8
==16179==    at 0x12429A4B: UnknownInlinedFun (sljitExecAllocator.c:189)
==16179==    by 0x12429A4B: sljit_generate_code (sljitNativeX86_common.c:466)
==16179==    by 0x1244E4E1: _pcre_jit_compile (pcre_jit_compile.c:10342)
==16179==    by 0x12428631: php_pcre_study (pcre_study.c:1628)
==16179==    by 0x12451074: pcre_get_compiled_regex_cache (php_pcre.c:542)
==16179==    by 0x12453971: php_pcre_replace (php_pcre.c:1160)
==16179==    by 0x12453A59: php_replace_in_subject (php_pcre.c:1523)
==16179==    by 0x12453E51: preg_replace_impl (php_pcre.c:1582)
==16179==    by 0x12454AC8: zif_preg_replace (php_pcre.c:1621)
==16179==    by 0x1B1A4B64: xdebug_execute_internal (xdebug.c:2021)
==16179==    by 0x12637BDB: ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1099)
==16179==    by 0x125DE98A: execute_ex (zend_vm_execute.h:429)
==16179==    by 0x1B1A3E98: xdebug_execute_ex (xdebug.c:1912)
==16179==  Address 0x40c8488 is not stack'd, malloc'd or (recently) free'd
==16179==
==16179==
==16179== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==16179==    at 0x12429A4B: UnknownInlinedFun (sljitExecAllocator.c:189)
==16179==    by 0x12429A4B: sljit_generate_code (sljitNativeX86_common.c:466)
==16179==    by 0x1244E4E1: _pcre_jit_compile (pcre_jit_compile.c:10342)
==16179==    by 0x12428631: php_pcre_study (pcre_study.c:1628)
==16179==    by 0x12451074: pcre_get_compiled_regex_cache (php_pcre.c:542)
==16179==    by 0x12453971: php_pcre_replace (php_pcre.c:1160)
==16179==    by 0x12453A59: php_replace_in_subject (php_pcre.c:1523)
==16179==    by 0x12453E51: preg_replace_impl (php_pcre.c:1582)
==16179==    by 0x12454AC8: zif_preg_replace (php_pcre.c:1621)
==16179==    by 0x1B1A4B64: xdebug_execute_internal (xdebug.c:2021)
==16179==    by 0x12637BDB: ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1099)
==16179==    by 0x125DE98A: execute_ex (zend_vm_execute.h:429)
==16179==    by 0x1B1A3E98: xdebug_execute_ex (xdebug.c:1912)
==16179==
==16179== HEAP SUMMARY:
==16179==     in use at exit: 4,300,404 bytes in 29,295 blocks
==16179==   total heap usage: 801,597 allocs, 772,302 frees, 141,574,697 bytes allocated
==16179==
что тут не так?

п.с. могу выложить весь лог, но он набежал под 600 мб

Garcia
() автор топика
Ответ на: комментарий от Garcia

Не похоже на use-after-free, который я ожидал, а похоже на какой-то внутренний глюк в JIT-компиляторе у PCRE (это движок регулярок). Тут комментарием выше советуют отключить PCRE JIT в конфиге PHP (pcre.jit=0). Как обход должно сработать.

Если JIT очень нужен, стоит посмотреть в сторону обновления libpcre до более новых версий. Если с ними тоже падает, стоит завести баг на libpcre.

(Весь лог не нужен, первых ошибок уже достаточно.)

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

спасибо всем за помощь, выключил pcre.jit=0 и падений пока нет

п.с. а для чего pcre.jit вообще используется, есть какое-то практическое применение?

Garcia
() автор топика
Ответ на: комментарий от Garcia

а для чего pcre.jit вообще используется

Если включен, поиск по регулярным выражениям происходит быстрее, иногда в 10 раз. Подробнее описано тут: https://zherczeg.github.io/sljit/pcre.html

i-rinat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.