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.