#45518 [Opn->Bgs]: NULL matching zero, empty array, false
ID: 45518 User updated by: stephen dot cuppett at sas dot com Reported By: stephen dot cuppett at sas dot com -Status: Open +Status: Bogus Bug Type: Variables related Operating System: Windows XP/2003 PHP Version: 5.2.6 New Comment: NM, I see the loose comparisons table in the appendix. Previous Comments: [2008-07-15 12:19:28] stephen dot cuppett at sas dot com Description: I noticed a behavior with PHP 5.2.x that I found disturbing. PHP is matching variables initialized to zero, an empty array and false with NULL. From the documentation here: http://us2.php.net/NULL The only thing that should match NULL are ones that meet these criteria: A variable is considered to be null if: - it has been assigned the constant NULL. - it has not been set to any value yet. - it has been unset(). The function empty() should return true in the above cases (and does), but a comparison operator of == should not. FYI, is_null() returns false and the === operator works as expected too. Reproduce code: --- Expected result: Empty array, diff from NULL Zero, different from NULL Actual result: -- Empty array, same as NULL Zero, same as NULL -- Edit this bug report at http://bugs.php.net/?id=45518&edit=1
#45518 [NEW]: NULL matching zero, empty array, false
From: stephen dot cuppett at sas dot com Operating system: Windows XP/2003 PHP version: 5.2.6 PHP Bug Type: Variables related Bug description: NULL matching zero, empty array, false Description: I noticed a behavior with PHP 5.2.x that I found disturbing. PHP is matching variables initialized to zero, an empty array and false with NULL. From the documentation here: http://us2.php.net/NULL The only thing that should match NULL are ones that meet these criteria: A variable is considered to be null if: - it has been assigned the constant NULL. - it has not been set to any value yet. - it has been unset(). The function empty() should return true in the above cases (and does), but a comparison operator of == should not. FYI, is_null() returns false and the === operator works as expected too. Reproduce code: --- Expected result: Empty array, diff from NULL Zero, different from NULL Actual result: -- Empty array, same as NULL Zero, same as NULL -- Edit bug report at http://bugs.php.net/?id=45518&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45518&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45518&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45518&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45518&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45518&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45518&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45518&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45518&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45518&r=support Expected behavior:http://bugs.php.net/fix.php?id=45518&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45518&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45518&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45518&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45518&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45518&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45518&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45518&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45518&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45518&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45518&r=mysqlcfg
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994
Comment by: stephen dot cuppett at sas dot com
Reported By: dbarrett at vistaprint dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Windows 2003 Server, 64-bit
PHP Version: 5.2.6
New Comment:
I am also experiencing this problem. I have been able to recreate it
with system() as well as proc_open(). With proc_open() it doesn't seem
to matter if I set bypass_shell or not, just determines whether I have a
dangling cmd.exe process or not...
cmd.exe seems to stop at Wait:UserReq, but that probably doesn't mean
much.
I am able to reproduce it with XAMPP 1.6.6a (PHP 5.2.5) on Windows XP
or Windows Server 2003 (32-bit).
I don't have much to add in terms of documentation as I don't get
anything in the httpd logs, but using the following code snippet:
protected function runSAS($filename) {
$this->log("Requested to run SAS file:
" . $filename, LOG_DEBUG);
$toRun = "\"" . SAS . "\"";
$toRun .= " -sysin '" . $filename .
"'";
$toRun .= " -CONFIG '" . SASV9CFG .
"'";
$toRun .= " -PRINT '" . TEMP_DIR . "/"
. basename($filename) . ".lst'";
$toRun .= " -LOG '" . TEMP_DIR . "/" .
basename($filename) . ".log'";
$toRun .= " -NOSPLASH";
$this->log("SAS command to run: " .
$toRun, LOG_DEBUG);
$descriptorspec = array(
0 => array("pipe",
"r"), // stdin is a pipe that the child will read from
1 => array("pipe",
"w"), // stdout is a pipe that the child will write to
2 => array("pipe", "w")
// stderr is a file to write to
);
$res = proc_open($toRun,
$descriptorspec, $pipes, null, null, array(/*"bypass_shell" =>
true*/));
if (is_resource($res)) {
//fwrite($pipes[0],
"exit\n");
//fflush($pipes[0]);
fclose($pipes[0]);
fclose($pipes[1]);
fclose($pipes[2]);
$return_value =
proc_close($res);
$this->log("Return
value from SAS: " . $return_value, LOG_DEBUG);
}
}
When it does seem to complete, I'll get this in my log:
2008-06-26 20:23:55 Debug: Return value from SAS: 1
Nothing should come out on the pipes at all and when I set it up to
read those and it completes, there is no data read. However, in a hang
case, PHP blocks reading STDOUT instead of on proc_close never getting
any data... even if I set the stream to be non-blocking on the pipe
explicitely after proc_open.
Previous Comments:
[2008-07-07 18:27:57] dbarrett at vistaprint dot com
I received a report from [EMAIL PROTECTED] that he is also
experiencing this problem. I've tried to post it several times but the
CAPTCHA is blocking it with "Please do not SPAM our bug system." I'll
keep trying.
[2008-05-29 13:21:51] dbarrett at vistaprint dot com
I replaced all occurrences of exec() and shell_exec() in MediaWiki with
calls to a custom COM object that invokes programs. The problem went
away. This strongly suggests that PHP's implementation of exec(0 and
shell_exec() is the culprit. I suspect a race condition.
[2008-05-14 15:09:43] dbarrett at vistaprint dot com
Description:
This is an intermittent but fatal problem. I cannot reproduce it on
demand, but it occurs regularly on our MediaWiki 1.12.0 site running on
Apache 2.2.8.
When invoking a non-interactive Microsoft Windows command via exec() or
shell_exec(), sometimes the resulting process will hang. Once t
