preloading shutdown frees objects before module shutdown

[bwoebi]

Description

Since cecea72, preloading executes zend_shutdown_executor_values() early in accel_preload() directly, causing zend_objects_store_free_object_storage() to be called long before php_request_shutdown() is called, which calls php_module_shutdown() - before zend_shutdown_executor_values, normally.

Can we bring consistency here between regular request shutdown and preloading shutdown, so that the latter needs no special handling?

This change led to a crash in our extension creating an object at rinit and accessing it in rshutdown: DataDog/dd-trace-php#1795

==77== Invalid read of size 8
==77==    at 0x583BB80: ddtrace_close_all_open_spans (span.c:504)
==77==    by 0x582CAAB: zm_deactivate_ddtrace (ddtrace.c:897)
==77==    by 0x582CAAB: zm_deactivate_ddtrace (ddtrace.c:882)
==77==    by 0x51C81B: zend_deactivate_modules (in /usr/local/sbin/php-fpm)
==77==    by 0x4B0FB3: php_request_shutdown (in /usr/local/sbin/php-fpm)
==77==    by 0x56155FF: accel_finish_startup_preload (in /usr/local/lib/php/extensions/no-debug-non-zts-20210902/opcache.so)
==77==    by 0x5810D13: zai_interceptor_post_startup (interceptor.c:683)
==77==    by 0x515397: zend_post_startup (in /usr/local/sbin/php-fpm)
==77==    by 0x4B18DF: php_module_startup (in /usr/local/sbin/php-fpm)
==77==  Address 0x5a63b88 is 184 bytes inside a block of size 272 free'd
==77==    at 0x48C7488: free (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==77==    by 0x5B2B4B: zend_objects_store_del (in /usr/local/sbin/php-fpm)
==77==    by 0x5ADA7F: zend_object_std_dtor (in /usr/local/sbin/php-fpm)
==77==    by 0x5B2A3B: zend_objects_store_free_object_storage (in /usr/local/sbin/php-fpm)
==77==    by 0x504A17: zend_shutdown_executor_values (in /usr/local/sbin/php-fpm)
==77==    by 0x5613F5B: accel_preload (in /usr/local/lib/php/extensions/no-debug-non-zts-20210902/opcache.so)
==77==    by 0x56155CB: accel_finish_startup_preload (in /usr/local/lib/php/extensions/no-debug-non-zts-20210902/opcache.so)
==77==    by 0x5810D13: zai_interceptor_post_startup (interceptor.c:683)
==77==    by 0x515397: zend_post_startup (in /usr/local/sbin/php-fpm)
==77==    by 0x4B18DF: php_module_startup (in /usr/local/sbin/php-fpm)
==77==  Block was alloc'd at
==77==    at 0x48C4EC0: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==77==    by 0x4E6FB3: __zend_malloc (in /usr/local/sbin/php-fpm)
==77==    by 0x4EBA4F: _ecalloc (in /usr/local/sbin/php-fpm)
==77==    by 0x5828C8B: ddtrace_span_data_create (ddtrace.c:404)
==77==    by 0x5181EB: object_init_ex (in /usr/local/sbin/php-fpm)
==77==    by 0x583B063: ddtrace_init_span (span.c:247)
==77==    by 0x583B063: ddtrace_push_root_span (span.c:284)
==77==    by 0x582AA9B: zm_activate_ddtrace (ddtrace.c:834)
==77==    by 0x51C67F: zend_activate_modules (in /usr/local/sbin/php-fpm)
==77==    by 0x4B0BAB: php_request_startup (in /usr/local/sbin/php-fpm)

(ping @nikic being commit author)

PHP Version

PHP 8.1+

Operating System

No response

[bwoebi]

Ah, I see the primary difference between before and now: previously fast_shutdown was true, leading to zend_object_std_dtor calls not being executed at that place, which saved our custom objects.

The primary request still stands, though: ensure RSHUTDOWN is executed in the proper order relative to object freeing.

[phroggyy]

Just for reference to the different parts, to make debugging easier from the original change (as @bwoebi referred to a change in fast_shutdown):

It was originally 1 here: cecea72#diff-b66a794224587a12f8650298f931f4feafb7734f00885ad885f609a68e840949L4463

And was changed to false here: cecea72#diff-b66a794224587a12f8650298f931f4feafb7734f00885ad885f609a68e840949R4451 (which gets passed down to the same zend_objects_store_free_object_storage).