Missing information:

- the segfaults are sporadic
- checkout was git master branch at commit 66770f9c37e3821582b02f77867bf09141e59a51

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.

or an way to reproduce it with TYPO3(reproduce instructions)

As the crashs are sporadic I can't provide any test script.

To run TYPO3 functional tests you need to checkout TYPO3 master branch, add vendor data via composer and have a MySQL database.

mkdir typo3
cd typo3
git clone git://git.typo3.org/Packages/TYPO3.CMS.git .
composer.phar install

To get TYPO3 ready. Running the functional tests:

typo3DatabaseName="typo3_phpunit" typo3DatabaseUsername="typo3" typo3DatabasePassword="typo3typo3" typo3DatabaseHost="localhost" bin/phpunit -c typo3/sysext/core/Build/FunctionalTests.xml

Please change the DB connection data to your settings. To speed up the database side of the functional tests have a look at: https://wiki.typo3.org/Functional_testing#Using_a_ram_disk_for_the_database

hmm, it's sad, composer is blocked at my country (china)... :<

Hi laruence,

is http://getcomposer.org/ or https://packagist.org/ blocked?
I could provide a complete package from my master system, if this helps.

@ opitz , I asked bob to look into this one, and he already can reproduce it. but maybe fixed tomorrow. let's wait and see, thanks :)

./sapi/cli/php -r 'define("TEST", fopen("php://temp", "w+b"));'

gives me a few invalid reads with valgrind.

The fix is actually simple: In shutdown_executor(), move the call to clean_non_persistent_constants(); a few lines up above zend_close_rsrc_list(&EG(regular_list));

Though, I'm not sure if that might have side-effects [AFAIK, misordering in shutdown often causes subtle breaks] … so, can you please verify, Xinchen?

it can not work, since resource dtor may call some user function that uses constants

could you please verify whether the following patch fixed the problem?

diff --git a/Zend/zend_builtin_functions.c b/Zend/zend_builtin_functions.c
index fc834df..5dceaae 100644
--- a/Zend/zend_builtin_functions.c
+++ b/Zend/zend_builtin_functions.c
@@ -864,6 +864,10 @@ repeat:
        }

        ZVAL_DUP(&c.value, val);
+       if (Z_TYPE_INFO(c.value) == IS_RESOURCE_EX) {
+               /* disable resource constant destruction */
+               Z_TYPE_INFO(c.value) = IS_RESOURCE;
+       }
        zval_ptr_dtor(&val_free);
 register_constant:
        c.flags = case_sensitive; /* non persistent */

That fixes the issue, but is it safe? There might be places directly operating on the zend_resource * and manipulating its refcount [under the assumption that all resources are refcounted].

Also, even if it should be safe, copy_constant_array() needs to be patched too.

Hence, I propose this alternative patch (assuming constants are only ever freed at the end of the run):

diff --git a/Zend/zend_constants.c b/Zend/zend_constants.c
index 8d1be74..10648e4 100644
--- a/Zend/zend_constants.c
+++ b/Zend/zend_constants.c
@@ -33,7 +33,9 @@ void free_zend_constant(zval *zv)
        zend_constant *c = Z_PTR_P(zv);
 
        if (!(c->flags & CONST_PERSISTENT)) {
-               zval_dtor(&c->value);
+               if (Z_TYPE(c->value) != IS_RESOURCE) {
+                       zval_dtor(&c->value);
+               }
        } else {
                zval_internal_dtor(&c->value);
        }

hmm, forget that, in case of an array, it'll fail, because the arrays have the ZVAL_PTR_DTOR as destructor... So, not sure yet, what's best.