In setups such as PHP-FPM, each request is handled by a worker process. If the worker hits a fatal error, runs out of memory or receives a signal like SIGSEGV from a memory access fault, it dies, and the manager starts another. The visitor typically sees a 500 or 502 error, and the logs show a message saying that a child exited on a signal.
An occasional crash can be a plain bug. Repeated crashes caused by specific requests are more concerning, because memory corruption bugs can be a stepping stone to code execution, and an attacker often needs several attempts to get an exploit working. Each failed attempt may leave a crash in the log.
So crashes are worth reading as evidence. Look at the timing, the source address and the URL that came just before, and see whether the pattern repeats from one client.
Keep PHP and its extensions updated, monitor for child process exit messages, and treat a cluster of them after a new vulnerability is announced as a possible exploitation attempt.