Bug #61141 [Com]: curl_multi_select returns -1
Edit report at https://bugs.php.net/bug.php?id=61141&edit=1 ID: 61141 Comment by: kulminaator at gmail dot com Reported by:amoo_miki at yahoo dot com Summary:curl_multi_select returns -1 Status: Open Type: Bug Package:cURL related Operating System: Windows 7 x64 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Running PHP 5.4.0 on Windows 7 has the same issue, curl_multi_select always returns -1 PHP Version => 5.4.0 System => Windows NT MSA-3644048 6.1 build 7601 (Windows 7 Enterprise Edition Service Pack 1) i586 cURL support => enabled cURL Information => 7.24.0 Age => 3 Features AsynchDNS => Yes Debug => No GSS-Negotiate => Yes IDN => No IPv6 => Yes Largefile => Yes NTLM => Yes SPNEGO => No SSL => Yes SSPI => Yes krb4 => No libz => Yes CharConv => No Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp Host => i386-pc-win32 SSL Version => OpenSSL/0.9.8t ZLib Version => 1.2.5 libSSH Version => libssh2/1.3.0 Previous Comments: [2012-04-03 16:26:35] bompus at gmail dot com Related to 60790 and 61240 [2012-02-29 08:17:12] amoo_miki at yahoo dot com The curl details on 5.3.9 are: cURL support => enabled cURL Information => 7.21.7 Age => 3 Features AsynchDNS => Yes Debug => No GSS-Negotiate => Yes IDN => No IPv6 => Yes Largefile => Yes NTLM => Yes SPNEGO => No SSL => Yes SSPI => Yes krb4 => No libz => Yes CharConv => No Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp Host => i386-pc-win32 SSL Version => OpenSSL/0.9.8r ZLib Version => 1.2.5 libSSH Version => libssh2/1.2.7 meaning the changes are related to one of the following: 5.3.9 -> 5.3.10 libcURL: 7.21.7 -> 7.24.0 GSS/Negotiate: Yes -> NO SSPI:Yes -> No OpenSSL: 0.9.8r -> 0.9.8t libSSH:1.2.7 -> 1.3.0 I don't see a reason for the last 2 effecting anything. [2012-02-28 22:09:05] bompus at gmail dot com I hope this helps. curl_multi_select works fine on my PHP 5.3.6 under Windows 7 x64 with the following CURL information: cURL support => enabled cURL Information => 7.21.2 Age => 3 Features AsynchDNS => Yes Debug => No GSS-Negotiate => No IDN => No IPv6 => Yes Largefile => Yes NTLM => Yes SPNEGO => No SSL => Yes SSPI => Yes krb4 => No libz => Yes CharConv => No Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp Host => i386-pc-win32 SSL Version => OpenSSL/1.0.0d ZLib Version => 1.2.3 libSSH Version => libssh2/1.2.7 - Under PHP 5.3.10 on Windows 7 x64, curl_multi_select is always returning -1 with the following CURL information: cURL support => enabled cURL Information => 7.24.0 Age => 3 Features AsynchDNS => Yes Debug => No GSS-Negotiate => No IDN => No IPv6 => Yes Largefile => Yes NTLM => Yes SPNEGO => No SSL => Yes SSPI => No krb4 => No libz => Yes CharConv => No Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp Host => i386-pc-win32 SSL Version => OpenSSL/0.9.8t ZLib Version => 1.2.5 libSSH Version => libssh2/1.3.0 I am trying to make GET requests to https:// is that helps. I noticed that there are different versions of libcurl and OpenSSL used, so it could end up being an issue with either one of those, most likely libcurl or PHP itself. Hope this helps! [2012-02-28 16:52:26] bompus at gmail dot com Same exact problem and has been driving me nuts. I keep having to revert back to PHP 5.3.6 -- I have not tried 5.3.9 yet, but did try 5.3.10 and had the same issue. I am running loops with curl_multi_select and they always time out because of an infinite loop since it's always returning -1 [2012-02-20 20:28:50] amoo_miki at yahoo dot com I put some debug code and got to "curl_multi_select" returning -1 no matter what, which seems to mean failure from the underlying select system call. So I guess, the conversation between Win7 x64 and cURL in 5.3.10 is not going smooth. 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=61141 -- Edit this bug report at https://bugs.php.net/bug.php?id=61141&edit=1
#47020 [NEW]: print_r produces output with $return set to true
From: kulminaator at gmail dot com Operating system: Mac OS X 10.5.6 PHP version: 5.2.8 PHP Bug Type: Scripting Engine problem Bug description: print_r produces output with $return set to true Description: print_r creates output although it was not asked to The code $str = print_r($expression, true); should never produce any output, but it does if php hits the memory limit closely enough. My memory_limit is set to 128M (may be this has to be the same to reproduce the bug). Needless to say, this is a security issue and may output information to clients that never should go there by the code. Reproduce code: --- http://bugs.php.net/?id=47020&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47020&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47020&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47020&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47020&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47020&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47020&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47020&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47020&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47020&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47020&r=support Expected behavior: http://bugs.php.net/fix.php?id=47020&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47020&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47020&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47020&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47020&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47020&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47020&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47020&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47020&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47020&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47020&r=mysqlcfg
#47020 [Bgs]: print_r produces output with $return set to true
ID: 47020 User updated by: kulminaator at gmail dot com Reported By: kulminaator at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Mac OS X 10.5.6 PHP Version: 5.2.8 New Comment: even with display_errors set to Off or zero, output is still produced Previous Comments: [2009-01-15 15:22:04] j...@php.net This has nothing to do with print_r(). Fix your php.ini not to output errors. [2009-01-06 15:19:37] finsoft at gmail dot com Same thing reproduced on PHP Version 5.2.6, Windows XP Pro SP3, Apache 2.2.8 [2009-01-06 14:05:13] kulminaator at gmail dot com Description: print_r creates output although it was not asked to The code $str = print_r($expression, true); should never produce any output, but it does if php hits the memory limit closely enough. My memory_limit is set to 128M (may be this has to be the same to reproduce the bug). Needless to say, this is a security issue and may output information to clients that never should go there by the code. Reproduce code: --- http://bugs.php.net/?id=47020&edit=1
#47020 [Bgs]: print_r produces output with $return set to true
ID: 47020
User updated by: kulminaator at gmail dot com
Reported By: kulminaator at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Mac OS X 10.5.6
PHP Version: 5.2.8
New Comment:
After looking around a bit, this extra output of
xxx like data is caused by the weird
behaviour of ob_start/ob_end and the fact that output buffers are always
flushed when a fatal error is coughed up from below.
straight from the source of ext/standard/basic_functions.c
PHP_FUNCTION(print_r)
{
zval *var;
zend_bool i = 0;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z|b", &var,
&i) == FAILURE) {
RETURN_FALSE;
}
if (i) {
php_start_ob_buffer (NULL, 0, 1 TSRMLS_CC);
}
zend_print_zval_r(var, 0 TSRMLS_CC);
if (i) {
php_ob_get_buffer (return_value TSRMLS_CC);
php_end_ob_buffer (0, 0 TSRMLS_CC);
} else {
RETURN_TRUE;
}
}
Here the zend_print_zval_r causes creating/appending to ob , ob hits
the memory limit and bang, the output is created, although it never
should be.
Can we hope for a fix (either root out the issue of ob being flushed or
avoiding ob in the first place ?) or are supposed to remove all
sensitive data from ever reaching print_r ?
Previous Comments:
[2009-01-15 15:45:27] kulminaator at gmail dot com
even with display_errors set to Off or zero, output is still produced
[2009-01-15 15:22:04] j...@php.net
This has nothing to do with print_r(). Fix your php.ini not to output
errors.
[2009-01-06 15:19:37] finsoft at gmail dot com
Same thing reproduced on PHP Version 5.2.6, Windows XP Pro SP3, Apache
2.2.8
[2009-01-06 14:05:13] kulminaator at gmail dot com
Description:
print_r creates output although it was not asked to
The code
$str = print_r($expression, true);
should never produce any output, but it does if php hits the memory
limit closely enough.
My memory_limit is set to 128M (may be this has to be the same to
reproduce the bug).
Needless to say, this is a security issue and may output information to
clients that never should go there by the code.
Reproduce code:
---
http://bugs.php.net/?id=47020&edit=1
