php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #51580 socket_select randomly fails when used together with fork and Unix signals
Submitted: 2010-04-17 02:11 UTC Modified: 2010-05-12 15:48 UTC
From: marco at vmsoft-gbr dot de Assigned:
Status: Not a bug Package: PCNTL related
PHP Version: 5.3.2 OS: Debian Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: marco at vmsoft-gbr dot de
New email:
PHP Version: OS:

 

 [2010-04-17 02:11 UTC] marco at vmsoft-gbr dot de 
Description:
------------
When firing unix signals onto a forked process with pcntl_signal handlers active and a socket_select currently running, socket_select may crash.

Run the test script with php test.php 1339, and then launch some "kill -s 10 <child pid>" on it. After some, maybe just one, kill's, the script will crash.

Test script:
---------------
http://php.pastebin.com/Td68vtMn

Expected result:
----------------
Installing signal handlers
Installing handler for signal 15
Installing handler for signal 10
child-pid 20030
running
marco@vs932:~/php_daemon$ kill -s 10 20030
got signal 10
marco@vs932:~/php_daemon$ kill -s 10 20030
got signal 10
marco@vs932:~/php_daemon$ kill -s 10 20030
got signal 10

(etc)

Actual result:
--------------
Installing signal handlers
Installing handler for signal 15
Installing handler for signal 10
child-pid 20030
running
marco@vs932:~/php_daemon$ kill -s 10 20030
got signal 10
marco@vs932:~/php_daemon$ kill -s 10 20030
got signal 10
marco@vs932:~/php_daemon$ kill -s 10 20030
got signal 10
marco@vs932:~/php_daemon$ kill -s 10 20030
marco@vs932:~/php_daemon$ PHP Warning:  socket_select(): unable to select [4]: Interrupted system call in /home/marco/php_daemon/test.php on line 39
socket_select failed: Interrupted system call
end

marco@vs932:~/php_daemon$

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-04-17 03:51 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2010-04-17 03:51 UTC] pajoye@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
 [2010-04-17 11:06 UTC] marco at vmsoft-gbr dot de
-Status: Feedback +Status: Open
 [2010-04-17 11:06 UTC] marco at vmsoft-gbr dot de 
PHP itself doesn't crash, the error is not fatal - and how do I make a gdb backtrace on a forked process, anyway?
 [2010-04-17 11:13 UTC] marco at vmsoft-gbr dot de 
just ran it under gdb, it fails as expected, but as it's not segfaulting, no backtrace can be made.
 [2010-04-17 13:23 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2010-04-17 13:23 UTC] pajoye@php.net 
Can you try to generate a coredump and use it later to get a bt:

http://stackoverflow.com/questions/17965/generate-a-core-dump-in-linux
 [2010-04-17 13:39 UTC] marco at vmsoft-gbr dot de
-Status: Feedback +Status: Open
 [2010-04-17 13:39 UTC] marco at vmsoft-gbr dot de 
Uh, the PHP *process* doesn't crash, so no corefile. Sorry, was bad choice of words by me. Anyway, whatever happens with socket_select there should not happen... but how to backtrace that one without an actual crash?
 [2010-04-17 13:46 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2010-04-17 13:46 UTC] pajoye@php.net 
If it crashes then linux should be able to generate a core dump file (without gdb). You can then use it to generate a back trace.
 [2010-04-17 14:50 UTC] marco at vmsoft-gbr dot de
-Status: Feedback +Status: Open
 [2010-04-17 14:50 UTC] marco at vmsoft-gbr dot de 
It doesn't crash in the literal sense, as I said before this was a mistake in word choosing. So it's technically something other than a crash, but I dunno how to properly call it. It's a bug, that's the only thing thats sure.
 [2010-04-22 17:11 UTC] felipe@php.net
-Summary: socket_select randomly crashes when used together with fork and Unix signals +Summary: socket_select randomly fails when used together with fork and Unix signals
 [2010-05-12 15:48 UTC] mike@php.net
-Status: Open +Status: Bogus
 [2010-05-12 15:48 UTC] mike@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

See the restart_syscalls parameter.
 [2012-04-28 12:28 UTC] lykillerl at gmail dot com 
I also have this problem, the php no crash, still running, and i use the 
socket_select() time out to become the looping interval, but sometime the the 
socket_select() failed and no wait the time out, at the same time my client cannot 
connect to the server during the socket_select() function was failed.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 12:01:31 2024 UTC