#51152 [NEW]: socket_select
From: 9669105 at qq dot com
Operating system: windows xp
PHP version: 5.2.13
PHP Bug Type: CGI related
Bug description: socket_select
Description:
I am not good at english .
I pass an array with 257 sockets to monitor for changes, a warning :
unable to select [0]:An operation was attempted on something that is not a
socket.
Why?
Reproduce code:
---
$i = 0;
$sockets = array();
while (true) {
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
if (socket_connect($socket, '192.168.1.101', 11001)) {
socket_set_nonblock($socket);
$sockets[] = $socket;
$i = $i + 1;
} else {
break;
}
}
echo $i;
Expected result:
$i=257 always.
How can pass an array more than 257 sockets ?
--
Edit bug report at http://bugs.php.net/?id=51152&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51152&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51152&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51152&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51152&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51152&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51152&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51152&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51152&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51152&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51152&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51152&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51152&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51152&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51152&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51152&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51152&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51152&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51152&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51152&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51152&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51152&r=mysqlcfg
#50839 [NoF->Opn]: log_errors + display_errors = bogus timezone warning in response entity
ID: 50839 User updated by: miqrogroove at gmail dot com Reported By: miqrogroove at gmail dot com -Status: No Feedback +Status: Open Bug Type: PHP options/info functions Operating System: Windows 2003 PHP Version: 5.3.1 New Comment: Please keep this bug open. Previous Comments: [2010-02-26 06:23:57] miqrogroove at gmail dot com Please keep this bug open. [2010-02-03 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-01-27 06:26:49] miqrogroove at gmail dot com > you should actually read the error message and do what it suggests? As a developer, I don't have the luxury of assuming servers are configured a certain way. Since PHP offers no way to check if the default timezone has been set already, the only alternative I have is to disable error reporting, so that functions like mail() wont interrupt header output or image generation. If you do find that Windows snapshot for me, could you check if it comes with the installer, or if there are any instructions for upgrading without the installer? [2010-01-27 02:03:36] miqrogroove at gmail dot com hi jani, I followed your link and all it says is: PHP 5.3 5.3 has no release. PHP 5.2 5.2 has no release. PHP 6.0 6.0 has no release. [2010-01-26 07:27:40] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ IIRC, this was fixed already..then again, you should actually read the error message and do what it suggests? :) 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 http://bugs.php.net/50839 -- Edit this bug report at http://bugs.php.net/?id=50839&edit=1
#50839 [Com]: log_errors + display_errors = bogus timezone warning in response entity
ID: 50839 Comment by: miqrogroove at gmail dot com Reported By: miqrogroove at gmail dot com Status: No Feedback Bug Type: PHP options/info functions Operating System: Windows 2003 PHP Version: 5.3.1 New Comment: Please keep this bug open. Previous Comments: [2010-02-03 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-01-27 06:26:49] miqrogroove at gmail dot com > you should actually read the error message and do what it suggests? As a developer, I don't have the luxury of assuming servers are configured a certain way. Since PHP offers no way to check if the default timezone has been set already, the only alternative I have is to disable error reporting, so that functions like mail() wont interrupt header output or image generation. If you do find that Windows snapshot for me, could you check if it comes with the installer, or if there are any instructions for upgrading without the installer? [2010-01-27 02:03:36] miqrogroove at gmail dot com hi jani, I followed your link and all it says is: PHP 5.3 5.3 has no release. PHP 5.2 5.2 has no release. PHP 6.0 6.0 has no release. [2010-01-26 07:27:40] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ IIRC, this was fixed already..then again, you should actually read the error message and do what it suggests? :) [2010-01-26 06:31:28] miqrogroove at gmail dot com I also confirmed that any call to the mail() function results in two identical warnings on screen, and one in the log. 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 http://bugs.php.net/50839 -- Edit this bug report at http://bugs.php.net/?id=50839&edit=1
#45149 [WFx]: Handling plus sign in an url failed
ID: 45149 Updated by: ras...@php.net Reported By: frode dot langvik at exense dot com Status: Wont fix Bug Type: Strings related Operating System: * PHP Version: 5.2.6 New Comment: Yes, just to echo the previous comment. base64-encoding is not safe for URLs. That's why Flickr and other sites use base58-encoding to generate unique tokens for their URLs. You will need to urlencode your base64-encoded strings. Even if we hacked it in PHP, it would break other places. Previous Comments: [2010-02-26 03:53:23] ahar...@php.net This was changed by the fix for bug #34214 (revision 194419, just in case anyone's morbidly interested). Frankly, this is a classic case of "damned if you do, damned if you don't": the "new" behaviour (which has actually been in place since PHP 5.1.0, so since November 2005 in a stable release) is compliant with the spec, while the "old" behaviour was more useful for software that doesn't properly URL encode base64 values in GET variables. Given that you can't really have this both ways and PHP 5 has had the "new" behaviour for more than four years, I doubt we'd change this back now. The real lesson in this is that you do need to urlencode() or rawurlencode() base64 data in URLs, since + characters do have a special meaning there. [2010-02-26 02:40:15] mat at ucsc dot edu We are seeing this issue with base64_encode and base64_decode. We have php 5.2.6 and the url string contains a '+' sign in the url parameter, however, in php itself if we $_GET the same parameter the + is replaced by a space. The base64_decode cannot use this value in php 5.2.6. However, 5.0.4 (my other running reference) base64_decode can read the blank. So the blank may be okay except that base64_decode seems to have changed in the newer version. Here is a test: The url parameter is (has +): YTozMDp7czo0OiJTVFJNIjtzOjQ6IjIxMDIiO3M6OToiQ0xBU1NfTkJSIjtzOjU6IjcyNTczIjtzOjEzOiJDTEFTU19TRUNUSU9OIjtzOjI6IjAxIjtzOjEzOiJDTEFTU19NVEdfTkJSIjtzOjE6IjEiO3M6MTI6IlNFU1NJT05fQ09ERSI7czoxOiIxIjtzOjEwOiJDTEFTU19TVEFUIjtzOjE6IkEiO3M6NzoiU1VCSkVDVCI7czo0OiJCSU9FIjtzOjExOiJDQVRBTE9HX05CUiI7czo0OiIgMTA3IjtzOjU6IkRFU0NSIjtzOjc6IkVjb2xvZ3kiO3M6MTM6IlNTUl9DT01QT05FTlQiO3M6MzoiTEVDIjtzOjEwOiJTVEFSVF9USU1FIjtzOjc6IjAyOjAwUE0iO3M6ODoiRU5EX1RJTUUiO3M6NzoiMDM6NDVQTSI7czo5OiJGQUNfREVTQ1IiO3M6MTQ6IkVpZ2h0IEFjYWQgMjQwIjtzOjM6Ik1PTiI7czoxOiJOIjtzOjQ6IlRVRVMiO3M6MToiWSI7czozOiJXRUQiO3M6MToiTiI7czo1OiJUSFVSUyI7czoxOiJZIjtzOjM6IkZSSSI7czoxOiJOIjtzOjM6IlNBVCI7czoxOiJOIjtzOjM6IlNVTiI7czoxOiJOIjtzOjk6IkVOUkxfU1RBVCI7czoxOiJPIjtzOjg6IldBSVRfVE9UIjtzOjE6IjAiO3M6ODoiRU5STF9DQVAiO3M6MjoiNzYiO3M6ODoiRU5STF9UT1QiO3M6MToiMCI7czo5OiJMQVNUX05BTUUiO3M6NToiTW9vcmUiO3M6MTA6IkZJUlNUX05BTUUiO3M6ODoiSm9uYXRoYW4iO3M6MTE6Ik1JRERMRV9OQU1FIjtzOjE6IlciO3M6MTY6IkNPTUJJTkVEX1NFQ1RJT04iO3M6MToiICI7czo1OiJUT1BJQyI7TjtzOjEyO! iJESVNQTEFZX05BTUUiO3M6MjQ6IkVzdGVzLEouQS48YnI+TW9vcmUsSi5XLiI7fQ== The $_GET value of this data dropps the + to look like this (in case text wrap breaks on my space it is a space at column 1036): YTozMDp7czo0OiJTVFJNIjtzOjQ6IjIxMDIiO3M6OToiQ0xBU1NfTkJSIjtzOjU6IjcyNTczIjtzOjEzOiJDTEFTU19TRUNUSU9OIjtzOjI6IjAxIjtzOjEzOiJDTEFTU19NVEdfTkJSIjtzOjE6IjEiO3M6MTI6IlNFU1NJT05fQ09ERSI7czoxOiIxIjtzOjEwOiJDTEFTU19TVEFUIjtzOjE6IkEiO3M6NzoiU1VCSkVDVCI7czo0OiJCSU9FIjtzOjExOiJDQVRBTE9HX05CUiI7czo0OiIgMTA3IjtzOjU6IkRFU0NSIjtzOjc6IkVjb2xvZ3kiO3M6MTM6IlNTUl9DT01QT05FTlQiO3M6MzoiTEVDIjtzOjEwOiJTVEFSVF9USU1FIjtzOjc6IjAyOjAwUE0iO3M6ODoiRU5EX1RJTUUiO3M6NzoiMDM6NDVQTSI7czo5OiJGQUNfREVTQ1IiO3M6MTQ6IkVpZ2h0IEFjYWQgMjQwIjtzOjM6Ik1PTiI7czoxOiJOIjtzOjQ6IlRVRVMiO3M6MToiWSI7czozOiJXRUQiO3M6MToiTiI7czo1OiJUSFVSUyI7czoxOiJZIjtzOjM6IkZSSSI7czoxOiJOIjtzOjM6IlNBVCI7czoxOiJOIjtzOjM6IlNVTiI7czoxOiJOIjtzOjk6IkVOUkxfU1RBVCI7czoxOiJPIjtzOjg6IldBSVRfVE9UIjtzOjE6IjAiO3M6ODoiRU5STF9DQVAiO3M6MjoiNzYiO3M6ODoiRU5STF9UT1QiO3M6MToiMCI7czo5OiJMQVNUX05BTUUiO3M6NToiTW9vcmUiO3M6MTA6IkZJUlNUX05BTUUiO3M6ODoiSm9uYXRoYW4iO3M6MTE6Ik1JRERMRV9OQU1FIjtzOjE6IlciO3M6MTY6IkNPTUJJTkVEX1NFQ1RJT04iO3M6MToiICI7czo1OiJUT1BJQyI7TjtzOjEyO! iJESVNQTEFZX05BTUUiO3M6MjQ6IkVzdGVzLEouQS48YnI TW9vcmUsSi5XLiI7fQ== Using a bit of php one can try the base64_decode on both strings. It will produce data with the +, but not with the space (5.2.6). Here is the test case code with a space (be careful text will line break on the space in some editors): After calling base64_decode ... "; echo ''; print_r($class_result); echo ''; $class_result = unserialize($class_result); echo "After unserialized ... "; echo ''; print_r($class_result); echo "Start print class_resul "; print_r($class_result); echo "*"; ?> Here is code with the + in the string: After calling base64_decode ... "; echo ''; print_r($class_result); echo ''; $class_result = unserialize($class_result
#45149 [NoF->WFx]: Handling plus sign in an url failed
ID: 45149 Updated by: ahar...@php.net Reported By: frode dot langvik at exense dot com -Status: No Feedback +Status: Wont fix Bug Type: Strings related Operating System: * PHP Version: 5.2.6 New Comment: This was changed by the fix for bug #34214 (revision 194419, just in case anyone's morbidly interested). Frankly, this is a classic case of "damned if you do, damned if you don't": the "new" behaviour (which has actually been in place since PHP 5.1.0, so since November 2005 in a stable release) is compliant with the spec, while the "old" behaviour was more useful for software that doesn't properly URL encode base64 values in GET variables. Given that you can't really have this both ways and PHP 5 has had the "new" behaviour for more than four years, I doubt we'd change this back now. The real lesson in this is that you do need to urlencode() or rawurlencode() base64 data in URLs, since + characters do have a special meaning there. Previous Comments: [2010-02-26 02:40:15] mat at ucsc dot edu We are seeing this issue with base64_encode and base64_decode. We have php 5.2.6 and the url string contains a '+' sign in the url parameter, however, in php itself if we $_GET the same parameter the + is replaced by a space. The base64_decode cannot use this value in php 5.2.6. However, 5.0.4 (my other running reference) base64_decode can read the blank. So the blank may be okay except that base64_decode seems to have changed in the newer version. Here is a test: The url parameter is (has +): YTozMDp7czo0OiJTVFJNIjtzOjQ6IjIxMDIiO3M6OToiQ0xBU1NfTkJSIjtzOjU6IjcyNTczIjtzOjEzOiJDTEFTU19TRUNUSU9OIjtzOjI6IjAxIjtzOjEzOiJDTEFTU19NVEdfTkJSIjtzOjE6IjEiO3M6MTI6IlNFU1NJT05fQ09ERSI7czoxOiIxIjtzOjEwOiJDTEFTU19TVEFUIjtzOjE6IkEiO3M6NzoiU1VCSkVDVCI7czo0OiJCSU9FIjtzOjExOiJDQVRBTE9HX05CUiI7czo0OiIgMTA3IjtzOjU6IkRFU0NSIjtzOjc6IkVjb2xvZ3kiO3M6MTM6IlNTUl9DT01QT05FTlQiO3M6MzoiTEVDIjtzOjEwOiJTVEFSVF9USU1FIjtzOjc6IjAyOjAwUE0iO3M6ODoiRU5EX1RJTUUiO3M6NzoiMDM6NDVQTSI7czo5OiJGQUNfREVTQ1IiO3M6MTQ6IkVpZ2h0IEFjYWQgMjQwIjtzOjM6Ik1PTiI7czoxOiJOIjtzOjQ6IlRVRVMiO3M6MToiWSI7czozOiJXRUQiO3M6MToiTiI7czo1OiJUSFVSUyI7czoxOiJZIjtzOjM6IkZSSSI7czoxOiJOIjtzOjM6IlNBVCI7czoxOiJOIjtzOjM6IlNVTiI7czoxOiJOIjtzOjk6IkVOUkxfU1RBVCI7czoxOiJPIjtzOjg6IldBSVRfVE9UIjtzOjE6IjAiO3M6ODoiRU5STF9DQVAiO3M6MjoiNzYiO3M6ODoiRU5STF9UT1QiO3M6MToiMCI7czo5OiJMQVNUX05BTUUiO3M6NToiTW9vcmUiO3M6MTA6IkZJUlNUX05BTUUiO3M6ODoiSm9uYXRoYW4iO3M6MTE6Ik1JRERMRV9OQU1FIjtzOjE6IlciO3M6MTY6IkNPTUJJTkVEX1NFQ1RJT04iO3M6MToiICI7czo1OiJUT1BJQyI7TjtzOjEyO! iJESVNQTEFZX05BTUUiO3M6MjQ6IkVzdGVzLEouQS48YnI+TW9vcmUsSi5XLiI7fQ== The $_GET value of this data dropps the + to look like this (in case text wrap breaks on my space it is a space at column 1036): YTozMDp7czo0OiJTVFJNIjtzOjQ6IjIxMDIiO3M6OToiQ0xBU1NfTkJSIjtzOjU6IjcyNTczIjtzOjEzOiJDTEFTU19TRUNUSU9OIjtzOjI6IjAxIjtzOjEzOiJDTEFTU19NVEdfTkJSIjtzOjE6IjEiO3M6MTI6IlNFU1NJT05fQ09ERSI7czoxOiIxIjtzOjEwOiJDTEFTU19TVEFUIjtzOjE6IkEiO3M6NzoiU1VCSkVDVCI7czo0OiJCSU9FIjtzOjExOiJDQVRBTE9HX05CUiI7czo0OiIgMTA3IjtzOjU6IkRFU0NSIjtzOjc6IkVjb2xvZ3kiO3M6MTM6IlNTUl9DT01QT05FTlQiO3M6MzoiTEVDIjtzOjEwOiJTVEFSVF9USU1FIjtzOjc6IjAyOjAwUE0iO3M6ODoiRU5EX1RJTUUiO3M6NzoiMDM6NDVQTSI7czo5OiJGQUNfREVTQ1IiO3M6MTQ6IkVpZ2h0IEFjYWQgMjQwIjtzOjM6Ik1PTiI7czoxOiJOIjtzOjQ6IlRVRVMiO3M6MToiWSI7czozOiJXRUQiO3M6MToiTiI7czo1OiJUSFVSUyI7czoxOiJZIjtzOjM6IkZSSSI7czoxOiJOIjtzOjM6IlNBVCI7czoxOiJOIjtzOjM6IlNVTiI7czoxOiJOIjtzOjk6IkVOUkxfU1RBVCI7czoxOiJPIjtzOjg6IldBSVRfVE9UIjtzOjE6IjAiO3M6ODoiRU5STF9DQVAiO3M6MjoiNzYiO3M6ODoiRU5STF9UT1QiO3M6MToiMCI7czo5OiJMQVNUX05BTUUiO3M6NToiTW9vcmUiO3M6MTA6IkZJUlNUX05BTUUiO3M6ODoiSm9uYXRoYW4iO3M6MTE6Ik1JRERMRV9OQU1FIjtzOjE6IlciO3M6MTY6IkNPTUJJTkVEX1NFQ1RJT04iO3M6MToiICI7czo1OiJUT1BJQyI7TjtzOjEyO! iJESVNQTEFZX05BTUUiO3M6MjQ6IkVzdGVzLEouQS48YnI TW9vcmUsSi5XLiI7fQ== Using a bit of php one can try the base64_decode on both strings. It will produce data with the +, but not with the space (5.2.6). Here is the test case code with a space (be careful text will line break on the space in some editors): After calling base64_decode ... "; echo ''; print_r($class_result); echo ''; $class_result = unserialize($class_result); echo "After unserialized ... "; echo ''; print_r($class_result); echo "Start print class_resul "; print_r($class_result); echo "*"; ?> Here is code with the + in the string: After calling base64_decode ... "; echo ''; print_r($class_result); echo ''; $class_result = unserialize($class_result); echo "After unserialized ... "; echo ''; print_r($class_result); echo "Start print class_resul "; print_r($class_result); echo "*"; ?> This will dump an array course data I generated. The only difference is the space or +. In 5.0.4 it works with a space. The space is not there in the URL in 5.2.6, but is after a $_GET on the parameter.
#51146 [Fbk->Opn]: mcrypt doesn't do OFB mode correctly
ID: 51146
User updated by: zelnaga at gmail dot com
Reported By: zelnaga at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: mcrypt related
Operating System: Windows XP
PHP Version: 5.3.1
New Comment:
Filing a bug report is going to be a little difficult giving that, near
as I can tell, the command line version of mcrypt randomly generates
IV's. My first example requires the IV's be of a known value and my
second example requires encrypting the same string with two different
modes and with the same IV.
Also, to be honest, I don't know at all how to intreprete the data the
command line version of mcrypt is giving me, anyway. I do the
following:
mcrypt --algorithm des --mode ecb --no-openpgp test.txt --verbose
--bare
And I get a 100 byte file. Given that the source file was 16 bytes
("-" repeated sixteen times), that's a bit odd. Curious to see what the
remaining 84 bytes are, I do the following:
And that doesn't produce anything even remotely resembling the source
text.
A while ago, there was a bug report filed on the mcrypt PHP extension
(49561) where someone reproduced the problem in C, using the mcrypt
libraries, and filed the bug report themselves. Can't that be done
here? I don't have the ability to compile PHP or PHP extensions such as
mcrypt and if no one reports the bug to the mcrypt developers than both
PHP and mcrypt will have this bug.
Of course, then again, given that bug # 49561 hasn't even been touched
by the mcrypt developers, it seems safe to assume that any bug report
that's filed - by me or anyone else - will be ignored. If mcrypt has
been abandoned by its developers when does PHP abandon mcrypt?
Previous Comments:
[2010-02-25 19:23:47] paj...@php.net
It looks like a libmcrypt problem, if it is a bug. Can you try using
the mcrypt cmd line tools? If it fails and you see it as a bug, please
report a bug to the mcrypt project. Let us know how it went.
[2010-02-25 18:18:35] zelnaga at gmail dot com
mcrypt also seems to be implementing OFB and CFB modes identically.
Although the first block produced by either mode should be the same,
subsequent blocks should be different. ie. in CFB, the second block is
XOR'd with the previous ciphertext, reencrypted with the key, whereas in
OFB, the second block is XOR'd with that which the previous text was
previously XOR'd with.
Example code:
[2010-02-25 18:01:52] zelnaga at gmail dot com
Description:
Correct me if I'm wrong, but shouldn't an ECB decryption of an OFB
encrypted string of null bytes produce a string whose first eight bytes
(assuming that that's the block size) are equal to the IV? Certainly
that's the impression I get from wikipedia.org's discussion of OFB.
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Output_feedback_.28OFB.29
Reproduce code:
---
Expected result:
Actual result:
--
5%FBdq%C7Y7%13
--
Edit this bug report at http://bugs.php.net/?id=51146&edit=1
#45149 [Com]: Handling plus sign in an url failed
ID: 45149 Comment by: mat at ucsc dot edu Reported By: frode dot langvik at exense dot com Status: No Feedback Bug Type: Strings related Operating System: * PHP Version: 5.2.6 New Comment: We are seeing this issue with base64_encode and base64_decode. We have php 5.2.6 and the url string contains a '+' sign in the url parameter, however, in php itself if we $_GET the same parameter the + is replaced by a space. The base64_decode cannot use this value in php 5.2.6. However, 5.0.4 (my other running reference) base64_decode can read the blank. So the blank may be okay except that base64_decode seems to have changed in the newer version. Here is a test: The url parameter is (has +): YTozMDp7czo0OiJTVFJNIjtzOjQ6IjIxMDIiO3M6OToiQ0xBU1NfTkJSIjtzOjU6IjcyNTczIjtzOjEzOiJDTEFTU19TRUNUSU9OIjtzOjI6IjAxIjtzOjEzOiJDTEFTU19NVEdfTkJSIjtzOjE6IjEiO3M6MTI6IlNFU1NJT05fQ09ERSI7czoxOiIxIjtzOjEwOiJDTEFTU19TVEFUIjtzOjE6IkEiO3M6NzoiU1VCSkVDVCI7czo0OiJCSU9FIjtzOjExOiJDQVRBTE9HX05CUiI7czo0OiIgMTA3IjtzOjU6IkRFU0NSIjtzOjc6IkVjb2xvZ3kiO3M6MTM6IlNTUl9DT01QT05FTlQiO3M6MzoiTEVDIjtzOjEwOiJTVEFSVF9USU1FIjtzOjc6IjAyOjAwUE0iO3M6ODoiRU5EX1RJTUUiO3M6NzoiMDM6NDVQTSI7czo5OiJGQUNfREVTQ1IiO3M6MTQ6IkVpZ2h0IEFjYWQgMjQwIjtzOjM6Ik1PTiI7czoxOiJOIjtzOjQ6IlRVRVMiO3M6MToiWSI7czozOiJXRUQiO3M6MToiTiI7czo1OiJUSFVSUyI7czoxOiJZIjtzOjM6IkZSSSI7czoxOiJOIjtzOjM6IlNBVCI7czoxOiJOIjtzOjM6IlNVTiI7czoxOiJOIjtzOjk6IkVOUkxfU1RBVCI7czoxOiJPIjtzOjg6IldBSVRfVE9UIjtzOjE6IjAiO3M6ODoiRU5STF9DQVAiO3M6MjoiNzYiO3M6ODoiRU5STF9UT1QiO3M6MToiMCI7czo5OiJMQVNUX05BTUUiO3M6NToiTW9vcmUiO3M6MTA6IkZJUlNUX05BTUUiO3M6ODoiSm9uYXRoYW4iO3M6MTE6Ik1JRERMRV9OQU1FIjtzOjE6IlciO3M6MTY6IkNPTUJJTkVEX1NFQ1RJT04iO3M6MToiICI7czo1OiJUT1BJQyI7TjtzOjEyO! iJESVNQTEFZX05BTUUiO3M6MjQ6IkVzdGVzLEouQS48YnI+TW9vcmUsSi5XLiI7fQ== The $_GET value of this data dropps the + to look like this (in case text wrap breaks on my space it is a space at column 1036): YTozMDp7czo0OiJTVFJNIjtzOjQ6IjIxMDIiO3M6OToiQ0xBU1NfTkJSIjtzOjU6IjcyNTczIjtzOjEzOiJDTEFTU19TRUNUSU9OIjtzOjI6IjAxIjtzOjEzOiJDTEFTU19NVEdfTkJSIjtzOjE6IjEiO3M6MTI6IlNFU1NJT05fQ09ERSI7czoxOiIxIjtzOjEwOiJDTEFTU19TVEFUIjtzOjE6IkEiO3M6NzoiU1VCSkVDVCI7czo0OiJCSU9FIjtzOjExOiJDQVRBTE9HX05CUiI7czo0OiIgMTA3IjtzOjU6IkRFU0NSIjtzOjc6IkVjb2xvZ3kiO3M6MTM6IlNTUl9DT01QT05FTlQiO3M6MzoiTEVDIjtzOjEwOiJTVEFSVF9USU1FIjtzOjc6IjAyOjAwUE0iO3M6ODoiRU5EX1RJTUUiO3M6NzoiMDM6NDVQTSI7czo5OiJGQUNfREVTQ1IiO3M6MTQ6IkVpZ2h0IEFjYWQgMjQwIjtzOjM6Ik1PTiI7czoxOiJOIjtzOjQ6IlRVRVMiO3M6MToiWSI7czozOiJXRUQiO3M6MToiTiI7czo1OiJUSFVSUyI7czoxOiJZIjtzOjM6IkZSSSI7czoxOiJOIjtzOjM6IlNBVCI7czoxOiJOIjtzOjM6IlNVTiI7czoxOiJOIjtzOjk6IkVOUkxfU1RBVCI7czoxOiJPIjtzOjg6IldBSVRfVE9UIjtzOjE6IjAiO3M6ODoiRU5STF9DQVAiO3M6MjoiNzYiO3M6ODoiRU5STF9UT1QiO3M6MToiMCI7czo5OiJMQVNUX05BTUUiO3M6NToiTW9vcmUiO3M6MTA6IkZJUlNUX05BTUUiO3M6ODoiSm9uYXRoYW4iO3M6MTE6Ik1JRERMRV9OQU1FIjtzOjE6IlciO3M6MTY6IkNPTUJJTkVEX1NFQ1RJT04iO3M6MToiICI7czo1OiJUT1BJQyI7TjtzOjEyO! iJESVNQTEFZX05BTUUiO3M6MjQ6IkVzdGVzLEouQS48YnI TW9vcmUsSi5XLiI7fQ== Using a bit of php one can try the base64_decode on both strings. It will produce data with the +, but not with the space (5.2.6). Here is the test case code with a space (be careful text will line break on the space in some editors): After calling base64_decode ... "; echo ''; print_r($class_result); echo ''; $class_result = unserialize($class_result); echo "After unserialized ... "; echo ''; print_r($class_result); echo "Start print class_resul "; print_r($class_result); echo "*"; ?> Here is code with the + in the string: After calling base64_decode ... "; echo ''; print_r($class_result); echo ''; $class_result = unserialize($class_result); echo "After unserialized ... "; echo ''; print_r($class_result); echo "Start print class_resul "; print_r($class_result); echo "*"; ?> This will dump an array course data I generated. The only difference is the space or +. In 5.0.4 it works with a space. The space is not there in the URL in 5.2.6, but is after a $_GET on the parameter. Previous Comments: [2008-11-10 21:04:15] phpbugs at samrowe dot com I'm seeing this behavior on RHEL5's PHP-5.1.6-20.el5_2.1 when trying to use JSON data-structures containing strings that contain '+'. [2008-11-03 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-10-26 23:12:42] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/
#34972 [Com]: STDIN won't allow nonblocking.
ID: 34972
Comment by: joseph at none-yo-business dot com
Reported By: VJTD3 at VJTD3 dot com
Status: Assigned
Bug Type: Streams related
Operating System: win32 only
PHP Version: 5.2CVS-2008-07-15
Assigned To: pajoye
New Comment:
Hope this helps someone else, but the workaround I had to do was to
fread(stdin) from another script, output to a temp file, then use output
in my other script.
Yeah its ugly, but at least I have an interactive shell (or should that
be shells :)
Dear PHP developers. I love php. Its the glue that holds everything I
do together Please take this in the best way possible, WTF? This bug
should not be there... And 4 years after the fact?! Please help me love
PHP even more, and fix this bug.
Previous Comments:
[2009-11-14 15:31:44] raskin at aoeu dot ru
Confirmed on Nov 14th, 2009 with PHP 5.2.11 on WinXp
Yet no useful fix. Linux (Ubuntu 9.10 is just fine)
[2009-07-22 22:58:50] xektrum at gmail dot com
I can confirm this bug affects PHP 5.3.0. today at July 22 2009 almost
4 years from its submittion and still no fix.
This is very important since you can't create a really interactive CLI
application with this issue, and stops developers from choosing PHP to
theirs CLI/CMD/Console application (Although this could affect PHP-GTK
users and developers)
Hope this fix soon
Regards
[2009-04-16 17:48:36] frase at cs dot wisc dot edu
I'm having the same trouble.
With php-5.3.0-beta1 on Linux it works fine, both on STDIN and on
fopen('/dev/ttyS0'). stream_set_blocking() returns true,
stream_get_meta_data() confirms, and the stream behaves as if
non-blocking.
But with php-5.2.9 on Windows 2000 it doesn't work for either STDIN or
the serial port (COM1 instead of /dev/ttyS0). stream_set_blocking()
returns false, stream_get_meta_data() shows blocking, and the streams do
in fact block. I also tried stream_set_timeout() with a tiny value, to
simulate the effect, but that also returns false and doesn't work.
[2008-10-24 16:11:54] j...@php.net
Assigned to the windows port maintainer.
[2008-03-15 10:57:09] VJTD3 at VJTD3 dot com
on *nix it seems to be solved.
easy way to test:
php -r "stream_set_blocking(STDIN, FALSE);echo fread(STDIN, 10);"
on *nix it instantly exits. (correct behavior)
on windows it will hang for input. (incorrect behavior, it's ignoring
the non blocking setting.)
tested on 5.2.5
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
http://bugs.php.net/34972
--
Edit this bug report at http://bugs.php.net/?id=34972&edit=1
#50934 [Opn->Fbk]: UnexpectedValueException: RecursiveDirectoryIterator
ID: 50934
Updated by: ka...@php.net
Reported By: draeli at draeli dot com
-Status: Open
+Status: Feedback
Bug Type: SPL related
Operating System: win32 only - Windows
PHP Version: 5.3.1
New Comment:
Does this work in 5.2.x ?
Previous Comments:
[2010-02-04 21:52:44] draeli at draeli dot com
I use the latest (I have download, install and try before report).
[2010-02-04 20:37:05] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-02-04 19:30:05] draeli at draeli dot com
Description:
Under Windows (XP Sp3) I want to remove files and dir recursively.
When dir contain '-' (dash symbol), error message
"UnexpectedValueException:
RecursiveDirectoryIterator::__construct(E:\directoryTest\name - file)
[recursivedirectoryiterator.--construct]: failed to open dir: No such
file or directory in" is call and script is stop after loop
(consequently dir is really remove)
Reproduce code:
---
foreach (new \RecursiveIteratorIterator(new
\RecursiveDirectoryIterator('E:\directoryTest'),
\RecursiveIteratorIterator::SELF_FIRST) as $objCur) {
if ( $objCur->isDir() ){
rmdir($objCur->getPathname());
}else{
unlink($objCur->getPathname());
}
}
Expected result:
I try to remove file and dir recurvely since one dir.
Actual result:
--
Actual result is file are delete, dir too but script stop after loop if
current read dir contain dash symbol.
--
Edit this bug report at http://bugs.php.net/?id=50934&edit=1
#50777 [Com]: mysql_connect timeout / server reset
ID: 50777
Comment by: reddy1042001 at yahoo dot co dot in
Reported By: magikman74 at gmail dot com
Status: Open
Bug Type: MySQL related
Operating System: win32 only - Windows 7
PHP Version: 5.3.1
New Comment:
I dont See any Error .iam able to connect succesfully to the localhost
and able to see the results.
reproduce code
---
\n";
while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
echo "\t\n";
foreach ($line as $col_value) {
echo "\t\t$col_value\n";
}
echo "\t\n";
}
echo "\n";
// Free resultset
mysql_free_result($result);
// Closing connection
mysql_close($link);
?>
Actual output
-
t1 10
t2 20
t3 30
Expected output
---
t1 10
t2 20
t3 30
Previous Comments:
[2010-01-16 08:37:09] magikman74 at gmail dot com
Description:
I get the "The connection to the server was reset while the page was
loading." error everytime I try to connect to mysql using Windows7. Just
so you know I'm using the 32 bit version.
I've tried using both localhost and 127.0.0.1 to no avail. I've tried
creating a user on mysql and I've tried using root as well, both
failed.
It looks like the same issue as reported here:
http://www.mail-archive.com/php-bugs@lists.php.net/msg131577.html
Unfortunately I'm unable to get it working.
Reproduce code:
---
The code located here reproduces the problem:
http://sg.php.net/manual/en/mysql.examples-basic.php
--
Edit this bug report at http://bugs.php.net/?id=50777&edit=1
#51023 [Com]: ext/filter/tests/046.phpt fails, does not detect int overflow (with -O2 gcc 4.4)
ID: 51023
Comment by: seanius at debian dot org
Reported By: geissert at debian dot org
Status: Open
Bug Type: Filter related
Operating System: *
PHP Version: 5.3SVN-2010-02-12
New Comment:
Here's the patch i've cobbled together. in case it doesn't cut/paste
okay, it's also available at:
http://git.debian.org/?p=pkg-php/php.git;a=commitdiff;h=3061d111de130df7388cc78e26b63cc105574775
From: Sean Finney
Subject: Fix improper signed overflow detection in filter extension
The existing filter code relied on detecting invalid long integers by
examining computed values for wraparound. This is not defined
behavior
in any C standard, and in fact recent versions of gcc will optimize
out
such checks resulting in invalid code.
This patch therefore changes how the overflow/underflow conditions are
detected, using more reliable arithmetic. It also fixes another bug,
that
the minimum integer value (-PHP_INT_MAX)-1 could not be detected
properly.
This patch also includes an update to the test case that detects such
overflows, adding much more thorough and descriptive checking.
Bug: http://bugs.php.net/bug.php?id=51023
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570287
--- php.orig/ext/filter/logical_filters.c
+++ php/ext/filter/logical_filters.c
@@ -68,7 +68,7 @@
static int php_filter_parse_int(const char *str, unsigned int str_len,
long *ret TSRMLS_DC) { /* {{{ */
long ctx_value;
- int sign = 0;
+ int sign = 0, digit = 0;
const char *end = str + str_len;
switch (*str) {
@@ -82,7 +82,7 @@ static int php_filter_parse_int(const ch
/* must start with 1..9*/
if (str < end && *str >= '1' && *str <= '9') {
- ctx_value = ((*(str++)) - '0');
+ ctx_value = ((sign)?-1:1) * ((*(str++)) - '0');
} else {
return -1;
}
@@ -95,19 +95,18 @@ static int php_filter_parse_int(const ch
while (str < end) {
if (*str >= '0' && *str <= '9') {
- ctx_value = (ctx_value * 10) + (*(str++) - '0');
+ digit = (*(str++) - '0');
+ if ( (!sign) && ctx_value <= (LONG_MAX-digit)/10 ) {
+ ctx_value = (ctx_value * 10) + digit;
+ } else if ( sign && ctx_value >= (LONG_MIN+digit)/10) {
+ ctx_value = (ctx_value * 10) - digit;
+ } else {
+ return -1;
+ }
} else {
return -1;
}
}
- if (sign) {
- ctx_value = -ctx_value;
- if (ctx_value > 0) { /* overflow */
- return -1;
- }
- } else if (ctx_value < 0) { /* overflow */
- return -1;
- }
*ret = ctx_value;
return 1;
--- php.orig/ext/filter/tests/046.phpt
+++ php/ext/filter/tests/046.phpt
@@ -4,16 +4,46 @@ Integer overflow
--FILE--
---EXPECT--
-bool(true)
-bool(false)
-bool(true)
+--EXPECTF--
+max filtered: int(%d)
+max is_long: bool(true)
+max equal: bool(true)
+overflow filtered: bool(false)
+overflow is_long: bool(false)
+overflow equal: bool(false)
+min filtered: int(-%d)
+min is_long: bool(true)
+min equal: bool(true)
+underflow filtered: bool(false)
+underflow is_long: bool(false)
+underflow equal: bool(false)
Previous Comments:
[2010-02-23 13:04:48] j...@php.net
See also bug #51008
[2010-02-20 20:56:44] geiss...@php.net
Further investigation revealed that the bug occurs with gcc 4.4 and
optimisation -02. Without optimisation the code still works.
[2010-02-11 23:31:02] geissert at debian dot org
Description:
The filter fails to detect an integer overflow and passes the
FILTER_VALIDATE_INT test. The problem is caused because
php_filter_parse_int uses a long to detect the overflow, which of course
doesn't have the same size of an integer.
This can be fixed by making ctx_value an integer in both
php_filter_parse_int and php_filter_int (and for correctness, not
setting Z_TYPE_P(value) to IS_LONG).
Reproduce code:
---
// the current test:
$s = sprintf("%d", PHP_INT_MAX);
var_dump(is_long(filter_var($s, FILTER_VALIDATE_INT)));
$s = sprintf("%.0f", PHP_INT_MAX+1);
var_dump(filter_var($s, FILTER_VALIDATE_INT));
$s = sprintf("%d", -PHP_INT_MAX);
var_dump(is_long(filter_var($s, FILTER_VALIDATE_INT)));
Expected result:
bool(true)
bool(false)
bool(true)
Actual result:
--
bool(true)
int(-2147483648)
bool(true)
--
Edit this bug report at http://bug
#51150 [NEW]: spl_autoload_extensions() should accept arrays to avoid invalid separators
From: jo at feuersee dot de
Operating system: Any
PHP version: 5.3.1
PHP Bug Type: SPL related
Bug description: spl_autoload_extensions() should accept arrays to avoid
invalid separators
Description:
spl_autoload_extensions() accepts a string with a , separated list of
filename parts to register for autoloading.
This results in filenames containing a , as an extension filename
become impossible to register.
It should be possible to pass an array to circumvent any restriction
cased by the string based argument.
I know that ppl might consider it strange to use , as part of a
filename.
IMHO there may be cases where it might be necessary. Considering that
arrays are a native PHP data type, it would be a better design.
Reproduce code:
---
spl_autoload_extensions(array('.class.php', '.php'));
myclass::hello();
Expected result:
Hello world
Actual result:
--
Warning: spl_autoload_extensions() expects parameter 1 to be string,
array given in [test.php] on line ##
Fatal error: Class 'myclass' not found in [test.php] on line ##
--
Edit bug report at http://bugs.php.net/?id=51150&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51150&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51150&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51150&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51150&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51150&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51150&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51150&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51150&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51150&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51150&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51150&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51150&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51150&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51150&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51150&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51150&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51150&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51150&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51150&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51150&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51150&r=mysqlcfg
#49267 [Com]: Linking fails for iconv: "Undefined symbols: _libiconv"
ID: 49267 Comment by: scruffylion at gmail dot com Reported By: s dot rost at ewerk dot com Status: No Feedback Bug Type: Compile Failure Operating System: Mac OSX 10.6 Snow Leopard PHP Version: 5.3, 6 (2009-08-18) Assigned To: scottmac New Comment: Hi, I finally got it to work in multiple versions of PHP after alot of headbanging. I'm running snow leopard that was an upgrade and not a fresh install. I did NOT apply the iconv patch to any of the versions I tried this on. Also, specific to the compile of PHP, I ran everything literally as root. Not all steps are necessary I'm sure, but here's what I did: 1) Forcibly removed and reinstalled macports (had multiple versions of iconv after the upgrade to snow leopard, one de-activated, but this may not have done anything with regard to actually solving the iconv issue). 2) Compile iconv as static with configuration as follows: ./configure prefix=/usr/local enable-static (I used my own compilations of things such as iconv, mcrypt, ligjpeg, etc... all in /usr/local) 3) Configured PHP with iconv directive, and extra LIBS: env LIBS="-lresolv -liconv" ./configure --prefix=/usr/local/php \ --with-config-file-path=/usr/local/etc \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-openssl=shared,/opt/local \ --enable-cli \ --enable-mbstring \ --enable-exif \ --enable-sockets \ --with-mcrypt \ --with-zlib \ --with-zlib-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-freetype-dir=/usr/local \ --with-mysql=/usr/local/mysql \ --with-mysql-sock=/var/mysql/mysql.sock \ --enable-zip \ --with-iconv=/usr/local \ --with-curl 4) Edited the Makefile prior to compilation and changed the location of $(MH_BUNDLE_FLAGS) when called by the compiler. Changed this line: $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@ libs/libphp$(PHP_MAJOR_VERSION).so To: $(CC) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) $(MH_BUNDLE_FLAGS) -o $@ && cp $@ libs/libphp$(PHP_MAJOR_VERSION).so 5) Ran make. Finally, I got this to work with PHP versions: php-5.2.12 php-5.3.1 php5.3-201002242130 Final note: for php-5.2.12 and php-5.3.1 I actually messed up my mysql.sock location and decided to recompile php, and it failed on the first attempt. I then ran a "make clean", and re-configured and compiled and it workd on the second attempt. Frankly, I don't know why. But if it works for you then great! Previous Comments: [2010-02-16 00:21:24] lperry65 at gmail dot com I just tried to install 5.3.1 on os x 10.6.2 and had the following error: Undefined symbols: "_libiconv", referenced from: etc etc. Is this issue going to fixed anytime soon ? [2010-02-11 10:14:06] sj at sjaensch dot org The problem seems to be related to MacPorts, which often installs its own version of libiconv as dependency for several other ports. In my case, I'm using the MacPorts libpng, jpeg and freetype ports to compile PHP. Even though I specified --with-iconv-dir=/usr, it seems that the version in /opt/local gets picked up at the linking stage. The reason is that the linker command includes -L/opt/local/lib and -Wl,- rpath,/opt/local/lib. [2010-01-28 23:24:00] yux87 at hotmail dot com Okay, here's the result how I made it work against my environment and php version after a few times of failure in compiling: -- Steps -- 1. The only thing I tried to make it work was to hack the iconv.c as the patch above. ie. manually remove the #ifdef HAVE_LIBICONV, etc. lines. 2. Do a re-configure, re-make. - Result - ./configure --with-iconv-dir=/usr [Pass] ./make [Pass] ./make test [Okay, didn't notice any fail with iconv, not sure it's been tested though] -- Configuration -- Snow Leopard, with XCode. I did a fresh install rather than upgrade from the old 10.5 version, so I guess it could be the reason I didn't suffer the multiple iconv lib problem as some descriptions above. PHP version: 5.3.1 - 19 Nov 2009 release from the download page So I think the problem here is just some need to change the iconv.c code a bit. Hope this works for you, too. I also tried compiling with my macport iconv library(coz this'd be the actual one I'm going to use), there's no problem working with it too. [2010-01-03 11:48:35] iongion at yahoo dot com My system is a SNOW LEOPARD 10.6.2 I think we have a final solution. All these problems are generated becau
#51148 [Opn->Bgs]: preg_match doesn't work...le't post an example
ID: 51148
Updated by: ras...@php.net
Reported By: fabriziodimeo at alice dot it
-Status: Open
+Status: Bogus
Bug Type: *Regular Expressions
Operating System: windows and linux
PHP Version: 5.3.1
New Comment:
There is no bug here. The first example just looks for any character
anywhere in the string. You would need to change it to:
$pattern="/^[A-Za-z0-9]$/";
to get the result you want. Same goes for the second example. Your
ereg and preg regular expressions are not the same. Your preg one is
not anchored the same way your ereg one is. Make it the same and you
get the same results:
if (preg_match("/^[a-zA-Z0-9]+$/",$str))
Previous Comments:
[2010-02-25 19:14:12] alessandro dot romani at vivanet dot it
I tested the two functions (preg_match and ereg) and this is the
result:
";
}
else
{
echo "not ok";
}
}
function test2($str)
{
if (ereg("^[a-zA-Z0-9]+$",$str))
{
echo "it's ok";
}
else
{
echo "not ok";
}
}
echo "PREG_MATCH";
test("iao");
test("$iao");
test("iao!");
test("123!");
test("123");
echo "";
echo "EREG";
test2("iao");
test2("$iao");
test2("iao!");
test2("123!");
test2("123");
?>
The result is:
PREG_MATCH
not ok
not ok
not ok
not ok
not ok
EREG
it's ok
not ok
not ok
not ok
it's ok
[2010-02-25 18:56:50] fabriziodimeo at alice dot it
Description:
preg_match do not match correctly.
Reproduce code:
---
Expected result:
ok
hacking
Actual result:
--
ok
ok
--
Edit this bug report at http://bugs.php.net/?id=51148&edit=1
#50981 [NoF->Opn]: CachingIterator::hasNext() does not return correct value in some cases
ID: 50981
User updated by: clarity1285 at gmail dot com
Reported By: clarity1285 at gmail dot com
-Status: No Feedback
+Status: Open
Bug Type: SPL related
Operating System: Mac OS X
PHP Version: 5.3.1
New Comment:
I provided the feedback in my earlier comment. Reopening.
Previous Comments:
[2010-02-20 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2010-02-12 18:49:14] clarity1285 at gmail dot com
Tested with PHP 5.3.3-dev snapshot provided, and the issue is still
reproducible.
[2010-02-12 17:23:50] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-02-12 17:04:55] aleksey dot v dot korzun at gmail dot com
I'm experiencing the same issue.
[2010-02-09 23:05:48] clarity1285 at gmail dot com
Description:
When there are 11 total items and you use a LimitIterator to get the
first 10, CachingIterator::hasNext() returns false even though there
are
more than 10 items in the initial set.
If there are 12 total items it works as expected.
Reproduce code:
---
$items = new ArrayObject(range(1,11));
echo 'there are ' . $items->count() . ' total items' . "\r\n";
$cachingIterator = new CachingIterator($items->getIterator());
$limitIterator = new LimitIterator($cachingIterator, 0, 10);
$i = 0;
foreach ($limitIterator as $item) {
++$i;
}
echo 'first page has ' . $i . ' items' . "\r\n";
if ($cachingIterator->hasNext()) {
echo 'there is a next page';
} else {
echo 'there is no next page';
}
Expected result:
The code should output:
there are 11 total items
first page has 10 items
there is a next page
Actual result:
--
The code outputs:
there are 11 total items
first page has 10 items
there is no next page
--
Edit this bug report at http://bugs.php.net/?id=50981&edit=1
#51146 [Opn->Fbk]: mcrypt doesn't do OFB mode correctly
ID: 51146 Updated by: paj...@php.net Reported By: zelnaga at gmail dot com -Status: Open +Status: Feedback Bug Type: mcrypt related Operating System: Windows XP PHP Version: 5.3.1 New Comment: It looks like a libmcrypt problem, if it is a bug. Can you try using the mcrypt cmd line tools? If it fails and you see it as a bug, please report a bug to the mcrypt project. Let us know how it went. Previous Comments: [2010-02-25 18:18:35] zelnaga at gmail dot com mcrypt also seems to be implementing OFB and CFB modes identically. Although the first block produced by either mode should be the same, subsequent blocks should be different. ie. in CFB, the second block is XOR'd with the previous ciphertext, reencrypted with the key, whereas in OFB, the second block is XOR'd with that which the previous text was previously XOR'd with. Example code: [2010-02-25 18:01:52] zelnaga at gmail dot com Description: Correct me if I'm wrong, but shouldn't an ECB decryption of an OFB encrypted string of null bytes produce a string whose first eight bytes (assuming that that's the block size) are equal to the IV? Certainly that's the impression I get from wikipedia.org's discussion of OFB. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Output_feedback_.28OFB.29 Reproduce code: --- Expected result: Actual result: -- 5%FBdq%C7Y7%13 -- Edit this bug report at http://bugs.php.net/?id=51146&edit=1
#51148 [Com]: preg_match doesn't work...le't post an example
ID: 51148
Comment by: alessandro dot romani at vivanet dot it
Reported By: fabriziodimeo at alice dot it
Status: Open
Bug Type: *Regular Expressions
Operating System: windows and linux
PHP Version: 5.3.1
New Comment:
I tested the two functions (preg_match and ereg) and this is the
result:
";
}
else
{
echo "not ok";
}
}
function test2($str)
{
if (ereg("^[a-zA-Z0-9]+$",$str))
{
echo "it's ok";
}
else
{
echo "not ok";
}
}
echo "PREG_MATCH";
test("iao");
test("$iao");
test("iao!");
test("123!");
test("123");
echo "";
echo "EREG";
test2("iao");
test2("$iao");
test2("iao!");
test2("123!");
test2("123");
?>
The result is:
PREG_MATCH
not ok
not ok
not ok
not ok
not ok
EREG
it's ok
not ok
not ok
not ok
it's ok
Previous Comments:
[2010-02-25 18:56:50] fabriziodimeo at alice dot it
Description:
preg_match do not match correctly.
Reproduce code:
---
Expected result:
ok
hacking
Actual result:
--
ok
ok
--
Edit this bug report at http://bugs.php.net/?id=51148&edit=1
#51147 [NEW]: mysql_connect can't resolve hostname within apache module
From: kugel at rci dot rutgers dot edu Operating system: PHP version: 5.2.12 PHP Bug Type: Feature/Change Request Bug description: mysql_connect can't resolve hostname within apache module Description: When this is run from the command line: "php mytest.php" on the local machine, it connects successfully to the remote database. When it's run as a webpage, it dies with the mysql_error message of "Unknown MySQL server host 'mysql.vobj.org' (2)" Command line access "mysql -h mysql.vobj.org ..." works fine. If I substitute the IP address for the hostname, the webpage connects. NOTE: vobj.org is hosted by dreamhost, and while mysql.vobj.org maps to 67.205.28.132, 67.205.28.132 maps to thadison.masevo.dreamhost.com. Maybe there's some IP security check that causes failure without generating a useful error message. Fedora 11 host, Apache/2.2.13 (Fedora) Reproduce code: --- \n"; mysql_close($link); ?> Expected result: Code should say "successful connection\n" Actual result: -- Could not connect: MySQL server host 'mysql.vobj.org' (2) -- Edit bug report at http://bugs.php.net/?id=51147&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51147&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51147&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51147&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51147&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51147&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51147&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51147&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51147&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51147&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51147&r=support Expected behavior: http://bugs.php.net/fix.php?id=51147&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51147&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51147&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51147&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51147&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51147&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51147&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51147&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51147&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51147&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51147&r=mysqlcfg
#51146 [Opn]: mcrypt doesn't do OFB mode correctly
ID: 51146 User updated by: zelnaga at gmail dot com Reported By: zelnaga at gmail dot com Status: Open Bug Type: mcrypt related Operating System: Windows XP PHP Version: 5.3.1 New Comment: mcrypt also seems to be implementing OFB and CFB modes identically. Although the first block produced by either mode should be the same, subsequent blocks should be different. ie. in CFB, the second block is XOR'd with the previous ciphertext, reencrypted with the key, whereas in OFB, the second block is XOR'd with that which the previous text was previously XOR'd with. Example code: Previous Comments: [2010-02-25 18:01:52] zelnaga at gmail dot com Description: Correct me if I'm wrong, but shouldn't an ECB decryption of an OFB encrypted string of null bytes produce a string whose first eight bytes (assuming that that's the block size) are equal to the IV? Certainly that's the impression I get from wikipedia.org's discussion of OFB. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Output_feedback_.28OFB.29 Reproduce code: --- Expected result: Actual result: -- 5%FBdq%C7Y7%13 -- Edit this bug report at http://bugs.php.net/?id=51146&edit=1
#51148 [NEW]: preg_match doesn't work...le't post an example
From: fabriziodimeo at alice dot it Operating system: windows and linux PHP version: 5.3.1 PHP Bug Type: *Regular Expressions Bug description: preg_match doesn't work...le't post an example Description: preg_match do not match correctly. Reproduce code: --- Expected result: ok hacking Actual result: -- ok ok -- Edit bug report at http://bugs.php.net/?id=51148&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51148&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51148&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51148&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51148&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51148&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51148&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51148&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51148&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51148&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51148&r=support Expected behavior: http://bugs.php.net/fix.php?id=51148&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51148&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51148&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51148&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51148&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51148&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51148&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51148&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51148&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51148&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51148&r=mysqlcfg
#51146 [NEW]: mcrypt doesn't do OFB mode correctly
From: zelnaga at gmail dot com Operating system: Windows XP PHP version: 5.3.1 PHP Bug Type: mcrypt related Bug description: mcrypt doesn't do OFB mode correctly Description: Correct me if I'm wrong, but shouldn't an ECB decryption of an OFB encrypted string of null bytes produce a string whose first eight bytes (assuming that that's the block size) are equal to the IV? Certainly that's the impression I get from wikipedia.org's discussion of OFB. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Output_feedback_.28OFB.29 Reproduce code: --- Expected result: Actual result: -- 5%FBdq%C7Y7%13 -- Edit bug report at http://bugs.php.net/?id=51146&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51146&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51146&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51146&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51146&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51146&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51146&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51146&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51146&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51146&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51146&r=support Expected behavior: http://bugs.php.net/fix.php?id=51146&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51146&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51146&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51146&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51146&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51146&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51146&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51146&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51146&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51146&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51146&r=mysqlcfg
#40141 [NoF->Csd]: open_basedir vs. tmpfile()
ID: 40141 Updated by: paj...@php.net Reported By: flobee at gmail dot com -Status: No Feedback +Status: Closed Bug Type: *Directory/Filesystem functions Operating System: debian etch PHP Version: 5.2.0 New Comment: Fixed already in all releases. Previous Comments: [2010-02-25 01:51:34] sebastian at hometronix dot de I had the same problem a few days ago, but now it works fine. I just changed: php_admin_value open_basedir "/home/somthing/:/tmp/" --> php_admin_value open_basedir /home/somthing/:/tmp Try it! [2007-01-24 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-01-16 08:25:44] tony2...@php.net Make sure /tmp/ is not a symlink. [2007-01-16 01:13:59] flobee at gmail dot com Description: using php_admin_value open_basedir "/home/somthing/" in vhosts i get problems to run the function tmpfile() vhost setting: php_admin_value open_basedir "/home/somthing/:/tmp/" or tested with ... does the same error: php_admin_value open_basedir "/home/somthing/" without open_basedir the function works like expected :-/ Reproduce code: --- Actual result: -- Warning: tmpfile() [function.tmpfile]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/home/abc/:/tmp/) in index.php on line 123 -- Edit this bug report at http://bugs.php.net/?id=40141&edit=1
#51144 [NEW]: spl_autoload is broken
From: davi dot fol at gmail dot com
Operating system: Mac OSX 10.6
PHP version: 5.3.1
PHP Bug Type: Dynamic loading
Bug description: spl_autoload is broken
Description:
I am aware of spl_autoload_* issues that the development team do not
consider bugs, namely the requirement for class files to have
lowercase names in order for spl_autoload to function. (I would like
to think that moving forwards, we could supply a constant to
spl_register_autoload as a best compromise BC step to change this
behaviour to support PascalCase class names).
Anyhow, I've disabled all extensions, I believe I've exhausted all
configuration possibilities affecting spl_autoloads behaviour, and
it still does not work. Defining my own handler, does. It seems that
no matter how I define the include path, spl_autoload throws
LogicExceptions as it cannot find classes. I am hoping that its not
the case that as Mac OSX paths contain upper case folder names,
that the auto lowercasing behaviour of spl_autoload is affecting
absolute paths.
As a concrete case, this IS an include path that I use- it works with
include_once et al, supplying or omitting the trailing slash:
"/Users/davidfoley/Documents/Aptana Studio
Workspace/www.thorium.site/Private/Library/"
The above path is a perfectly valid file path- its somewhat different
in the sense that 'www.thorium.site' is plonked in the middle-
thats simply the name of a virtual hosts symlinked folder. I am only
guessing that this could be a possible reason why spl_autoload is
not working.
Reproduce code:
---
Assume a class file:
location:
www/Private/library/target.php
contents:
namespace library
{
class target
{
}
}
Assume a bootloader script
location:
www/Public/boot.php
contents:
define('BREAK', '');
set_include_path('absolute/path/to/www/Private/library);
spl_autoload_extensions('.php');
spl_autoload_register();
$classFile= new SplFileObject('library/target.php', true);
echo 'The class file exists: ' . ($classFile->isFile() ? 'true' : 'false')
. BREAK;
use library\target;
$instance= new target;
echo 'The class was loaded: ' . (isset($instance) ? 'true' : 'false') .
BREAK;
Expected result:
The following output:
The class file exists: true
The class was loaded: true
Actual result:
--
LogicException 'could not load class library\target'
--
Edit bug report at http://bugs.php.net/?id=51144&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51144&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51144&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51144&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51144&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51144&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51144&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51144&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51144&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51144&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51144&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51144&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51144&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51144&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51144&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51144&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51144&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51144&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51144&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51144&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51144&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51144&r=mysqlcfg
#51138 [Bgs]: Impossible to use "IN()"
ID: 51138
User updated by: fmaz008 at gmail dot com
Reported By: fmaz008 at gmail dot com
Status: Bogus
Bug Type: PDO related
Operating System: n/a
PHP Version: 5.2.12
New Comment:
This is still a major design flaw, and I'm far from beeing the only one
to ran into this problem (google a bit, you'll see)
Something should(must) be emulated.
I've also read the how to repport a bug, I can't figure out what you're
trying to tell me. And giving me a link to all the PHP manual is a bit
ridiculous.
Previous Comments:
[2010-02-25 07:41:27] johan...@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
Databases allow only to bind one value per placeholder. Nothing we can
change.
[2010-02-25 03:43:13] fmaz008 at gmail dot com
Description:
Using MySQL and InnoDB table, if you prepare this query:
SELECT * FROM foo WHERE id IN(:values);
You will be totally unable to use it, thoses solutions doesn't work:
$arr = array(1,2,3,4,5);
$prep->bindParam(':values', $arr, PDO::PARAM_STMT); //Invalid Array to
String conversion
or:
$arr = array(1,2,3,4,5);
$prep->bindParam(':values', implode(',', $arr), PDO::PARAM_STR);
//Seems to be interpreted as "1,2,3,4,5" instead of "1","2","3","4","5"
or plain integer values.
Actual work arround is to generate a string to inject in the query
string before preparing it. But it's not a good solution as I often need
to use prepared statement in loop. So if I must prepare and reprepare
and re-reprepare, that's not usefull.
A PDO::PARAM_RAWSTR or PDO::PARAM_UNPROTECTED_STR might be a quick &
good workarround to solve this problem until a better fix.
Reproduce code:
---
$arr = array(1,2,3,4,5);
$prep->prepare('SELECT * FROM foo WHERE id IN(:values);');
$prep->bindParam(':values', implode(',', $arr), PDO::PARAM_STMT);
$prep->execute();
Expected result:
SELECT * FROM foo WHERE id IN(1,2,3,4,5);
Actual result:
--
SELECT * FROM foo WHERE id IN("1,2,3,4,5");
--
Edit this bug report at http://bugs.php.net/?id=51138&edit=1
#51141 [NEW]: Add a deleteMin() method to SplMaxHeap
From: jeroen at jeroen-vandeven dot nl
Operating system:
PHP version: 5.3.1
PHP Bug Type: Feature/Change Request
Bug description: Add a deleteMin() method to SplMaxHeap
Description:
Add a deleteMin() method to SplMaxHeap (and/or a deleteMax() to
SplMinHeap) to limit the size of the heap without taking off the top
element.
Reproduce code:
---
$heap = new SplMaxHeap();
for ($i = 0; $i < 1; $i++) {
$heap.insert($arr[$i])
if ($heap.count() > 100) {
$heap.deleteMin();
}
}
Expected result:
The example is pretty useless, it will add 100 elements to the heap and
then add 9900 more, immediately removing each one.
This is useful in other situations where you may only be interested in
the top 100 sorted elements of 1 unsorted elements and don't want
the heap to grow excessively large.
Actual result:
--
There is no deleteMin() method in SplMaxHeap
--
Edit bug report at http://bugs.php.net/?id=51141&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51141&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51141&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51141&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51141&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51141&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51141&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51141&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51141&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51141&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51141&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51141&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51141&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51141&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51141&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51141&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51141&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51141&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51141&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51141&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51141&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51141&r=mysqlcfg
#51140 [Bgs]: No php5apache2_2.dll provided in zip download
ID: 51140 Updated by: paj...@php.net Reported By: tony at marston-home dot demon dot co dot uk Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.3.2RC3 New Comment: that's about php in general, not this specific build. Please read the PHP manual for further information. Previous Comments: [2010-02-25 10:45:54] tony at marston-home dot demon dot co dot uk So why do the installation instructions in the nts zip file still say that it can be used with apache? [2010-02-25 10:26:50] paj...@php.net Apache requires the thread safe version of PHP. [2010-02-25 10:20:35] tony at marston-home dot demon dot co dot uk Description: I am trying to install the non thread safe version of PHP (to run as an apache module with Apache 2.2) as Zend only supply the nts version of their debugger as of version 5.3. When I unzip the download file I notice that it does not include a version of the php5apache2_2.dll. If I try to use the ts version it rejects all the PHP extensions as they were compiled with the nts option. -- Edit this bug report at http://bugs.php.net/?id=51140&edit=1
#51140 [Bgs]: No php5apache2_2.dll provided in zip download
ID: 51140 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.3.2RC3 New Comment: So why do the installation instructions in the nts zip file still say that it can be used with apache? Previous Comments: [2010-02-25 10:26:50] paj...@php.net Apache requires the thread safe version of PHP. [2010-02-25 10:20:35] tony at marston-home dot demon dot co dot uk Description: I am trying to install the non thread safe version of PHP (to run as an apache module with Apache 2.2) as Zend only supply the nts version of their debugger as of version 5.3. When I unzip the download file I notice that it does not include a version of the php5apache2_2.dll. If I try to use the ts version it rejects all the PHP extensions as they were compiled with the nts option. -- Edit this bug report at http://bugs.php.net/?id=51140&edit=1
#51140 [Opn->Bgs]: No php5apache2_2.dll provided in zip download
ID: 51140 Updated by: paj...@php.net Reported By: tony at marston-home dot demon dot co dot uk -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.3.2RC3 New Comment: Apache requires the thread safe version of PHP. Previous Comments: [2010-02-25 10:20:35] tony at marston-home dot demon dot co dot uk Description: I am trying to install the non thread safe version of PHP (to run as an apache module with Apache 2.2) as Zend only supply the nts version of their debugger as of version 5.3. When I unzip the download file I notice that it does not include a version of the php5apache2_2.dll. If I try to use the ts version it rejects all the PHP extensions as they were compiled with the nts option. -- Edit this bug report at http://bugs.php.net/?id=51140&edit=1
#51140 [NEW]: No php5apache2_2.dll provided in zip download
From: tony at marston-home dot demon dot co dot uk Operating system: Windows XP PHP version: 5.3.2RC3 PHP Bug Type: Apache2 related Bug description: No php5apache2_2.dll provided in zip download Description: I am trying to install the non thread safe version of PHP (to run as an apache module with Apache 2.2) as Zend only supply the nts version of their debugger as of version 5.3. When I unzip the download file I notice that it does not include a version of the php5apache2_2.dll. If I try to use the ts version it rejects all the PHP extensions as they were compiled with the nts option. -- Edit bug report at http://bugs.php.net/?id=51140&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51140&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51140&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51140&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51140&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51140&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51140&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51140&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51140&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51140&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51140&r=support Expected behavior: http://bugs.php.net/fix.php?id=51140&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51140&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51140&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51140&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51140&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51140&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51140&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51140&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51140&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51140&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51140&r=mysqlcfg
#44300 [Com]: mssql_connect fails sometimes
ID: 44300
Comment by: healerx78 at yahoo dot com
Reported By: alfa77 at gmail dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 5.2.5
New Comment:
trials
Previous Comments:
[2010-01-19 08:41:40] t dot zander at tuneup dot de
We're experiencing the same problem with Microsofts SQLSRV driver.
So it might be it's not just a driver problem.
[2009-12-03 17:37:29] dbuerer at leviton dot com
I too have suffered this same problem for the last couple of years on
all of the 5.x release of PHP. It works great for days then has problem
for a few days then works great. 1-3 page reloads often solves the
problem but not always. Unfortunatley support for this extension has
been discontinued--I wonder if this is one of the reasons why? I would
like to try using Microsofts SQLSRV driver but converting an entire
website from mssql to sqlsrv is going to be a lot of work!
[2009-02-13 19:26:45] b116d at mail dot ru
Same problem here.
Apache 2.2.10
Php 5.2.5 as module.
OS win2003 sp1+all critical updates
I even try upgrade to php 5.2.8, but it still appears.
[2008-12-09 15:25:50] frosty dot z at freesbee dot fr
Hi, same problem detected here (connection "rarely" successful with
mssql_connect, with a MSSQL server under quite heavy load).
Happens only with PHP on Windows, not on Linux (FreeDTS).
But for some reason I needed to connect from PHP/Windows, so I have
used the "ADO workaround", as previously suggested by alfa77.
At first, I didn't understand very well that workaround, so here are
some details :
Do not use the ADOdb engine 'mssql' because it will still use
mssql_connect(). Instead, use 'ado_mssql' which uses COM objects ; that
makes all the difference.
Here is a basic database functions lib :
function db_open($db_host, $db_login, $db_pass, $db_name)
{
$db = NewADOConnection('ado_mssql');
$dsn="PROVIDER=MSDASQL;DRIVER={SQL Server};"
.
"SERVER=".$db_host.";DATABASE=".$db_name.";UID=".$db_login.";PWD=".$db_pass.";";
$db->Connect($dsn);
return $db;
}
function db_query($db, $query)
{
return $db->Execute($query);
}
function db_fetch_assoc($res)
{
$obj = $res->FetchNextObj();
return get_object_vars($obj);
}
function db_close($db)
{
$db->Close();
}
[2008-09-26 11:53:35] yusefhassan at gmail dot com
Have you try editing php.ini mssql.max_procs?
mssql.max_procs = -1
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
http://bugs.php.net/44300
--
Edit this bug report at http://bugs.php.net/?id=44300&edit=1
