One thing you can try, to find a reproduction procedure from a core dump, is to dump the request data:

Core was generated by `php-fpm: pool www'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  php_request_shutdown (dummy=dummy@entry=0x0) at ./main/main.c:1784
1784    ./main/main.c: No such file or directory.
[Current thread is 1 (Thread 0x7f5c84e5aa00 (LWP 281))]
(gdb) source /srv/php/core/.gdbinit
(gdb) printzv &core_globals.http_globals[3]
[0x55b69526d010] (refcount=2) array:     Hash(51)[0x7f5c820581c0]: {
      [0] "USER" => [0x7f5c82062c00] (refcount=2) string: www-data
      [1] "HOME" => [0x7f5c82062c20] (refcount=2) string: /var/www
...

http_globals[3] is TRACK_VARS_SERVER, i.e. $_SERVER.

Then you can run the request again by feeding that back into curl. If that's not enough, maybe run it 1000 times.

If the request calls the parser, you may have to suppress the parser cache to reproduce the bug. Maybe get the cache key out of the debug log, and delete it before each request.

Thanks a lot, Tim :)- using your advice, I inspected a more recent dump and found that it was a request where PHP was exceeding its configured memory limit while it was parsing a rather complex page. Going by that, I managed to narrow it down to a consistent reproducer:

--TEST--
Memory limit exceeded during sandbox init
--INI--
memory_limit=2M
--FILE--
<?php
$buf = str_repeat('a', 1000000);
$sandboxes = [];
for ($i = 0; $i < 100; $i++) {
    $sandboxes[] = new LuaSandbox();
}
?>
--EXPECTF--
Fatal error: Allowed memory size of 2097152 bytes exhausted%s(tried to allocate %d bytes) in %s on line %d

This seems to reliably segfault on PHP 8.2. It seems that this is because the assignment of standard handlers sandbox->std.handlers = &luasandbox_object_handlers; occurs only after the sandbox state is allocated, which uses the Zend allocator and so may trigger PHP's memory limiter. Then the process dumps core during the shutdown phase.

I'll make a patch.

I think this is not a PHP 8.0 specific issue, it'd likely happen on earlier versions as well. We just happened to notice it because we were on the lookout for core dumps while investigating unrelated JIT issues.

Change 938925 had a related patch set uploaded (by TK-999; author: TK-999):

[mediawiki/php/luasandbox@master] Fix segmentation fault when memory limit is exceeded in LuaSandbox init

https://gerrit.wikimedia.org/r/938925

Change 938925 merged by jenkins-bot:

[mediawiki/php/luasandbox@master] Fix segmentation fault when memory limit is exceeded in LuaSandbox init

https://gerrit.wikimedia.org/r/938925

Thanks @TK-999!

It would seem that there's a critical section between zend_object_std_init() and the assignment of handlers, during which time it's unsafe to call emalloc().

I grepped the PHP in-tree extensions, and it looks like there are a few that have the same problem. I'll probably file something upstream about this.

I filed https://github.com/php/php-src/issues/11734

Thanks, this is great!