|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75621 Opcache crashes Apache possible with bad chars
Submitted: 2017-12-04 10:55 UTC Modified: 2017-12-18 17:47 UTC
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: pascal dot nobus at webservice dot be Assigned: nikic (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 7.1.12 OS: Slackware 14.1
Private report: No CVE-ID: None
 [2017-12-04 10:55 UTC] pascal dot nobus at webservice dot be
On POSTs from IP's mostly located in Russia/Ukrain, we see apache is crashing:
[Mon Dec 04 10:30:40.665477 2017] [core:notice] [pid 9797:tid 140551095412608] AH00051: child pid 16751 exit signal Segmentation fault (11)

Back tracing the core-dumps is always one of these:

#0  0x0000000000000000 in ?? ()
#1  0x00007fd4936272d3 in execute_ex (ex=<optimized out>) at /usr/local/src/php-7.1.12/Zend/zend_vm_execute.h:429

#0  execute_ex (ex=<optimized out>) at /usr/local/src/php-7.1.12/Zend/zend_vm_execute.h:429
#1  0x00007fd49368367b in zend_execute (op_array=<optimized out>, return_value=<optimized out>) at /usr/local/src/php-7.1.12/Zend/zend_vm_execute.h:474

Apache-version httpd-2.4.29 (MPM-event)
php compiled as module.
There is only one php-extension on the server: opcache.
Uncommented opcache-settings in php.ini:

I changed output_buffering to 8192 (no effect)
I changed opcache.log_verbosity_level to 4, but no strange things in the logs.

I have also seen:
 [Sun Dec 03 15:21:44.025975 2017] [core:notice] [pid 29980:tid 140454601000832] AH00052: child pid 4005 exit signal Segmentation fault (11)

And even a couple of times this one (less then the segmenation faults):
 zend_mm_heap corrupted

Any ideas

Test script:
up-to-date pages of wordpress (index.php wp-login.php), on different sites.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-12-05 09:05 UTC] post at minhost dot no
Are you sure it is Apache that crashes and not only PHP pages? If it is only PHP pages that crashes, then it could be related to Bug #75579
 [2017-12-05 10:12 UTC] pascal dot nobus at webservice dot be
The apache-logs show it was an apache-child that got the Segmentation fault:
 [Sun Dec 03 15:21:44.025975 2017] [core:notice] [pid 29980:tid 140454601000832] AH00052: child pid 4005 exit signal Segmentation fault (11)

but that's quit normal because php is configured as a module (not fpm).

According to the symptons it looks to me that it is related to bug 75579.
However I can't see Interned Strings Used/Free memory, it's not in my phpinfo, nor in opcache_get_status

I also have the default value for interned_strings_buffer
 [2017-12-05 10:44 UTC] post at minhost dot no
Strange that you don't see statistic for opcache on a phpinfo page, like "Interned Strings Used memory" and "Interned Strings Free memory", maybe it is because you run PHP as a module. I run PHP as FPM, so I don't know.

What I see in PHP 7.1.12 is that Interned Strings memory run full in a very short time, then PHP pages start to go down. What I don't know if Interned Strings Free memory is supposed to run full in a short time or not? It never happened before, it was always plenty memory left in Interned Strings Free memory before upgrading to PHP 7.1.12. Question is if that was a bug before or not. Only thing I can say for sure, is that when there is no Interned Strings Free memory left in PHP 7.1.12, then PHP pages go down. That never happened in previous PHP versions.

I have set opcache.interned_strings_buffer to 4, and by the way that is the default value according to

I am worried about lack of response to from PHP developers to Bug #75579, my fear is that this will not be fixed anytime soon, so that I will be stuck on PHP 7.1.11
 [2017-12-13 12:53 UTC] pascal at nobus dot Be
I have been collecting coredump since a few days, and I see about 2 crashes a day.

The all have different files now?

I run nginx as a proxy before this apache, could this have something to do with it? (don't see any problems with nginx)

#0  i_zval_ptr_dtor (zval_ptr=0x7fd3f024aa40) at /usr/local/src/php-7.1.12/Zend/zend_variables.h:46
46              if (Z_REFCOUNTED_P(zval_ptr)) {

#0  zend_hash_clean (ht=0x7fd48a02ae78) at /usr/local/src/php-7.1.12/Zend/zend_hash.c:1366
1366                                            if (EXPECTED(Z_TYPE(p->val) != IS_UNDEF)) {

#0  zend_hash_clean (ht=0x7fd4880c7690) at /usr/local/src/php-7.1.12/Zend/zend_hash.c:1352
1352                                                    if (EXPECTED(Z_TYPE(p->val) != IS_UNDEF)) {

#0  zval_delref_p (pz=<optimized out>, pz=<optimized out>) at /usr/local/src/php-7.1.12/Zend/zend_types.h:838
838             return --GC_REFCOUNT(Z_COUNTED_P(pz));

#0  execute_ex (ex=<optimized out>) at /usr/local/src/php-7.1.12/Zend/zend_vm_execute.h:429
429                     ((opcode_handler_t)OPLINE->handler)(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU);

#0  execute_ex (ex=<optimized out>) at /usr/local/src/php-7.1.12/Zend/zend_vm_execute.h:429
429                     ((opcode_handler_t)OPLINE->handler)(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU);
 [2017-12-17 21:24 UTC]
-Status: Open +Status: Feedback
 [2017-12-17 21:24 UTC]
This is most likely bug #75573. Can you check whether 7.1.13RC1 resolves this issue?
 [2017-12-18 15:51 UTC] pascal dot nobus at webservice dot be
I'm running 7.1.13RC1 now for almost 20h without a single core-dump.
So it looks the problem is solved!

If it's up to me you may consider
 [2017-12-18 17:47 UTC]
-Status: Feedback +Status: Closed -Package: opcache +Package: Scripting Engine problem -Assigned To: +Assigned To: nikic
 [2017-12-18 17:47 UTC]
Thanks for checking!
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jun 19 02:01:29 2024 UTC