[PHP-BUG] Req #60938 [NEW]: xp_socket.c functions should respect pcntl signal handlers
From:
Operating system: *nix
PHP version: 5.3.9
Package: PCNTL related
Bug Type: Feature/Change Request
Bug description:xp_socket.c functions should respect pcntl signal handlers
Description:
Socket functions in xp_socket.c read and write indefinitely in case they
received
any
signal (read/write returned EINTR). Example, from
php_sock_stream_wait_for_data():
while(1) {
retval = php_pollfd_for(sock-socket, PHP_POLLREADABLE, ptimeout);
if (retval == 0) sock-timeout_event = 1;
if (retval = 0) break;
if (php_socket_errno() != EINTR) break;
}
The problem here is that this behavior is not compatible with pcntl signal
handling
because pcntl signals are implemented using ticks and this code actually
does not
exit
even if we need to call signal handler.
Suggested fix for read() is to take into account existence of PCNTL and do
the
following check:
if (php_socket_errno() != EINTR) break;
#ifdef PCNTL_G
else if(PCNTL_G(head)) break;
#endif
/* PCNTL_G(head) is pointer to a queue of signals
that were caught and will be processed after next tick.
This queue is empty if we do not register handlers for received signal.
*/
This fix (and adding ZEND_EXTERN_MODULE_GLOBALS(pcntl) to pcntl.c) gives
the
expected result below
Test script:
---
?php
declare(ticks = 1);
function sighandler($sig) {
echo Caught signal $sig, exiting correctly\n;
exit(1);
}
pcntl_signal(SIGINT, 'sighandler', false);
pcntl_signal(SIGHUP, 'sighandler', false);
mysql_connect(); // assumes 'mysqlnd' as MySQL driver
mysql_query('SELECT SLEEP(100)'); // ignores SIGINT and SIGHUP for 100 sec
Expected result:
$ php test.php
^C
Warning: mysql_query(): MySQL server has gone away in test.php on line 14
Warning: mysql_query(): Error reading result set's header in
/Users/nasretdinov/test.php on line 14
Caught signal 2, exiting correctly
Actual result:
--
$ php
^C
# ...after 100 sec...
Caught signal 2, exiting correctly
--
Edit bug report at https://bugs.php.net/bug.php?id=60938edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60938r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60938r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60938r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60938r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60938r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60938r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60938r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60938r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60938r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60938r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60938r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60938r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60938r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60938r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60938r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60938r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60938r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60938r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60938r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60938r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60938r=mysqlcfg
Bug #49340 [Com]: Signals not catchable when certain functions are in execution
Edit report at https://bugs.php.net/bug.php?id=49340edit=1 ID: 49340 Comment by: nasretdinov at gmail dot com Reported by:alexmontoanelli at gmail dot com Summary:Signals not catchable when certain functions are in execution Status: Open Type: Bug Package:PCNTL related Operating System: Linux PHP Version:5.2.10 Block user comment: N Private report: N New Comment: Actually it is due to syscall restarting by default. You should pass third argument as false to pcntl_signal and you will be able to catch SIGINT, but only after second attempt. The other bug I created (https://bugs.php.net/bug.php? id=52121) addresses more severe case, I suppose Previous Comments: [2009-08-31 13:42:12] alexmontoanelli at gmail dot com Ok.But I guess that this behavior is not that anyone expect. Some one else can give the final word ? Regards [2009-08-27 19:30:38] sjo...@php.net PHP signals are implemented with ticks (http://us3.php.net/manual/en/control-structures.declare.php). Ticks are events that occur every so much statements in a script. Since fgets() blocks, no more statements are executed and no more ticks are fired. This means that no signal arrives. I do not know whether the current behavior is by design or by mistake, so I cannot determine whether it is a bug or not. It would certainly be desirable to be able to interrupt a blocking read by doing Ctrl-C. [2009-08-27 11:28:41] alexmontoanelli at gmail dot com some position ? [2009-08-24 13:04:08] alexmontoanelli at gmail dot com Where I say: 'There is true?', is 'That's true?' Regards [2009-08-24 11:41:59] alexmontoanelli at gmail dot com The problem is that I need hit enter - exit from fgets - to run the signal handler - but this is not the correct way - in python for example, the signal handler are calling when the function are waiting for a user input. I found this page - http://br2.php.net/manual/en/function.pcntl-signal.php - the commentary above: '28-Mar-2006 07:26 Process handling is not available when using a blocking socket! Bear this in mind.' There is true? Regards The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49340 -- Edit this bug report at https://bugs.php.net/bug.php?id=49340edit=1
Bug #29100 [Com]: fread ignores memory_limit
Edit report at http://bugs.php.net/bug.php?id=29100edit=1 ID: 29100 Comment by: nasretdinov at gmail dot com Reported by: pickleman78 at sbcglobal dot net Summary: fread ignores memory_limit Status: Bogus Type: Bug Package: Reproducible crash Operating System: WIndows XP PHP Version: 4.3.6 New Comment: The this is that this does not lead to normal Fatal error, but to a web server/PHP uncatchable and undebuggable crash. Previous Comments: [2004-07-12 19:20:10] poll...@php.net emalloc() deosn't *actually* try to allocate the memory. It checks your requested amount against the php.ini setting and if it's too high, throws a fatal error. It has to be a fatal error because your script has outrun its resources, and it's impossible to predict whether or not it can safely continue operations in that condition. [2004-07-11 22:40:59] pickleman78 at sbcglobal dot net Description: I am getting a crash from PHP when I mistakenly attempt to read 1,761,607,681 bytes from an incoming socket. Now I would reasonably assume that since this is far above the memory limit set in my PHP.ini file memory_limit = 8M I would expect it to stop before even attempting to allocate such a rediculous ammount of memory for the script. In this case it fails with a FATAL: emalloc() unable to allocate 1761607681 bytes. Should this be what it does? I would expect it to issue an ERROR as opposed to crashing. Reproduce code: --- ?php $fp=fsockopen(http://php.net;); $data=fread($fp,1761607681); ? Expected result: It would be expected to receive an error as opposed to PHP trying to allocate this memory Actual result: -- Stated above, causes FATAL: emalloc() could not.. -- Edit this bug report at http://bugs.php.net/bug.php?id=29100edit=1
