Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

I can confirm this issue - we are also experiencing massive amounts of segmentation faults of PHP processes after upgrading from 7.0.25 to 7.0.26 and from 7.1.11 to 7.1.12 across our servers.

Providing a simple testcase will be difficult, since this issue mainly seems to occur in lager CMS installations - I will try to narrow this down.

Rolling back to the previous PHP versions in the meantime.

So I spend some time tracing the crash and trying to copy the minimal object model. The script I've come up with has different btacktrace and only crashes about 1 out of 5 runs, but it's related as PHP with both commits reverted doesn't crash anymore.

Script:
-------
<?php

class A
{
  var $_stdObject;
  function initialize($properties = FALSE) {
    $this->_stdObject = $properties ? (object) $properties : new stdClass();
    parent::initialize();
  }
  function &__get($property)
  {
    if (isset($this->_stdObject->{$property})) {
      $retval =& $this->_stdObject->{$property};
      return $retval;
    } else {
      return NULL;
    }
  }
  function &__set($property, $value)
  {
    return $this->_stdObject->{$property} = $value;
  }
  function __isset($property_name)
  {
    return isset($this->_stdObject->{$property_name});
  }
}

class B extends A
{
  function initialize($properties = array())
  {
      parent::initialize($properties);
  }
  function &__get($property)
  {
    if (isset($this->settings) && isset($this->settings[$property])) {
      $retval =& $this->settings[$property];
      return $retval;
    } else {
      return parent::__get($property);
    }
  }
}

$b = new B();
$b->settings = [ "foo" => "bar", "name" => "abc" ];
var_dump($b->name);
var_dump($b->settings);

I applied this patch http://git.php.net/?p=php-src.git;a=commit;h=3b9ba7b6bd9e24bdbeca8e8e3f24cee2fccc51d8 to PHP 7.1.12 and it seems to have fixed the crashes I reported in Bug #75579

Can I also use this same patch for PHP 7.0.26, or must I wait for a modified patch for that PHP version?

@Xinchen: I'm unable to find the backport for the PHP 7.0 branch.

I agree that this patch solves the problem on PHP 7.1.12 in my testing.

It does seem that a different patch is needed for 7.0.26, though, as the logic appears to be slightly different.

This bug should be re-opened and the fix also applied to the 7.0 branch...

Patch for 7.0.26 looks like this:

--- Zend/zend_object_handlers.c.org     2017-11-21 12:57:10.000000000 +0100
+++ Zend/zend_object_handlers.c 2017-11-30 14:42:29.154940011 +0100
@@ -602,8 +602,8 @@
                        zval_ptr_dtor(&tmp_object);
                        goto exit;
                } else {
-                       zval_ptr_dtor(&tmp_object);
                        if (Z_STRVAL_P(member)[0] == '\0') {
+                               zval_ptr_dtor(&tmp_object);
                                if (Z_STRLEN_P(member) == 0) {
                                        zend_throw_error(NULL, "Cannot access empty property");
                                        retval = &EG(uninitialized_zval);

Thanks in advance

As I commented before, I applied the patch http://git.php.net/?p=php-src.git;a=commit;h=3b9ba7b6bd9e24bdbeca8e8e3f24cee2fccc51d8 and it seemed to fix the bug. However after testing more today, the bug is still present. I don't know if it is the same bug or not, I have filled a bug report here previous https://bugs.php.net/bug.php?id=75579 - anyway the patch did not work after all.

What happens is that after visiting about nine wordpress sites (wich by the way was auto-updating from wordpress 4.9 to 4.9.1), then interned strings used memory became full and sites started to go down with HTTP ERROR 500, and apache error log got lines like this:

[Thu Nov 30 15:40:40.273796 2017] [proxy_fcgi:error] [pid 17990:tid 140238684755712] [client 176.74.214.18:42343] AH01071: Got error 'PHP message: PHP Fatal error:  Cannot declare interface JsonSerializable, because the name is already in use in /home/USER/domains/DOMAIN.TLD/public_html/wp-includes/compat.php on line 428\n'

[Thu Nov 30 15:40:41.697018 2017] [proxy_fcgi:error] [pid 17990:tid 140238693148416] [client 176.74.214.18:52760] AH01071: Got error 'PHP message: PHP Fatal error:  Cannot declare interface JsonSerializable, because the name is already in use in /home/USER/domains/DOMAIN.TLD/public_html/wp-includes/compat.php on line 428\n'

In PHP info page it looks like this when interned strings used memory become full (and sites stop working!):

Interned Strings Used memory	4194288
Interned Strings Free memory	16

This is a completely show stoppper wich makes PHP 7.1.12 not usable. Some developers at PHP really need to take time to look deep into this now. It is a critical bug introduced in PHP 7.1.12 and (possibly 7.0.26) if you use opcache, wich forces you to stay on PHP 7.1.11 wich do not have this bug. Can someone at PHP please understand the seriousness in this?

Please study both this bug #75573 and my bug report #75579, they could be the same thing, or separate issues but somehow related.

NextGen gallery worked on my site for months with 7.0.26  why is it suddenly a problem with the PHP?  I foolishly updated today without reading the disabling ability. How can I uninstall the latest update?

@laruence, as far as I can see this is only fixed in 7.1+

While 7.0.26 is also affected.

Any sense when this commit/patch will be released? Thanks, Mike.

> Any sense when this commit/patch will be released?

The fix will be released with PHP 7.0.27, 7.1.13 and 7.2.1. The
PHP 7.0 and 7.1 releases are scheduled for January, 4th.

So can you make an update? You can adapt the plug-in to the current version.

> So can you make an update?

you can download tarballs with every commit at any time in point
https://git.php.net/?p=php-src.git;a=shortlog;h=refs/heads/PHP-7.1

Did the unused initialize methods have some bearing on this bug?

Since `A` does not have a parent it would fatal if it were ever called. I'm adding compile-time warnings to uses of `parent` when there isn't one and ran across this bug, but since it's "fixed" I can't tell if removing the unused methods has any bearing.