If I understand https://github.com/php/php-src/blob/5a68d991ad20402ebfecba2a30b2dfdb197c8c8e/Zend/zend_execute_API.c#L1429 correctly, PHP is using setitimer(ITIMER_PROF) as a CPU time limit, and the problem that you are running into is that it thinks the timeout has been reached when it receives a spurious SIGPROF?

For that specific issue, it seems like the best approach would be for PHP to allow for spurious signals. e.g., when setting up the timeout, use clock_gettime(CLOCK_PROCESS_CPUTIME_ID) to get the current CPU time, and then the signal handle uses clock_gettime(CLOCK_PROCESS_CPUTIME_ID) to compute the duration to determine if the timeout has been reached.

However, there are more issues. e.g., both Go and PHP are trying to use the single setitimer(ITIMER_PROF) timer for different purposes. To work together they would probably need to find the lowest common denominator period between the two uses and then ignore extra signals beyond the frequency they care about. On Linux, Go and/or PHP could use timer_create() to create custom CPU timers that won't conflict with each other (they'd still need to filter signals by timer source), but I don't think all OSes have equivalent functionality. On Darwin/macOS, I think setitimer may be the only available CPU timer?

For better or for worse, there is only one SIGPROF signal. There is really no way that both PHP and Go can use it simultaneously for different purposes.

That said, simply running a plain go test should not cause Go to start generating SIGPROF signals. That should only happen if something explicitly calls runtime/pprof.StartCPUProfile. So the first step might be to find out what is calling that function. An ordinary Go test should only do that if explicitly invoked with the -test.cpuprofile option.

Fixed on the PHP side: php/php-src#10141