Edit report at http://bugs.php.net/bug.php?id=52784&edit=1
ID: 52784 Updated by: fel...@php.net Reported by: nick dot telford at gmail dot com Summary: Race condition when handling many concurrent signals -Status: Open +Status: Assigned Type: Bug Package: PCNTL related Operating System: Linux 2.6+ PHP Version: 5.3.3 -Assigned To: +Assigned To: lbarnaud Block user comment: N Previous Comments: ------------------------------------------------------------------------ [2010-09-06 18:15:23] nick dot telford at gmail dot com It's been suggested that signal.h isn't portable and should be checked for in config.m4. Thing is, if this functionality is disabled, there exists a potentially crippling race condition. Given the small number of people who actually use this extension, I would recommend that signal.h/sigprocmask etc. should be a pre-requisite for activating custom signal handling. Without it, all userland signal handling should be disabled - thoughts? ------------------------------------------------------------------------ [2010-09-06 18:09:03] nick dot telford at gmail dot com Description: ------------ When a user-defined signal handler has been defined and many concurrent signals are being delivered to it through ext/pcntl, a race-condition can occur causing memory corruption. ext/pcntl handles signals to user-defined functions by placing incoming signals in to a "pending signals queue" (linked-list), which is then iterated when pcntl_signal_dispatch() is called (either explicitly, or via a tick). However, if another signal interrupts the execution of the signal handler whilst it is manipulating this linked list, it can become corrupted. The correct solution is to block signals from being delivered to the handler whilst it is handling a signal. This is achieved using sigprocmask(SIG_BLOCK). We have two patches, the first just cleans up the allocation of the pending signals queue. The second directly addresses the problem by wrapping any block of code that alters the pending signal queue with a set of syscalls to block the handling of any new signals. This is the safest approach as blocking the signals will cause the kernel to queue and deliver them once the handler has been unblocked. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=52784&edit=1
