Hello Bernhard,
Yes, I'm running testing, but I updated the php packages before reporting the
bug to avoid posting an issue that might be already solved. The following
packages are installed from unstable:
libapache2-mod-php7.3-dbgsym/unstable-debug,now 7.3.0~rc5-2 amd64
libapache2-mod-php7.3/unstable,now 7.3.0~rc5-2 amd64
php-common/unstable,now 2:68 all
php7.3-bz2/unstable,now 7.3.0~rc5-2 amd64
php7.3-cli/unstable,now 7.3.0~rc5-2 amd64
php7.3-common/unstable,now 7.3.0~rc5-2 amd64
php7.3-curl/unstable,now 7.3.0~rc5-2 amd64
php7.3-gd/unstable,now 7.3.0~rc5-2 amd64
php7.3-gmp/unstable,now 7.3.0~rc5-2 amd64
php7.3-imap/unstable,now 7.3.0~rc5-2 amd64
php7.3-intl-dbgsym/unstable-debug,now 7.3.0~rc5-2 amd64
php7.3-json/unstable,now 7.3.0~rc5-2 amd64
php7.3-ldap/unstable,now 7.3.0~rc5-2 amd64
php7.3-mbstring/unstable,now 7.3.0~rc5-2 amd64
php7.3-mysql/unstable,now 7.3.0~rc5-2 amd64
php7.3-opcache/unstable,now 7.3.0~rc5-2 amd64
php7.3-phpdbg/unstable,now 7.3.0~rc5-2 amd64
php7.3-readline/unstable,now 7.3.0~rc5-2 amd64
php7.3-xml/unstable,now 7.3.0~rc5-2 amd64
php7.3-zip/unstable,now 7.3.0~rc5-2 amd64
The reload happening every night was configured by default, but I couldn't
figure out yet which mechanism is used to trigger it.
I can reproduce the crash at any time. When apache is running and I execute
"systemctl reload apache2.service" the segfaults occur immediately. In
contrast, after "systemctl restart apache2.service"
the server still works fine.
I now removed my self-built php7.3-intl package and installed the version from
unstable and the debug symbols again. Surprisingly, gdb was able to resolve the
function name and line now:
(gdb) c
Continuing.
[New process 3583]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Thread 2.1 "apache2" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1c91cb3440 (LWP 3583)]
0x00007f1c9089331a in zend_parse_va_args (num_args=0, type_spec=0x7f1c8a4158df
"l",
va=0x7fffc56e8640, flags=0) at ./Zend/zend_API.c:941
941 ./Zend/zend_API.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 0x00007f1c9089331a in zend_parse_va_args (num_args=0,
type_spec=0x7f1c8a4158df "l",
va=0x7fffc56e8640, flags=0) at ./Zend/zend_API.c:941
#1 0x00007f1c90a49cc6 in zend_parse_parameters (num_args=<optimized out>,
type_spec=type_spec@entry=0x7f1c8a4158df "l") at ./Zend/zend_API.c:1026
#2 0x00007f1c8a4116bc in _breakiter_int32_ret_int32 (
func_name=0x7f1c91cb3720 " 7ˑ\034\177", func=<optimized out>,
execute_data=0x7f1c91f22330 <__stack_user>, return_value=<optimized out>,
return_value=<optimized out>)
at ./ext/intl/breakiterator/breakiterator_methods.cpp:215
#3 0x00007f1c91e0a70e in __libc_fork () at ../sysdeps/nptl/fork.c:204
#4 0x00007f1c91c095c5 in make_child (s=0x7f1c91c9d4a0, slot=0, bucket=0) at
prefork.c:665
#5 0x00007f1c91c0a3f5 in perform_idle_server_maintenance (p=<optimized out>)
at prefork.c:824
#6 prefork_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized
out>)
at prefork.c:1019
#7 0x0000557197e4660e in ap_run_mpm (pconf=0x7f1c92011028,
plog=0x7f1c91c96028,
s=0x7f1c91c9d4a0) at mpm_common.c:94
#8 0x0000557197e3ef47 in main (argc=<optimized out>, argv=<optimized out>) at
main.c:819
The surrounding disassemble is attached. Here is the output of the other
commands:
(gdb) print *__fork_handlers
$1 = {next = 0x7f1c91eff9c8 <fork_handler_pool+104>, prepare_handler = 0x0,
parent_handler = 0x0, child_handler = 0x7f1c8a43b660, dso_handle =
0x7f1c91f1e2a0,
refcntr = 2, need_signal = 0}
(gdb) print *__fork_handlers->next
$2 = {next = 0x7f1c91eff998 <fork_handler_pool+56>, prepare_handler = 0x0,
parent_handler = 0x0, child_handler = 0x7f1c8f67b0a0, dso_handle =
0x7f1c8f780000,
refcntr = 2, need_signal = 0}
pstree -p | grep apache
|-apache2(3000)-+-apache2(3583)
| `-apache2(9938)
Kind regards,
Dino
(gdb) disassemble $pc-0x40,$pc+40
Dump of assembler code from 0x7f1c908932da to 0x7f1c90893342:
0x00007f1c908932da <zend_activate_modules+14>: sub %al,(%rax)
0x00007f1c908932dc <zend_activate_modules+16>: xor %eax,%eax
0x00007f1c908932de <zend_activate_modules+18>: callq 0x7f1c9087a200
<zend_error@plt>
0x00007f1c908932e3 <zend_activate_modules+23>: mov $0x1,%edi
0x00007f1c908932e8 <zend_activate_modules+28>: callq 0x7f1c90878780
<exit@plt>
0x00007f1c908932ed <zend_is_callable_ex+0>: mov %r8,%rcx
0x00007f1c908932f0 <zend_is_callable_ex+3>: lea 0x28b5f1(%rip),%rsi
# 0x7f1c90b1e8e8
0x00007f1c908932f7 <zend_is_callable_ex+10>: xor %edi,%edi
0x00007f1c908932f9 <zend_is_callable_ex+12>: xor %eax,%eax
0x00007f1c908932fb <zend_is_callable_ex+14>: callq 0x7f1c9087ad80
<zend_throw_error@plt>
0x00007f1c90893300 <zend_is_callable_ex+19>: xor %r9d,%r9d
0x00007f1c90893303 <zend_is_callable_ex+22>: mov -0x78(%rbp),%r11
0x00007f1c90893307 <zend_is_callable_ex+26>: jmpq 0x7f1c90a47b3e
<zend_is_callable_ex+1422>
0x00007f1c9089330c <zend_parse_va_args+0>: mov 0x380735(%rip),%rax
# 0x7f1c90c13a48
0x00007f1c90893313 <zend_parse_va_args+7>: mov 0x1e8(%rax),%rax
=> 0x00007f1c9089331a <zend_parse_va_args+14>: mov 0x18(%rax),%rsi
0x00007f1c9089331e <zend_parse_va_args+18>: mov 0x10(%rsi),%rdx
0x00007f1c90893322 <zend_parse_va_args+22>: test %rdx,%rdx
0x00007f1c90893325 <zend_parse_va_args+25>: je 0x7f1c908933e1
<zend_parse_va_args+213>
0x00007f1c9089332b <zend_parse_va_args+31>: mov 0x8(%rdx),%rcx
0x00007f1c9089332f <zend_parse_va_args+35>: lea 0x18(%rcx),%rdx
0x00007f1c90893333 <zend_parse_va_args+39>: movzbl 0x18(%rcx),%ecx
0x00007f1c90893337 <zend_parse_va_args+43>: mov 0x30(%rax),%rax
0x00007f1c9089333b <zend_parse_va_args+47>: test %rax,%rax
0x00007f1c9089333e <zend_parse_va_args+50>: je 0x7f1c90893355
<zend_parse_va_args+73>
0x00007f1c90893340 <zend_parse_va_args+52>: mov 0x18(%rax),%rax
End of assembler dump.
