Bug #52784 [Opn->Asn]: Race condition when handling many concurrent signals
| From: | felipe@php.net | Date: | Thu, 09 Sep 2010 00:13:04 +0000 |
| Subject: | Bug #52784 [Opn->Asn]: Race condition when handling many concurrent signals | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-154199@lists.php.net to get a copy of this message | ||
Edit report at http://bugs.php.net/bug.php?id=52784&edit=1
ID: 52784
Updated by: felipe@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