#39877 [Opn->Bgs]: Unable to load dynamic library
ID: 39877 Updated by: [EMAIL PROTECTED] Reported By: rob4you at vodafone dot it -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: Windows XP PHP Version: 5.2.0 New Comment: This is not a bug in php. Your php folder (C:\Programs\PHP) needs to be included in PATH. After modifying path you need to restart your machine for the changes to take effect for all services. Previous Comments: [2006-12-18 22:12:21] rob4you at vodafone dot it Sorry, the last three libraries were not in the extension directory. So the problem is resolved. So the way to make working extensions which require other .dll is to copy the last in the c:\windows\system32 (or setting up an environment variable)? This solutions however is not so good when having multiple PHP version installed on different webserver on the same machine. [2006-12-18 21:58:42] rob4you at vodafone dot it After try & errors i've observed that I need to copy some dll in the C:\Windows\system32. But the problem still persists with just three library: php_pdf.dll php_pop3.dll php_smtp.dll How can I make them working? [2006-12-18 21:26:25] rob4you at vodafone dot it Description: PHP 5.2.0 installed as Apache module (apache version 2.2.3) on Windows XP. I've also tried with PHP 5.2.1RC2-dev, PHP 5.1.2. I've used also Apache 2.0.x as webserver. The php.ini is correctly configured with the wanted extensions (extension=php_name.dll) and the right extensions_dir. The Apache server is correctly configured with the PHPIniDir and LoadModule directive. The problem is the following: when the server starts, SOME extensions are not loaded, and the following warning is produced (as an example): PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Programs\\PHP\\ext\\php_curl.dll' - Impossible to locate specified module.\r\n in Unknown on line 0 The extension is instead correctly placed in the right directory. It's quite strange that some extensions are loaded, some other are not loaded, but they are all in the SAME directory! ps: i've not used environment variable because in the manual it says it not necessary when using php as apache module. If I set instead the environment variable Path C:\Programs\PHP it works. However the behaviour for the problem previously exposed is unexpected: some extensions are correctly loaded, others no. -- Edit this bug report at http://bugs.php.net/?id=39877&edit=1
#39878 [Bgs->Opn]: CURL doesn't compile on Sun Studio Pro
ID: 39878 User updated by: leozh at nbcs dot rutgers dot edu Reported By: leozh at nbcs dot rutgers dot edu -Status: Bogus +Status: Open Bug Type: cURL related Operating System: Solaris 9 -PHP Version: 5.2.0 +PHP Version: 5.2.1RC1 New Comment: I have tried to compile 5.2.1RC1 and this is what I get: /bin/sh /usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/libtool --silent --preserve-dup-deps --mode=compile /opt/SUNWspro/bin/cc -Iext/curl/ -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/ -DPHP_ATOM_INC -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/include -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/main -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1 -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/date/lib -I/usr/local/include/freetype2 -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/imap-2004g/c-client/include -I//usr/local/mysql5/include/mysql -I/usr/local/mysql-5.0.27/include/mysql -I/usr/local/include/pspell -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/TSRM -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/Zend -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -mt -g -xs -c /usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c -o ext/curl/interface.lo /bin/sh /usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/libtool --silent --preserve-dup-deps --mode=compile /opt/SUNWspro/bin/cc -Iext/curl/ -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/ -DPHP_ATOM_INC -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/include -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/main -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1 -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/date/lib -I/usr/local/include/freetype2 -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/imap-2004g/c-client/include -I//usr/local/mysql5/include/mysql -I/usr/local/mysql-5.0.27/include/mysql -I/usr/local/include/pspell -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/TSRM -I/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/Zend -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -mt -g -xs -c /usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/multi.c -o ext/curl/multi.lo "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c", line 1464: warning: enum type mismatch: op "=" "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c", line 1471: warning: enum type mismatch: op "=" "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c", line 1622: warning: argument #3 is incompatible with prototype: prototype: pointer to unsigned int : "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/Zend/zend_hash.h", line 172 argument : pointer to int "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c", line 1622: warning: argument #4 is incompatible with prototype: prototype: pointer to unsigned long : "/usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/Zend/zend_hash.h", line 172 argument : pointer to long cc: acomp failed for /usr/local/src/rpm-packages/BUILD/php-5.2.1RC1/ext/curl/interface.c It still doesn't like the voids returning values. Previous Comments: [2006-12-18 23:37:52] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. It should be fixed already, please reopen if you can reproduce this with 5.2.1RC1 or the latest snap (http://snaps.php.net) [2006-12-18 21:53:17] leozh at nbcs dot rutgers dot edu Ignore the error on line 1071 though, that is from me putting a void in front of the function declaration, but the error that caused the compile to fail was the one on line 1084. [2006-12-18 21:28:43] leozh at nbcs dot rutgers dot edu Description: I tried to compile PHP 5.1.6 on my Solaris 9 box with Sun Studio Pro. cURL did not compile because it used deprecated
#39878 [Opn->Bgs]: CURL doesn't compile on Sun Studio Pro
ID: 39878 Updated by: [EMAIL PROTECTED] Reported By: leozh at nbcs dot rutgers dot edu -Status: Open +Status: Bogus Bug Type: cURL related Operating System: Solaris 9 PHP Version: 5.2.0 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. It should be fixed already, please reopen if you can reproduce this with 5.2.1RC1 or the latest snap (http://snaps.php.net) Previous Comments: [2006-12-18 21:53:17] leozh at nbcs dot rutgers dot edu Ignore the error on line 1071 though, that is from me putting a void in front of the function declaration, but the error that caused the compile to fail was the one on line 1084. [2006-12-18 21:28:43] leozh at nbcs dot rutgers dot edu Description: I tried to compile PHP 5.1.6 on my Solaris 9 box with Sun Studio Pro. cURL did not compile because it used deprecated cURL functions that did not exist in cURL 7.16. I then took the curl extension from the current 5.2 cvs and put it in the 5.1.6 source tree. Actual result: -- This is what happens: Sun Studio Pro does not like void functions returning values /bin/sh /usr/local/src/rpm-packages/BUILD/php-5.1.6/libtool --silent --preserve-dup-deps --mode=compile /opt/SUNWspro/bin/cc -Iext/curl/ -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/ -DPHP_ATOM_INC -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/include -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/main -I/usr/local/src/rpm-packages/BUILD/php-5.1.6 -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/date/lib -I/usr/local/include/freetype2 -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/imap-2004g/c-client/include -I//usr/local/mysql5/include/mysql -I/usr/local/mysql-5.0.27/include/mysql -I/usr/local/include/pspell -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/TSRM -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -mt -g -xs -c /usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c -o ext/curl/interface.lo "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1071: invalid type combination "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1464: warning: enum type mismatch: op "=" "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1471: warning: enum type mismatch: op "=" "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1622: warning: argument #3 is incompatible with prototype: prototype: pointer to unsigned int : "/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend/zend_hash.h", line 172 argument : pointer to int "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1622: warning: argument #4 is incompatible with prototype: prototype: pointer to unsigned long : "/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend/zend_hash.h", line 172 argument : pointer to long cc: acomp failed for /usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c *** Error code 1 make: Fatal error: Command failed for target `ext/curl/interface.lo' -- Edit this bug report at http://bugs.php.net/?id=39878&edit=1
#39880 [NEW]: imap_open('/localfile') fails
From: ceo at l-i-e dot com
Operating system: Windows
PHP version: 5.2.0
PHP Bug Type: IMAP related
Bug description: imap_open('/localfile') fails
Description:
imap_open('/localfile', '', '')
fails on Windows, but works on Linux.
I get this in the error log for Windows:
[Mon Dec 18 16:18:56 2006] [error] [client 127.0.0.1] PHP Warning:
imap_open() [function.i
map-open]: Couldn't open stream
C:/www/complaints.com/data/testdos.mbox in
C:\\www\\complaints.com\\imap_bug.php on
line 9
[Mon Dec 18 16:18:56 2006] [error] [client 127.0.0.1] PHP Notice:
Unknown: Can't open mailbox C:/www/complaints.com/dat
a/testdos.mbox: no such mailbox (errflg=2) in Unknown on line 0
Note that it's neither a path nor permissions problem, as fopen(..., 'r')
and fgets() succeed.
Also note that it is not a cr/lf problem as the testunix.mbox and
testdos.mbox files are identical except for ^M at the ends.
Linux happily works with either line-ending.
Windows just plain doesn't work.
The Linux box is running 5.1.4, while the Windows is running 5.2.0, so it
*could* be a change from 5.1.4 to 5.2.0
Reproduce code:
---
http://acousticdemo.com/complaints/imap_bug.phps
Expected result:
Linux Output:
http://acousticdemo.com/complaints/imap_bug.php
Actual result:
--
Line 1 of testdos.mbox: From "Richard Lynch" Fri Dec 15 17:13:48 2006
Line 1 of testunix.mbox: From "Richard Lynch" Fri Dec 15 17:13:48 2006
Failed to imap_open(C:/www/complaints.com/data/testdos.mbox)
array(1) {
[0]=>
string(75) "Can't open mailbox C:/www/complaints.com/data/testdos.mbox:
no such mailbox"
}
bool(false)
messages in C:/www/complaints.com/data/testdos.mbox:
bool(false)
bool(false)
Failed to imap_open(C:/www/complaints.com/data/testunix.mbox)
bool(false)
array(1) {
[0]=>
string(76) "Can't open mailbox C:/www/complaints.com/data/testunix.mbox:
no such mailbox"
}
messages in C:/www/complaints.com/data/testunix.mbox:
--
Edit bug report at http://bugs.php.net/?id=39880&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39880&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39880&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39880&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39880&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39880&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39880&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39880&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39880&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39880&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39880&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39880&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39880&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39880&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39880&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39880&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39880&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39880&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39880&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39880&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39880&r=mysqlcfg
#39877 [Opn]: Unable to load dynamic library
ID: 39877 User updated by: rob4you at vodafone dot it Reported By: rob4you at vodafone dot it Status: Open Bug Type: Dynamic loading Operating System: Windows XP PHP Version: 5.2.0 New Comment: Sorry, the last three libraries were not in the extension directory. So the problem is resolved. So the way to make working extensions which require other .dll is to copy the last in the c:\windows\system32 (or setting up an environment variable)? This solutions however is not so good when having multiple PHP version installed on different webserver on the same machine. Previous Comments: [2006-12-18 21:58:42] rob4you at vodafone dot it After try & errors i've observed that I need to copy some dll in the C:\Windows\system32. But the problem still persists with just three library: php_pdf.dll php_pop3.dll php_smtp.dll How can I make them working? [2006-12-18 21:26:25] rob4you at vodafone dot it Description: PHP 5.2.0 installed as Apache module (apache version 2.2.3) on Windows XP. I've also tried with PHP 5.2.1RC2-dev, PHP 5.1.2. I've used also Apache 2.0.x as webserver. The php.ini is correctly configured with the wanted extensions (extension=php_name.dll) and the right extensions_dir. The Apache server is correctly configured with the PHPIniDir and LoadModule directive. The problem is the following: when the server starts, SOME extensions are not loaded, and the following warning is produced (as an example): PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Programs\\PHP\\ext\\php_curl.dll' - Impossible to locate specified module.\r\n in Unknown on line 0 The extension is instead correctly placed in the right directory. It's quite strange that some extensions are loaded, some other are not loaded, but they are all in the SAME directory! ps: i've not used environment variable because in the manual it says it not necessary when using php as apache module. If I set instead the environment variable Path C:\Programs\PHP it works. However the behaviour for the problem previously exposed is unexpected: some extensions are correctly loaded, others no. -- Edit this bug report at http://bugs.php.net/?id=39877&edit=1
#39809 [Fbk->Opn]: FastCGI Requests silently dropped
ID: 39809
User updated by: e at osterman dot com
Reported By: e at osterman dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: FC6
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
By changing the example code to use PHP's sockets (e.g.
socket_create/connect/read/write) allows one to use the socket_shutdown
as you suggested. But calling shutdown after the request defeats the
purpose of persistent connections, since that just negates the effect
of passing FCGI_KEEP_CONN. Connections cannot be reused to send
requests once they're shutdown after a request.
So, it sounds like PHP's design decision is to support PHP_KEEP_CONN,
but when PHP_FCGI_CHILDREN is reached, all new connections are
queued/blocked. When a client releases its connection to a php-cgi
child process, then the next connection in the queue is handed over to
the next available child. While this makes a lot of sense when you're
dealing with only non-persistent connections or only a single php-cgi
server, it's not desireable when you have lots of persistent
connections or lots of fcgi servers. For example, in HTTP/1.1, servers
respond "503 Server too busy". If the client were notified in some way,
either by way of a closed connection, refused connection, or
FCGI_OVERLOADED packet, then the client could try another FCGI server.
But since that doesn't happen, the client must just sit and wait.
Perhaps, indefinitely or just timeout =(
What is your take on this?
Best Regards,
Erik Osterman
Previous Comments:
[2006-12-18 18:53:58] [EMAIL PROTECTED]
> $socket1 = FCGI_Connect('localhost', 1234);
> FCGI_Test($socket1);
> FCGI_Response($socket1);
> sleep(30);
> fclose($socket1);
> ?>
this code is not perferct, and this is the reason of bad behavior. You
should call shutdown() "man 2 shutdown" after writing request into
socket, but PHP doesn't implement such function.
I cannot repeat your behavior with telnet. I always get "Connection
closed" after a timeout.
BTW you can insert debug output into fastcgi.c right after accept() and
try it.
[2006-12-18 18:29:13] e at osterman dot com
For what it's worth, this shows some conflicting data. Perhaps I'm just
interpretting it wrong.
Start theh FCGI server in single process mode
# php-cgi -b 1234
Modify the test script as follows:
Now, the single process php-cgi server should not be accept()ing any
more connections for 30 seconds.
# telnet localhost 1234
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
Per my previous post, when a stream_socket_server server does not call
accept(), the 'telnet' session gets "connection refused". In this
example, it's not getting refused by the php-cgi server, which leads me
to believe that php-cgi might actually be calling accept. This could be
a implementation difference.. but I don't know.
Regards,
Erik Osterman
[2006-12-18 18:20:11] e at osterman dot com
Dimitry,
You're example shocked me. I tried something similar making a simple
stream_socket_server, but didn't make the client in PHP.
# telnet localhost 1234
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
I had expected the same behavior in PHP's fsockopen, but indeed, as you
said fsocketopen returns a valid resource even though the connection has
not yet been accept()'d by the server. More over, feof returns false and
fwrite to the socket returns the correct number of bytes "written".
stream_get_metadata returns nothing interesting either.
How is a PHP fsockopen/stream_socket_client client to know when a
connection truely has been accept()'d?
The reason why this is all so important to us, is that we have a
cluster of frontend servers that use a pool of FCGI backend servers. We
need the busier frontend servers to dynamically open up more persistent
connections (FCGI_KEEP_CONN) to FCGI servers (and release them as
demand subsides). When a particular FCGI server is at capacity
(PHP_FCGI_CHILDREN), we need the client to try (in a round robin
fashion) another FCGI server. The current problem, as you understand by
now, is that the client get's stuck when connecting to an FCGI server at
capacity and timeout.
As you've now suggested, it's apparently b/c they getting stuck waiting
for the accept(), but never get it.
What recourse does the client have?
Regards,
Erik Osterman
[2006-12-18 13:15:46] [EMAIL PROTECTED]
No you are :)
But you made a great job writting test script, and I think this
discussion may lead us to some good result.
The fact that connect() returns file descriptor doesn't mean that
accept() was really called. See the folllow
#39879 [NEW]: strval not optimized
From: roberto at spadim dot com dot br Operating system: ALL PHP version: 5.2.0 PHP Bug Type: Performance problem Bug description: strval not optimized Description: maybe strval isn't otimized see reproduce code Reproduce code: --- Expected result: expect to result 2 be small than result 1 Actual result: -- result 1 is bigger than 2 -- Edit bug report at http://bugs.php.net/?id=39879&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39879&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39879&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39879&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39879&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39879&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39879&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39879&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39879&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39879&r=support Expected behavior:http://bugs.php.net/fix.php?id=39879&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39879&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39879&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39879&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39879&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39879&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39879&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39879&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39879&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39879&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39879&r=mysqlcfg
#39877 [Opn]: Unable to load dynamic library
ID: 39877 User updated by: rob4you at vodafone dot it Reported By: rob4you at vodafone dot it Status: Open Bug Type: Dynamic loading Operating System: Windows XP PHP Version: 5.2.0 New Comment: After try & errors i've observed that I need to copy some dll in the C:\Windows\system32. But the problem still persists with just three library: php_pdf.dll php_pop3.dll php_smtp.dll How can I make them working? Previous Comments: [2006-12-18 21:26:25] rob4you at vodafone dot it Description: PHP 5.2.0 installed as Apache module (apache version 2.2.3) on Windows XP. I've also tried with PHP 5.2.1RC2-dev, PHP 5.1.2. I've used also Apache 2.0.x as webserver. The php.ini is correctly configured with the wanted extensions (extension=php_name.dll) and the right extensions_dir. The Apache server is correctly configured with the PHPIniDir and LoadModule directive. The problem is the following: when the server starts, SOME extensions are not loaded, and the following warning is produced (as an example): PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Programs\\PHP\\ext\\php_curl.dll' - Impossible to locate specified module.\r\n in Unknown on line 0 The extension is instead correctly placed in the right directory. It's quite strange that some extensions are loaded, some other are not loaded, but they are all in the SAME directory! ps: i've not used environment variable because in the manual it says it not necessary when using php as apache module. If I set instead the environment variable Path C:\Programs\PHP it works. However the behaviour for the problem previously exposed is unexpected: some extensions are correctly loaded, others no. -- Edit this bug report at http://bugs.php.net/?id=39877&edit=1
#39878 [Opn]: CURL doesn't compile on Sun Studio Pro
ID: 39878 User updated by: leozh at nbcs dot rutgers dot edu Reported By: leozh at nbcs dot rutgers dot edu Status: Open Bug Type: cURL related Operating System: Solaris 9 PHP Version: 5.2.0 New Comment: Ignore the error on line 1071 though, that is from me putting a void in front of the function declaration, but the error that caused the compile to fail was the one on line 1084. Previous Comments: [2006-12-18 21:28:43] leozh at nbcs dot rutgers dot edu Description: I tried to compile PHP 5.1.6 on my Solaris 9 box with Sun Studio Pro. cURL did not compile because it used deprecated cURL functions that did not exist in cURL 7.16. I then took the curl extension from the current 5.2 cvs and put it in the 5.1.6 source tree. Actual result: -- This is what happens: Sun Studio Pro does not like void functions returning values /bin/sh /usr/local/src/rpm-packages/BUILD/php-5.1.6/libtool --silent --preserve-dup-deps --mode=compile /opt/SUNWspro/bin/cc -Iext/curl/ -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/ -DPHP_ATOM_INC -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/include -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/main -I/usr/local/src/rpm-packages/BUILD/php-5.1.6 -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/date/lib -I/usr/local/include/freetype2 -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/imap-2004g/c-client/include -I//usr/local/mysql5/include/mysql -I/usr/local/mysql-5.0.27/include/mysql -I/usr/local/include/pspell -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/TSRM -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -mt -g -xs -c /usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c -o ext/curl/interface.lo "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1071: invalid type combination "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1464: warning: enum type mismatch: op "=" "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1471: warning: enum type mismatch: op "=" "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1622: warning: argument #3 is incompatible with prototype: prototype: pointer to unsigned int : "/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend/zend_hash.h", line 172 argument : pointer to int "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1622: warning: argument #4 is incompatible with prototype: prototype: pointer to unsigned long : "/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend/zend_hash.h", line 172 argument : pointer to long cc: acomp failed for /usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c *** Error code 1 make: Fatal error: Command failed for target `ext/curl/interface.lo' -- Edit this bug report at http://bugs.php.net/?id=39878&edit=1
#39866 [Bgs]: simpleXMLElement == behaviur changed
ID: 39866
User updated by: liatb at marvell dot com
Reported By: liatb at marvell dot com
Status: Bogus
Bug Type: SimpleXML related
Operating System: windows
PHP Version: 5.2.0
New Comment:
I was comparing two objects and not object two string. I followed the
description in "Comparing objects" in the manual
http://www.php.net/manual/en/language.oop5.object-comparison.php
As it worked as I expected in 5.0 and 5.1 I expected it to keep the
same output in 5.2
Previous Comments:
[2006-12-18 13:58:00] [EMAIL PROTECTED]
That's right. Object are equal only if they point to the same libxml2
data.
You must cast the objects to strings first if you want to compare them
as strings.
See "Example 5" at http://php.net/simplexml.
[2006-12-18 13:22:03] liatb at marvell dot com
Description:
I upgraded my PHP version from 5.1.* to 5.2.0
XML string loaded into two different simpleXML objects.
The result of comparing xml node attributes (without any specific cast)
in version 5.2.0 is different then used to be in 5.0.3 and 5.1.5.
I also checked the last snapshot for windows marked as "PHP Version
5.2.1RC2-dev" and got the same output as 5.2.0
Reproduce code:
---
hello";
$xml_1 = simplexml_load_string($xmlStr);
$xml_2 = simplexml_load_string($xmlStr);
var_dump($xml_1);
var_dump($xml_2);
print("");
if($xml_1['id'] == $xml_2['id']) {
print("equal ids");
}
else
{
print("not equal ids");
}
print("");
if($xml_1->name == $xml_2->name)
{
print("equal names");
}
else
{
print("not equal names");
}
?>
Expected result:
equal ids
equal names
Actual result:
--
not equal ids
not equal names
--
Edit this bug report at http://bugs.php.net/?id=39866&edit=1
#39878 [NEW]: CURL doesn't compile on Sun Studio Pro
From: leozh at nbcs dot rutgers dot edu Operating system: Solaris 9 PHP version: 5.2.0 PHP Bug Type: cURL related Bug description: CURL doesn't compile on Sun Studio Pro Description: I tried to compile PHP 5.1.6 on my Solaris 9 box with Sun Studio Pro. cURL did not compile because it used deprecated cURL functions that did not exist in cURL 7.16. I then took the curl extension from the current 5.2 cvs and put it in the 5.1.6 source tree. Actual result: -- This is what happens: Sun Studio Pro does not like void functions returning values /bin/sh /usr/local/src/rpm-packages/BUILD/php-5.1.6/libtool --silent --preserve-dup-deps --mode=compile /opt/SUNWspro/bin/cc -Iext/curl/ -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/ -DPHP_ATOM_INC -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/include -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/main -I/usr/local/src/rpm-packages/BUILD/php-5.1.6 -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/date/lib -I/usr/local/include/freetype2 -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/imap-2004g/c-client/include -I//usr/local/mysql5/include/mysql -I/usr/local/mysql-5.0.27/include/mysql -I/usr/local/include/pspell -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/TSRM -I/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -mt -g -xs -c /usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c -o ext/curl/interface.lo "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1071: invalid type combination "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1084: void function cannot return value "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1464: warning: enum type mismatch: op "=" "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1471: warning: enum type mismatch: op "=" "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1622: warning: argument #3 is incompatible with prototype: prototype: pointer to unsigned int : "/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend/zend_hash.h", line 172 argument : pointer to int "/usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c", line 1622: warning: argument #4 is incompatible with prototype: prototype: pointer to unsigned long : "/usr/local/src/rpm-packages/BUILD/php-5.1.6/Zend/zend_hash.h", line 172 argument : pointer to long cc: acomp failed for /usr/local/src/rpm-packages/BUILD/php-5.1.6/ext/curl/interface.c *** Error code 1 make: Fatal error: Command failed for target `ext/curl/interface.lo' -- Edit bug report at http://bugs.php.net/?id=39878&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39878&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39878&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39878&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39878&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39878&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39878&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39878&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39878&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39878&r=support Expected behavior:http://bugs.php.net/fix.php?id=39878&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39878&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39878&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39878&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39878&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39878&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39878&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39878&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39878&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39878&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39878&r=mysqlcfg
#39877 [NEW]: Unable to load dynamic library
From: rob4you at vodafone dot it Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: Dynamic loading Bug description: Unable to load dynamic library Description: PHP 5.2.0 installed as Apache module (apache version 2.2.3) on Windows XP. I've also tried with PHP 5.2.1RC2-dev, PHP 5.1.2. I've used also Apache 2.0.x as webserver. The php.ini is correctly configured with the wanted extensions (extension=php_name.dll) and the right extensions_dir. The Apache server is correctly configured with the PHPIniDir and LoadModule directive. The problem is the following: when the server starts, SOME extensions are not loaded, and the following warning is produced (as an example): PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Programs\\PHP\\ext\\php_curl.dll' - Impossible to locate specified module.\r\n in Unknown on line 0 The extension is instead correctly placed in the right directory. It's quite strange that some extensions are loaded, some other are not loaded, but they are all in the SAME directory! ps: i've not used environment variable because in the manual it says it not necessary when using php as apache module. If I set instead the environment variable Path C:\Programs\PHP it works. However the behaviour for the problem previously exposed is unexpected: some extensions are correctly loaded, others no. -- Edit bug report at http://bugs.php.net/?id=39877&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39877&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39877&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39877&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39877&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39877&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39877&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39877&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39877&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39877&r=support Expected behavior:http://bugs.php.net/fix.php?id=39877&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39877&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39877&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39877&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39877&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39877&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39877&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39877&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39877&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39877&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39877&r=mysqlcfg
#39875 [NEW]: imap_open causes a segmentation fault
From: richard at hddbroker dot com Operating system: CentOS 4.4 i386 PHP version: 5.2.0 PHP Bug Type: IMAP related Bug description: imap_open causes a segmentation fault Description: I was trying to get a simple script to work which simply opened a connection to the mail server and then closed it but when I ran the script it caused a segmentation fault on the imap_open line. Reproduce code: --- If I run the script via the CLI version of PHP it prints "Segmentation fault (core dumped)". If I run the script via a web server, an empty page is returned. Expected result: In this particular script I expected the imap_open function to return a resource object. Actual result: -- I configured my PHP with --enable-debug and followed the steps to get the following backtrace: #0 0x00144019 in SSL_SESSION_hash () from /lib/libssl.so.4 #1 0x001ca484 in lh_free () from /lib/libcrypto.so.4 #2 0x001ca5f3 in lh_delete () from /lib/libcrypto.so.4 #3 0x00148141 in SSL_CTX_get_timeout () from /lib/libssl.so.4 #4 0x001ca56e in lh_retrieve () from /lib/libcrypto.so.4 #5 0x001481f7 in SSL_CTX_flush_sessions () from /lib/libssl.so.4 #6 0x001441a3 in SSL_CTX_free () from /lib/libssl.so.4 #7 0x005185ac in ssl_close () from /usr/lib/libc-client.so.0 #8 0x0051851f in ssl_close () from /usr/lib/libc-client.so.0 #9 0x005176c3 in ssl_aopen () from /usr/lib/libc-client.so.0 #10 0x0054a697 in imap_open () from /usr/lib/libc-client.so.0 #11 0x00523a90 in mail_open () from /usr/lib/libc-client.so.0 #12 0x0814dcfc in zif_imap_open (ht=3, return_value=0xb7c8bc9c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-5.2.0/ext/imap/php_imap.c:780 #13 0x08332c92 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe372e0) at /usr/local/src/php-5.2.0/Zend/zend_vm_execute.h:200 #14 0x08332419 in execute (op_array=0xb7c8b68c) at /usr/local/src/php-5.2.0/Zend/zend_vm_execute.h:92 #15 0x0831aa9b in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-5.2.0/Zend/zend.c:1097 #16 0x082e4a51 in php_execute_script (primary_file=0xbfe397d0) at /usr/local/src/php-5.2.0/main/main.c:1758 #17 0x08393462 in main (argc=2, argv=0xbfe398a4) at /usr/local/src/php-5.2.0/sapi/cli/php_cli.c:1108 -- Edit bug report at http://bugs.php.net/?id=39875&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39875&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39875&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39875&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39875&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39875&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39875&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39875&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39875&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39875&r=support Expected behavior:http://bugs.php.net/fix.php?id=39875&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39875&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39875&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39875&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39875&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39875&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39875&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39875&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39875&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39875&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39875&r=mysqlcfg
#39873 [Fbk->Opn]: thousands_sep not shown
ID: 39873
User updated by: rob4you at vodafone dot it
Reported By: rob4you at vodafone dot it
-Status: Feedback
+Status: Open
Bug Type: Strings related
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
I've tried the link for Windows you suggested:
http://snaps.php.net/win32/php5.2-win32-latest.zip.
Now i've this version of php: "PHP Version 5.2.1RC2-dev".
But the problem isn't resolved. On the contrary, it's going worse: now
it's ignored also the decimal separator [decimal_point] with %f.
The problem persists also with other os.
With the same script of the previous message, here it is the output
produced:
Actual result:
--
Italian_Italy.1252
1234,56
Not dependant in local settings: 1234.56000
Dependant on local settings: 1234.56
Array
(
[decimal_point] => ,
[thousands_sep] => .
...etc...
)
The expected result is obviously the same as the previous message:
Expected result:
Italian_Italy.1252
1.234,56
Not dependant in local settings: 1234.56
Dependant on local settings: 1.234,56
Array
(
[decimal_point] => ,
[thousands_sep] => .
...etc...
)
Previous Comments:
[2006-12-18 18:52:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-12-18 17:48:18] rob4you at vodafone dot it
Description:
The [thousands_sep] states dot "." as separator of thousands, but the
output of the number DOES NOT show it.
It is correctly shown in the array returned by "localeconv" although.
I've observed the same problem on other OS and with other locales.
Reproduce code:
---
";
$ita=array("ita","it","Italian","it_IT","it_IT.ISO8859-1","it_IT.ISO_8859-1");
$local_settings=setlocale(LC_ALL,$ita);
echo $local_settings."";
$num=0+"1234.56";
echo $num;
printf("\n Not dependant in local settings: %F \n",$num);
printf("\n Dependant on local settings: %f \n",$num);
$x=localeconv();
print_r($x);
echo "";
?>
Expected result:
Italian_Italy.1252
1.234,56
Not dependant in local settings: 1234.56
Dependant on local settings: 1.234,56
Array
(
[decimal_point] => ,
[thousands_sep] => .
...etc...
)
Actual result:
--
Italian_Italy.1252
1234,56
Not dependant in local settings: 1234.56
Dependant on local settings: 1234,56
Array
(
[decimal_point] => ,
[thousands_sep] => .
...etc...
)
--
Edit this bug report at http://bugs.php.net/?id=39873&edit=1
#39809 [Opn->Fbk]: FastCGI Requests silently dropped
ID: 39809
Updated by: [EMAIL PROTECTED]
Reported By: e at osterman dot com
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: FC6
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
> $socket1 = FCGI_Connect('localhost', 1234);
> FCGI_Test($socket1);
> FCGI_Response($socket1);
> sleep(30);
> fclose($socket1);
> ?>
this code is not perferct, and this is the reason of bad behavior. You
should call shutdown() "man 2 shutdown" after writing request into
socket, but PHP doesn't implement such function.
I cannot repeat your behavior with telnet. I always get "Connection
closed" after a timeout.
BTW you can insert debug output into fastcgi.c right after accept() and
try it.
Previous Comments:
[2006-12-18 18:29:13] e at osterman dot com
For what it's worth, this shows some conflicting data. Perhaps I'm just
interpretting it wrong.
Start theh FCGI server in single process mode
# php-cgi -b 1234
Modify the test script as follows:
Now, the single process php-cgi server should not be accept()ing any
more connections for 30 seconds.
# telnet localhost 1234
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
Per my previous post, when a stream_socket_server server does not call
accept(), the 'telnet' session gets "connection refused". In this
example, it's not getting refused by the php-cgi server, which leads me
to believe that php-cgi might actually be calling accept. This could be
a implementation difference.. but I don't know.
Regards,
Erik Osterman
[2006-12-18 18:20:11] e at osterman dot com
Dimitry,
You're example shocked me. I tried something similar making a simple
stream_socket_server, but didn't make the client in PHP.
# telnet localhost 1234
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
I had expected the same behavior in PHP's fsockopen, but indeed, as you
said fsocketopen returns a valid resource even though the connection has
not yet been accept()'d by the server. More over, feof returns false and
fwrite to the socket returns the correct number of bytes "written".
stream_get_metadata returns nothing interesting either.
How is a PHP fsockopen/stream_socket_client client to know when a
connection truely has been accept()'d?
The reason why this is all so important to us, is that we have a
cluster of frontend servers that use a pool of FCGI backend servers. We
need the busier frontend servers to dynamically open up more persistent
connections (FCGI_KEEP_CONN) to FCGI servers (and release them as
demand subsides). When a particular FCGI server is at capacity
(PHP_FCGI_CHILDREN), we need the client to try (in a round robin
fashion) another FCGI server. The current problem, as you understand by
now, is that the client get's stuck when connecting to an FCGI server at
capacity and timeout.
As you've now suggested, it's apparently b/c they getting stuck waiting
for the accept(), but never get it.
What recourse does the client have?
Regards,
Erik Osterman
[2006-12-18 13:15:46] [EMAIL PROTECTED]
No you are :)
But you made a great job writting test script, and I think this
discussion may lead us to some good result.
The fact that connect() returns file descriptor doesn't mean that
accept() was really called. See the folllowing script. You can even
write to socket befor it is really accepted.
[2006-12-15 21:35:04] e at osterman dot com
> PHP process DOESN'T accept() new connections
> if it already has persistent connection opened.
> Note that php/fastcgi is one-process-one-connection
> server that doesn't implement multiplexion
If this were actually the case, I'd be satisfied. That would mean the
FCGI clients would get "connection refused" when there are no more
sockets/children available. But what actually happens is that the
connection is established, meaning accept() does get called.
To test this, modify the example like this
// Open up the first connection
$socket1 = FCGI_Connect('localhost', 1234);
// Send a request with FCGI_KEEP_CONN
FCGI_Test($socket1);
// Open up the second connection (should be refused)
$socket2 = FCGI_Connect('localhost', 1234);
printf("socket1:%d socket2:%d\n", feof($socket1), feof($socket2));
Expected output:
socket1:0 socket2:1
Actual output:
socket1:0 socket2:0
In otherwords, both connections are established => accept() was
called.
Am I making sense?
Regards,
Erik Osterman
[2006-12-15 15:00:55] [EMAIL PROTECTED]
> it simply accepts/ignores them
PHP process DOESN'T accept() new connections if it already has
persist
#39873 [Opn->Fbk]: thousands_sep not shown
ID: 39873
Updated by: [EMAIL PROTECTED]
Reported By: rob4you at vodafone dot it
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-12-18 17:48:18] rob4you at vodafone dot it
Description:
The [thousands_sep] states dot "." as separator of thousands, but the
output of the number DOES NOT show it.
It is correctly shown in the array returned by "localeconv" although.
I've observed the same problem on other OS and with other locales.
Reproduce code:
---
";
$ita=array("ita","it","Italian","it_IT","it_IT.ISO8859-1","it_IT.ISO_8859-1");
$local_settings=setlocale(LC_ALL,$ita);
echo $local_settings."";
$num=0+"1234.56";
echo $num;
printf("\n Not dependant in local settings: %F \n",$num);
printf("\n Dependant on local settings: %f \n",$num);
$x=localeconv();
print_r($x);
echo "";
?>
Expected result:
Italian_Italy.1252
1.234,56
Not dependant in local settings: 1234.56
Dependant on local settings: 1.234,56
Array
(
[decimal_point] => ,
[thousands_sep] => .
...etc...
)
Actual result:
--
Italian_Italy.1252
1234,56
Not dependant in local settings: 1234.56
Dependant on local settings: 1234,56
Array
(
[decimal_point] => ,
[thousands_sep] => .
...etc...
)
--
Edit this bug report at http://bugs.php.net/?id=39873&edit=1
#39874 [NEW]: gztell returns incorrect file pointer number
From: sramage at nucleuslabs dot com
Operating system: FREEBSD 5
PHP version: 4.4.4
PHP Bug Type: *Compression related
Bug description: gztell returns incorrect file pointer number
Description:
The GZTELL function returns the gz file pointer as the uncompressed data
byte position not the real file pointer location when writing to a file.
I am not sure if this is a bug or just the way it is. but it doesn't
really make sense so I am reporting it.
The example is very simple and clear.
just use any text file that is 2 MB or bigger in length to recreate this
bug
We use the recommened php ini with the following changes:
memory_limit = 32M
error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
upload_max_filesize = 10Mb
session.cookie_lifetime = 0
session.cookie_path = /
session.gc_probability = 1
session.gc_divisor = 1
session.gc_maxlifetime = 3600
session.entropy_length = 16
session.entropy_file = /dev/urandom
modules:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--disable-all' '--with-regex=php' '--with-pcre-regex'
'--with-pear' '--enable-ftp' '--with-openssl=/usr/local/ssl' '--enable-ftp'
'--with-mysql=/usr/local/mysql' '--enable-overload' '--enable-session'
'--enable-xml' '--with-zlib=yes' '--with-apxs=/usr/local/apache/bin/apxs'
'--prefix=/usr/local/php' '--with-config-file-path=/usr/local/php'
'--enable-mbstring=all' '--enable-track-vars'
'--enable-force-cgi-redirect' '--with-gettext' '--with-pspell'
Reproduce code:
---
\n";
gzclose($gz_fp);
echo "filesize = ".filesize('some_file.sql.gz')."\n";
?>
Expected result:
gztell = 249264
filesize = 249264
(or something closer to the actual file pointer position in the gz file)
Actual result:
--
gztell = 2048000
filesize = 249264
--
Edit bug report at http://bugs.php.net/?id=39874&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39874&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39874&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39874&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39874&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39874&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39874&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39874&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39874&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39874&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39874&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39874&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39874&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39874&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39874&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39874&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39874&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39874&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39874&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39874&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39874&r=mysqlcfg
#39809 [Opn]: FastCGI Requests silently dropped
ID: 39809
User updated by: e at osterman dot com
Reported By: e at osterman dot com
Status: Open
Bug Type: CGI related
Operating System: FC6
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
For what it's worth, this shows some conflicting data. Perhaps I'm just
interpretting it wrong.
Start theh FCGI server in single process mode
# php-cgi -b 1234
Modify the test script as follows:
Now, the single process php-cgi server should not be accept()ing any
more connections for 30 seconds.
# telnet localhost 1234
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
Per my previous post, when a stream_socket_server server does not call
accept(), the 'telnet' session gets "connection refused". In this
example, it's not getting refused by the php-cgi server, which leads me
to believe that php-cgi might actually be calling accept. This could be
a implementation difference.. but I don't know.
Regards,
Erik Osterman
Previous Comments:
[2006-12-18 18:20:11] e at osterman dot com
Dimitry,
You're example shocked me. I tried something similar making a simple
stream_socket_server, but didn't make the client in PHP.
# telnet localhost 1234
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
I had expected the same behavior in PHP's fsockopen, but indeed, as you
said fsocketopen returns a valid resource even though the connection has
not yet been accept()'d by the server. More over, feof returns false and
fwrite to the socket returns the correct number of bytes "written".
stream_get_metadata returns nothing interesting either.
How is a PHP fsockopen/stream_socket_client client to know when a
connection truely has been accept()'d?
The reason why this is all so important to us, is that we have a
cluster of frontend servers that use a pool of FCGI backend servers. We
need the busier frontend servers to dynamically open up more persistent
connections (FCGI_KEEP_CONN) to FCGI servers (and release them as
demand subsides). When a particular FCGI server is at capacity
(PHP_FCGI_CHILDREN), we need the client to try (in a round robin
fashion) another FCGI server. The current problem, as you understand by
now, is that the client get's stuck when connecting to an FCGI server at
capacity and timeout.
As you've now suggested, it's apparently b/c they getting stuck waiting
for the accept(), but never get it.
What recourse does the client have?
Regards,
Erik Osterman
[2006-12-18 13:15:46] [EMAIL PROTECTED]
No you are :)
But you made a great job writting test script, and I think this
discussion may lead us to some good result.
The fact that connect() returns file descriptor doesn't mean that
accept() was really called. See the folllowing script. You can even
write to socket befor it is really accepted.
[2006-12-15 21:35:04] e at osterman dot com
> PHP process DOESN'T accept() new connections
> if it already has persistent connection opened.
> Note that php/fastcgi is one-process-one-connection
> server that doesn't implement multiplexion
If this were actually the case, I'd be satisfied. That would mean the
FCGI clients would get "connection refused" when there are no more
sockets/children available. But what actually happens is that the
connection is established, meaning accept() does get called.
To test this, modify the example like this
// Open up the first connection
$socket1 = FCGI_Connect('localhost', 1234);
// Send a request with FCGI_KEEP_CONN
FCGI_Test($socket1);
// Open up the second connection (should be refused)
$socket2 = FCGI_Connect('localhost', 1234);
printf("socket1:%d socket2:%d\n", feof($socket1), feof($socket2));
Expected output:
socket1:0 socket2:1
Actual output:
socket1:0 socket2:0
In otherwords, both connections are established => accept() was
called.
Am I making sense?
Regards,
Erik Osterman
[2006-12-15 15:00:55] [EMAIL PROTECTED]
> it simply accepts/ignores them
PHP process DOESN'T accept() new connections if it already has
persistent connection opened. Note that php/fastcgi is
one-process-one-connection server that doesn't implement multiplexion
(like apache 1.3).
PHP doesn't try to manage persistent connection itself, however FastCGI
module may do it (especially in multithreaded environment).
[2006-12-13 21:26:46] e at osterman dot com
I know if you open up 1 socket to one child, it works:
> If you only open up 1 socket, and run multiple requests > it works
fine.
That's not the bug. The bug is PHP doesn't handle persistent
connections (FCGI_KEEP_CONN), when the number of persistent
#39809 [Fbk->Opn]: FastCGI Requests silently dropped
ID: 39809
User updated by: e at osterman dot com
Reported By: e at osterman dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: FC6
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
Dimitry,
You're example shocked me. I tried something similar making a simple
stream_socket_server, but didn't make the client in PHP.
# telnet localhost 1234
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
I had expected the same behavior in PHP's fsockopen, but indeed, as you
said fsocketopen returns a valid resource even though the connection has
not yet been accept()'d by the server. More over, feof returns false and
fwrite to the socket returns the correct number of bytes "written".
stream_get_metadata returns nothing interesting either.
How is a PHP fsockopen/stream_socket_client client to know when a
connection truely has been accept()'d?
The reason why this is all so important to us, is that we have a
cluster of frontend servers that use a pool of FCGI backend servers. We
need the busier frontend servers to dynamically open up more persistent
connections (FCGI_KEEP_CONN) to FCGI servers (and release them as
demand subsides). When a particular FCGI server is at capacity
(PHP_FCGI_CHILDREN), we need the client to try (in a round robin
fashion) another FCGI server. The current problem, as you understand by
now, is that the client get's stuck when connecting to an FCGI server at
capacity and timeout.
As you've now suggested, it's apparently b/c they getting stuck waiting
for the accept(), but never get it.
What recourse does the client have?
Regards,
Erik Osterman
Previous Comments:
[2006-12-18 13:15:46] [EMAIL PROTECTED]
No you are :)
But you made a great job writting test script, and I think this
discussion may lead us to some good result.
The fact that connect() returns file descriptor doesn't mean that
accept() was really called. See the folllowing script. You can even
write to socket befor it is really accepted.
[2006-12-15 21:35:04] e at osterman dot com
> PHP process DOESN'T accept() new connections
> if it already has persistent connection opened.
> Note that php/fastcgi is one-process-one-connection
> server that doesn't implement multiplexion
If this were actually the case, I'd be satisfied. That would mean the
FCGI clients would get "connection refused" when there are no more
sockets/children available. But what actually happens is that the
connection is established, meaning accept() does get called.
To test this, modify the example like this
// Open up the first connection
$socket1 = FCGI_Connect('localhost', 1234);
// Send a request with FCGI_KEEP_CONN
FCGI_Test($socket1);
// Open up the second connection (should be refused)
$socket2 = FCGI_Connect('localhost', 1234);
printf("socket1:%d socket2:%d\n", feof($socket1), feof($socket2));
Expected output:
socket1:0 socket2:1
Actual output:
socket1:0 socket2:0
In otherwords, both connections are established => accept() was
called.
Am I making sense?
Regards,
Erik Osterman
[2006-12-15 15:00:55] [EMAIL PROTECTED]
> it simply accepts/ignores them
PHP process DOESN'T accept() new connections if it already has
persistent connection opened. Note that php/fastcgi is
one-process-one-connection server that doesn't implement multiplexion
(like apache 1.3).
PHP doesn't try to manage persistent connection itself, however FastCGI
module may do it (especially in multithreaded environment).
[2006-12-13 21:26:46] e at osterman dot com
I know if you open up 1 socket to one child, it works:
> If you only open up 1 socket, and run multiple requests > it works
fine.
That's not the bug. The bug is PHP doesn't handle persistent
connections (FCGI_KEEP_CONN), when the number of persistent connections
exceedes the number of php children. The fcgi spec states that if the
application doesn't have enough resoures to complete the request (e.g
database handles, or in the case of PHP enough children), that it
should return that it's overloaded. PHP does not do this; it simply
accepts/ignores them. What PHP does is rely on the connection queueing,
which doesn't solve the KEEP_CONN problem. Constantly opening up
connections is inefficient.
Regards,
Erik Osterman
[2006-12-13 14:44:51] [EMAIL PROTECTED]
In your example you use persistent FastCGI connections
(FCGI_KEEP_CONN). It means web server connects to PHP and sends SEVERAL
requests using the SAME socket then it can close connection. You can
correct your example in the following way to use persistent conec
#39869 [Fbk->Opn]: safe_read does not initialize errno
ID: 39869 User updated by: michiel at boland dot org Reported By: michiel at boland dot org -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Solaris PHP Version: 5.2.0 Assigned To: dmitry New Comment: If errno is already EINTR before entry into safe_read, then that function will loop forever if the read() call returns 0 Previous Comments: [2006-12-18 17:33:01] [EMAIL PROTECTED] Could you please provide which "errno" and "ret" values leads php into this loop. [2006-12-18 15:20:44] michiel at boland dot org Description: When using PHP in FastCGI mode, PHP has a tendency to once in a while spin in a tight loop, hogging the cpu. The fix is to initialize errno to 0 before any call to read() in the safe_read function in sapi/cgi/fastcgi.c Reproduce code: --- Not applicable Expected result: n.a. Actual result: -- n.a. -- Edit this bug report at http://bugs.php.net/?id=39869&edit=1
#39845 [Asn->Csd]: Persistent connections and PostgreSQL
ID: 39845
Updated by: [EMAIL PROTECTED]
Reported By: olivier at elma dot fr
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Debian unstable
PHP Version: 5.2.0
Assigned To: wez
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-12-15 16:16:05] olivier at elma dot fr
Just to be more specific about my php version:
$ php --version
PHP 5.2.0-7 (cli) (built: Nov 24 2006 14:36:54)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
[2006-12-15 16:09:29] olivier at elma dot fr
Description:
Since I upgraded from php 5.1.x to php 5.2.0 persistent connections
doesn't work anymore.
PDO keeps telling me the driver does not support this functionnality.
Reproduce code:
---
true));
echo "Connected\n";
} catch (Exception $e) {
echo "Failure: " . $e->getMessage();
}
?>
Expected result:
Connected
Actual result:
--
Warning: PDO::__construct(): SQLSTATE[IM001]: Driver does not support
this function: driver does not support setting attributes in
/home/slaanesh/pdo.php on line 3
Connected
--
Edit this bug report at http://bugs.php.net/?id=39845&edit=1
#39873 [NEW]: thousands_sep not shown
From: rob4you at vodafone dot it
Operating system: Windows XP
PHP version: 5.2.0
PHP Bug Type: Strings related
Bug description: thousands_sep not shown
Description:
The [thousands_sep] states dot "." as separator of thousands, but the
output of the number DOES NOT show it.
It is correctly shown in the array returned by "localeconv" although.
I've observed the same problem on other OS and with other locales.
Reproduce code:
---
";
$ita=array("ita","it","Italian","it_IT","it_IT.ISO8859-1","it_IT.ISO_8859-1");
$local_settings=setlocale(LC_ALL,$ita);
echo $local_settings."";
$num=0+"1234.56";
echo $num;
printf("\n Not dependant in local settings: %F \n",$num);
printf("\n Dependant on local settings: %f \n",$num);
$x=localeconv();
print_r($x);
echo "";
?>
Expected result:
Italian_Italy.1252
1.234,56
Not dependant in local settings: 1234.56
Dependant on local settings: 1.234,56
Array
(
[decimal_point] => ,
[thousands_sep] => .
...etc...
)
Actual result:
--
Italian_Italy.1252
1234,56
Not dependant in local settings: 1234.56
Dependant on local settings: 1234,56
Array
(
[decimal_point] => ,
[thousands_sep] => .
...etc...
)
--
Edit bug report at http://bugs.php.net/?id=39873&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39873&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39873&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39873&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39873&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39873&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39873&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39873&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39873&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39873&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39873&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39873&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39873&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39873&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39873&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39873&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39873&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39873&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39873&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39873&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39873&r=mysqlcfg
#39872 [Bgs]: PHP from CLI headers_list() is empty
ID: 39872 User updated by: markjcrane at gmail dot com Reported By: markjcrane at gmail dot com Status: Bogus Bug Type: CGI related Operating System: Windows XP SP2 PHP Version: 5.2.0 New Comment: Then can header() and headers_list() be removed from the CLI? When the function doesn't work from the CLI does it make sense to keep it in the CLI? Otherwise to use PHP 5.2.0 I would have to direct people to use alternative functions like myheader() and myheaders_list() for those commands. At which point their code would no longer be standard and work the same on an Apache Server or other web server. Previous Comments: [2006-12-18 17:04:47] [EMAIL PROTECTED] 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 Because in CLI headers are not actually sent, headers_list() does not report them. [2006-12-18 16:56:26] markjcrane at gmail dot com Description: The function header() and headers_list() works as expected when run from PHP 5.1.6 run from the command line however in PHP 5.2.0 when run from the command line headers_list() is an empty array. I'm not really sure if this was a bug or intentional. In most cases it probably is not needed for command line programs. In my case my command line program is a personal web server and I use headers_list() to find any custom PHP headers to send to the browser. If it was removed intentionally then maybe the header() function and headers_list() should be removed from the command line interface. That way it would be consistent and the few of us that need that functionality can add it back in with identical functions written in PHP code. Thanks for your time and help! Reproduce code: --- Expected result: Array ( [0] => X-Powered-By: PHP/5.2.0 [1] => Cache-Control: no-cache ) Actual result: -- Array ( ) -- Edit this bug report at http://bugs.php.net/?id=39872&edit=1
#39869 [Asn->Fbk]: safe_read does not initialize errno
ID: 39869 Updated by: [EMAIL PROTECTED] Reported By: michiel at boland dot org -Status: Assigned +Status: Feedback Bug Type: CGI related Operating System: Solaris PHP Version: 5.2.0 Assigned To: dmitry New Comment: Could you please provide which "errno" and "ret" values leads php into this loop. Previous Comments: [2006-12-18 15:20:44] michiel at boland dot org Description: When using PHP in FastCGI mode, PHP has a tendency to once in a while spin in a tight loop, hogging the cpu. The fix is to initialize errno to 0 before any call to read() in the safe_read function in sapi/cgi/fastcgi.c Reproduce code: --- Not applicable Expected result: n.a. Actual result: -- n.a. -- Edit this bug report at http://bugs.php.net/?id=39869&edit=1
#39803 [Opn->Fbk]: fsockopen() bug
ID: 39803 Updated by: [EMAIL PROTECTED] Reported By: marcelo at tpn dot com dot br -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: FreeBSD 5.3 PHP Version: 4.4.4 New Comment: I really doubt I can reproduce or investigate it with only an FTP account. When I said "account on this machine" I meant SSH access. Previous Comments: [2006-12-18 17:03:42] marcelo at tpn dot com dot br Someone else can help me to fix this bug? [2006-12-14 13:28:18] marcelo at tpn dot com dot br Did you receive my e-mail? [2006-12-13 14:30:38] marcelo at tpn dot com dot br Sent to [EMAIL PROTECTED] [2006-12-13 13:27:31] [EMAIL PROTECTED] Sure. [2006-12-13 13:13:10] marcelo at tpn dot com dot br Can I send the account information to [EMAIL PROTECTED] for privacy? 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/39803 -- Edit this bug report at http://bugs.php.net/?id=39803&edit=1
#28793 [Asn->Csd]: php.ini settings should be able to read other php.ini settings
ID: 28793 Updated by: [EMAIL PROTECTED] Reported By: bero at arklinux dot org -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.0.0RC3 Assigned To: andrei New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php It's already in PHP 5.1 and later. Previous Comments: [2004-06-15 16:36:29] [EMAIL PROTECTED] This is on our list for 5.1 already. Assigning this request to Andrei as he has a patch for it already. [2004-06-15 16:19:21] bero at arklinux dot org Description: This may not make a lot of sense at first look, but it makes perfect sense if you're using a CONFIG_FILE_SCAN_DIR and trying to install a number of 3rd party modules: php.ini settings should be able to reference other php.ini settings Example: [CONFIG_FILE_SCAN_DIR is set to /etc/php.d] /etc/php.ini has include_path=.;/usr/local/php-includes /etc/php.d/3rdpartymodule.ini has include_path=/opt/3rdpartymodule /etc/php.d/anothermodule.ini has include_path=/usr/local/anothermodule These are mutually exclusive --- to reduce the administrator workload of changing include_path for every 3rd party module (what CONFIG_FILE_SCAN_DIR was all about in the first place), it would be really nice if a 3rd party config file could just do include_path += /opt/3rdpartymodule or include_path = $include_path:/opt/3rdpartymodule -- Edit this bug report at http://bugs.php.net/?id=28793&edit=1
#39872 [Opn->Bgs]: PHP from CLI headers_list() is empty
ID: 39872 Updated by: [EMAIL PROTECTED] Reported By: markjcrane at gmail dot com -Status: Open +Status: Bogus Bug Type: CGI related Operating System: Windows XP SP2 PHP Version: 5.2.0 New Comment: 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 Because in CLI headers are not actually sent, headers_list() does not report them. Previous Comments: [2006-12-18 16:56:26] markjcrane at gmail dot com Description: The function header() and headers_list() works as expected when run from PHP 5.1.6 run from the command line however in PHP 5.2.0 when run from the command line headers_list() is an empty array. I'm not really sure if this was a bug or intentional. In most cases it probably is not needed for command line programs. In my case my command line program is a personal web server and I use headers_list() to find any custom PHP headers to send to the browser. If it was removed intentionally then maybe the header() function and headers_list() should be removed from the command line interface. That way it would be consistent and the few of us that need that functionality can add it back in with identical functions written in PHP code. Thanks for your time and help! Reproduce code: --- Expected result: Array ( [0] => X-Powered-By: PHP/5.2.0 [1] => Cache-Control: no-cache ) Actual result: -- Array ( ) -- Edit this bug report at http://bugs.php.net/?id=39872&edit=1
#39803 [Opn]: fsockopen() bug
ID: 39803 User updated by: marcelo at tpn dot com dot br Reported By: marcelo at tpn dot com dot br Status: Open Bug Type: Sockets related Operating System: FreeBSD 5.3 PHP Version: 4.4.4 New Comment: Someone else can help me to fix this bug? Previous Comments: [2006-12-14 13:28:18] marcelo at tpn dot com dot br Did you receive my e-mail? [2006-12-13 14:30:38] marcelo at tpn dot com dot br Sent to [EMAIL PROTECTED] [2006-12-13 13:27:31] [EMAIL PROTECTED] Sure. [2006-12-13 13:13:10] marcelo at tpn dot com dot br Can I send the account information to [EMAIL PROTECTED] for privacy? [2006-12-13 10:09:48] [EMAIL PROTECTED] Please provide more information on how to reproduce it or an account on this machine. 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/39803 -- Edit this bug report at http://bugs.php.net/?id=39803&edit=1
#39872 [NEW]: PHP from CLI headers_list() is empty
From: markjcrane at gmail dot com Operating system: Windows XP SP2 PHP version: 5.2.0 PHP Bug Type: *General Issues Bug description: PHP from CLI headers_list() is empty Description: The function header() and headers_list() works as expected when run from PHP 5.1.6 run from the command line however in PHP 5.2.0 when run from the command line headers_list() is an empty array. I'm not really sure if this was a bug or intentional. In most cases it probably is not needed for command line programs. In my case my command line program is a personal web server and I use headers_list() to find any custom PHP headers to send to the browser. If it was removed intentionally then maybe the header() function and headers_list() should be removed from the command line interface. That way it would be consistent and the few of us that need that functionality can add it back in with identical functions written in PHP code. Thanks for your time and help! Reproduce code: --- Expected result: Array ( [0] => X-Powered-By: PHP/5.2.0 [1] => Cache-Control: no-cache ) Actual result: -- Array ( ) -- Edit bug report at http://bugs.php.net/?id=39872&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39872&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39872&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39872&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39872&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39872&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39872&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39872&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39872&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39872&r=support Expected behavior:http://bugs.php.net/fix.php?id=39872&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39872&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39872&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39872&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39872&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39872&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39872&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39872&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39872&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39872&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39872&r=mysqlcfg
#39869 [Opn->Asn]: safe_read does not initialize errno
ID: 39869 Updated by: [EMAIL PROTECTED] Reported By: michiel at boland dot org -Status: Open +Status: Assigned Bug Type: CGI related Operating System: Solaris PHP Version: 5.2.0 -Assigned To: +Assigned To: dmitry Previous Comments: [2006-12-18 15:20:44] michiel at boland dot org Description: When using PHP in FastCGI mode, PHP has a tendency to once in a while spin in a tight loop, hogging the cpu. The fix is to initialize errno to 0 before any call to read() in the safe_read function in sapi/cgi/fastcgi.c Reproduce code: --- Not applicable Expected result: n.a. Actual result: -- n.a. -- Edit this bug report at http://bugs.php.net/?id=39869&edit=1
#39712 [Asn]: Installation failure "Program Required"
ID: 39712 Updated by: [EMAIL PROTECTED] Reported By: kemputer at optushome dot com dot au Status: Assigned Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 5.2.0 Assigned To: jmertic New Comment: Could you run it in verbose logging mode and attach the log file? To run in verbose logging mode issue the below command from the command prompt ( from the same directory where the install exists ): msiexec /i php-5.2.0-win32-installer.msi /l*v error.log Previous Comments: [2006-12-08 23:38:38] kemputer at optushome dot com dot au If I install the php msi kit without configuring a server, there is no error. Installation appears to be clean. (Sorry, for the delay in replying, I was away from my office) [2006-12-04 15:48:53] [EMAIL PROTECTED] Do you get the same error if you choose not configure a web server? [2006-12-02 07:23:33] kemputer at optushome dot com dot au I used AusGamers on http://au2.php.net/distributions/php-5.2.0-win32-installer.msi I had tried Planet Mirror au.php.net but the download hung on 40Kb. [2006-12-02 06:35:17] [EMAIL PROTECTED] Which mirror did you use to download PHP? [2006-12-02 03:40:35] kemputer at optushome dot com dot au Description: Installaing PHP V 5.2 from the msi installation file terminated prematurely with a message "A program required for this install to complete could not be run. Contact your support personnel etc". This is followed a a final installation wizard page informing that the process terminated prematurely and didn't complete I uninstalled php and repeated the installation many times, each time getting the same message irrespective of what ever flavour of IIS I selected form the early installation option regards Colin Expected result: Expectation is a clean installation of php -- Edit this bug report at http://bugs.php.net/?id=39712&edit=1
#39842 [Asn->Csd]: Windows installer sets non existing session.save_path
ID: 39842 Updated by: [EMAIL PROTECTED] Reported By: php at ahlenstorf dot ch -Status: Assigned +Status: Closed Bug Type: Unknown/Other Function Operating System: Windows XP SP2 PHP Version: 5.2.0 Assigned To: jmertic New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-12-15 09:15:43] php at ahlenstorf dot ch Description: The Windows Installer of PHP 5.2.0 creates a php.ini with prefilled upload_tmp_dir and session.save_path settings. Both point to directories within the temporary directory in the user profile like Temp\php\upload or Temp\php\session. Unfortunately neither the Windows Installer nor PHP (+Apache 2.2.3) itself create these directories. Expected result: Either valid php.ini settings or a warning at the end of the installer including empty php.ini settings (so that's easier to spot what's wrong). Actual result: -- Neither sessions nor file uploads work. Excerpt from Apache's error.log: [Fri Dec 15 10:05:20 2006] [error] [client 127.0.0.1] PHP Warning: session_start() [function.session-start]: open(C:\\DOKUME~1\\ADMINI~1\\LOKALE~1\\Temp\\php\\upload\\sess_n1ab9mml2m000pjl4ciq20gdl0, O_RDWR) failed: No such file or directory (2) in C:\\Webserver\\core\\base_classes\\session.class.php on line 106 -- Edit this bug report at http://bugs.php.net/?id=39842&edit=1
#39871 [NEW]: emalloc() fails when calling sybase_query()
From: kkimmel at cse dot ohio-state dot edu
Operating system: RHEL 4 x86_64 Kernel 2.6.9
PHP version: 4.4.4
PHP Bug Type: *General Issues
Bug description: emalloc() fails when calling sybase_query()
Description:
This error happens with php 4.4.4 and php 5.2.0.
Test system:
Dual Processor Intel Xeon CPU 3.20ghz
Red Hat Enterprise 4 x86_64
glibc 2.3.4
gcc 3.4.6
apache 2.0.59
PHP 4.4.4 build flags:
./configure \
--prefix=/opt/php-4.4.4 \
--with-apxs2=/opt/apache-2.0.59/bin/apxs \
--with-sybase-ct=/usr/local/sybase/OCS-12_5 \
--enable-debug
The apache startup script exports the following env vars:
SYBASE="/usr/local/sybase"
SYBASE_OCS="OCS-12_5"
SYBASE_SYSAM="SYSAM-1_0"
LANG="en_US"
There are no errors reported from the sybase client library in the log
file. I also had to hand edit ./configure because it cannot find the
sybase 64bit libraries.
The below code executes correctly on our old server which ran Solaris 8,
Apache 1.3.33, PHP 4.4.0 and connected to the same sybase server.
Reproduce code:
---
ini_set('display_errors', '1');
error_reporting(E_ALL);
$link = sybase_connect('omega', 'test1', 'pass');
$worked = sybase_select_db('dev01', $link);
$sql = "SELECT * FROM Events";
$mixed = sybase_query($sql, $link);
print_r($mixed);
Expected result:
It should print out something like the following:
Resource id #3
Actual result:
--
In the apache log I see the following error:
FATAL: emalloc(): Unable to allocate 42949672961 bytes
Below is the backtrace of the code attached to this bug:
(gdb) bt
#0 0x00374dd2e829 in kill () from /lib64/tls/libc.so.6
#1 0x002a956de859 in _emalloc (size=42949672961,
__zend_filename=0x2a9572a338
"/tmp/php-4.4.4/ext/sybase_ct/php_sybase_ct.c", __zend_lineno=1302,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/tmp/php-4.4.4/Zend/zend_alloc.c:187
#2 0x002a956842cc in php_sybase_fetch_result_set
(sybase_ptr=0x6eab50, buffered=0, store=1) at
/tmp/php-4.4.4/ext/sybase_ct/php_sybase_ct.c:1302
#3 0x002a95684cbf in php_sybase_query (ht=2, return_value=0x6fa0b0,
this_ptr=0x0, return_value_used=1, buffered=0)
at /tmp/php-4.4.4/ext/sybase_ct/php_sybase_ct.c:1497
#4 0x002a9568500f in zif_sybase_query (ht=2, return_value=0x6fa0b0,
this_ptr=0x0, return_value_used=1)
at /tmp/php-4.4.4/ext/sybase_ct/php_sybase_ct.c:1626
#5 0x002a9570cab3 in execute (op_array=0x6ea9c0) at
/tmp/php-4.4.4/Zend/zend_execute.c:1675
#6 0x002a956f538f in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /tmp/php-4.4.4/Zend/zend.c:934
#7 0x002a956b5844 in php_execute_script (primary_file=0x7fb270)
at /tmp/php-4.4.4/main/main.c:1752
#8 0x002a95713453 in php_handler (r=0x6db570) at
/tmp/php-4.4.4/sapi/apache2handler/sapi_apache2.c:581
#9 0x0043ca93 in ap_run_handler (r=0x6db570) at config.c:152
#10 0x0043cf31 in ap_invoke_handler (r=0x6db570) at config.c:364
#11 0x0042b360 in ap_process_request (r=0x6db570) at
http_request.c:249
#12 0x00426728 in ap_process_http_connection (c=0x6d6dd0) at
http_core.c:253
#13 0x004475d3 in ap_run_process_connection (c=0x6d6dd0) at
connection.c:43
#14 0x0043af1f in child_main (child_num_arg=Variable
"child_num_arg" is not available.
) at prefork.c:610
#15 0x0043b154 in make_child (s=0x5eda50, slot=0) at
prefork.c:650
#16 0x0043b22e in startup_children (number_to_start=5) at
prefork.c:722
#17 0x0043b90b in ap_mpm_run (_pconf=Variable "_pconf" is not
available.
) at prefork.c:941
#18 0x00441b70 in main (argc=2, argv=0x7fb878) at main.c:623
--
Edit bug report at http://bugs.php.net/?id=39871&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39871&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39871&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39871&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39871&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39871&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39871&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39871&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39871&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39871&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39871&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39871&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39871&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39871&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39871&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39871&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=
#39870 [Opn->Bgs]: Unable to load dynamic library
ID: 39870 Updated by: [EMAIL PROTECTED] Reported By: j dot ohnheiser at gmx dot de -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: Windows XP PHP Version: 5.2.0 New Comment: Because those modules require client libraries. Please read appropriate pages in the documentation to figure out how to install properly the required libraries. Previous Comments: [2006-12-18 15:23:18] j dot ohnheiser at gmx dot de Description: I've a clean php 5.2.0 install on my new System with a fresh Windows installation and I've this Problem: PHP Warning: PHP Startup: 'C:\\PHP5\\ext\\php_mssql.dll' - The specified module could not be found. PHP Warning: PHP Startup: 'C:\\PHP5\\ext\\php_mysql.dll' - The specified module could not be found. PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP5\\ext\\php_oci8.dll' - The specified module could not be found. The Files are all there. And phpinfo() says it is using C:\windows\php.ini. Why? I ditn't mixed PHP installations because the System is brand new. -- Edit this bug report at http://bugs.php.net/?id=39870&edit=1
#39822 [Asn->Sus]: new PDO() doesn't work with firebird
ID: 39822
Updated by: [EMAIL PROTECTED]
Reported By: bx at clansphere dot de
-Status: Assigned
+Status: Suspended
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2006-12-13 (snap)
Assigned To: wez
New Comment:
Looking for a maintainer
Previous Comments:
[2006-12-13 22:08:25] bx at clansphere dot de
Description:
using try/catch doesn't work for firebird like it works with other
rdbms extensions. i think the problem is that firebird returns
something (NULL) so that try expects all went well, but it is not
checking for the PDO object itself.
i am using is_object() currently to look for errors, but that way i
can't get errorcodes like 'database does not exist' for example and
even when track_errors is enabled $php_errormsg is empty.
Reproduce code:
---
try {
$connection = new PDO('firebird:dbname=test.fdb', $user,
$password);
}
catch(PDOException $error) {
echo $error->getMessage();
}
Expected result:
catch can be called to get the exact error
Actual result:
--
try statement thinks everything is ok
--
Edit this bug report at http://bugs.php.net/?id=39822&edit=1
#39870 [NEW]: Unable to load dynamic library
From: j dot ohnheiser at gmx dot de Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: Dynamic loading Bug description: Unable to load dynamic library Description: I've a clean php 5.2.0 install on my new System with a fresh Windows installation and I've this Problem: PHP Warning: PHP Startup: 'C:\\PHP5\\ext\\php_mssql.dll' - The specified module could not be found. PHP Warning: PHP Startup: 'C:\\PHP5\\ext\\php_mysql.dll' - The specified module could not be found. PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP5\\ext\\php_oci8.dll' - The specified module could not be found. The Files are all there. And phpinfo() says it is using C:\windows\php.ini. Why? I ditn't mixed PHP installations because the System is brand new. -- Edit bug report at http://bugs.php.net/?id=39870&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39870&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39870&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39870&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39870&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39870&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39870&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39870&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39870&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39870&r=support Expected behavior:http://bugs.php.net/fix.php?id=39870&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39870&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39870&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39870&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39870&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39870&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39870&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39870&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39870&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39870&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39870&r=mysqlcfg
#39869 [NEW]: safe_read does not initialize errno
From: michiel at boland dot org Operating system: Solaris PHP version: 5.2.0 PHP Bug Type: CGI related Bug description: safe_read does not initialize errno Description: When using PHP in FastCGI mode, PHP has a tendency to once in a while spin in a tight loop, hogging the cpu. The fix is to initialize errno to 0 before any call to read() in the safe_read function in sapi/cgi/fastcgi.c Reproduce code: --- Not applicable Expected result: n.a. Actual result: -- n.a. -- Edit bug report at http://bugs.php.net/?id=39869&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39869&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39869&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39869&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39869&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39869&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39869&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39869&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39869&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39869&r=support Expected behavior:http://bugs.php.net/fix.php?id=39869&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39869&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39869&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39869&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39869&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39869&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39869&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39869&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39869&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39869&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39869&r=mysqlcfg
#39850 [Asn->Csd]: SplFileObject contradictory "failed to open stream: Success"
ID: 39850 Updated by: [EMAIL PROTECTED] Reported By: judas dot iscariote at gmail dot com -Status: Assigned +Status: Closed Bug Type: Filesystem function related Operating System: Linux 64bit PHP Version: 5CVS-2006-12-16 (CVS) Assigned To: tony2001 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-12-18 11:08:13] [EMAIL PROTECTED] I got a patch, but I want to hear what Ilia thinks about it first.. http://tony2001.phpclub.net/dev/tmp/bug39850.diff [2006-12-16 07:08:35] judas dot iscariote at gmail dot com Description: A funny Exception is raised by SplFileObject on certain special situation. Reproduce code: --- Expected result: PHP Fatal error: Uncaught exception 'RuntimeException' with message 'SplFileObject::__construct(php://stdoutd): failed to open stream: (Invalid Wrapper ? , File not found ? or something ;) ) Actual result: -- PHP Fatal error: Uncaught exception 'RuntimeException' with message 'SplFileObject::__construct(php://stdoutd): failed to open stream: **Success** or in other cases without the get_included_files() call I get "Inappropriate ioctl for device" (!!) -- Edit this bug report at http://bugs.php.net/?id=39850&edit=1
#39868 [Opn->Fbk]: Destructor is called allthought constructor is never called
ID: 39868
Updated by: [EMAIL PROTECTED]
Reported By: jb at ez dot no
-Status: Open
+Status: Feedback
-Bug Type: *General Issues
+Bug Type: Unknown/Other Function
Operating System: Kubuntu 6.10
PHP Version: 5.2.0
New Comment:
I don't see anything wrong here.
With "$b = new Child(); $a = new Master( $b );" the second line does
not get executed, of course you won't see any of Master methods
called.
But "$a = new Master( new Child() );" is totally different case -
Master::__construct() is called, you don't see the output because the
exception is thrown just before you print it.
Previous Comments:
[2006-12-18 14:31:19] jb at ez dot no
Description:
It is possible for PHP to call the __destruct() on an
object allthough __construct() was never called. This
seems to happen when having nested object creations and
the inner one throws and exception in the constructor.
The attached reproducable code shows the problem:
Child::__construct() [Child]
Master::__destruct() [Master]
If the last line is changed to:
$b = new Child(); $a = new Master( $b );
it works of course.
In general destructors should never be called if the
constructor was not called or even if it did not finish.
Reproduce code:
---
class Master {
public function __construct( $child ) {
echo __CLASS__, "::__construct() [", get_class( $this ),
"]\n";
}
public function __destruct() {
echo __CLASS__, "::__destruct() [", get_class( $this ), "]\n";
}
}
class Child {
public function __construct() {
echo __CLASS__, "::__construct() [", get_class( $this ),
"]\n";
throw new Exception( "Child failure" );
}
public function __destruct() {
echo __CLASS__, "::__destruct() [", get_class( $this ), "]\n";
}
}
$a = new Master( new Child() );
Expected result:
Child::__construct() [Child]
Actual result:
--
Child::__construct() [Child]
Master::__destruct() [Master]
--
Edit this bug report at http://bugs.php.net/?id=39868&edit=1
#39832 [Asn->Csd]: SOAP Server: parameter not matching the WSDL specified type are set to 0
ID: 39832 Updated by: [EMAIL PROTECTED] Reported By: ebourlon at mail dot mobistar dot be -Status: Assigned +Status: Closed Bug Type: SOAP related Operating System: Win32 PHP Version: 5.2.0 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_2. Previous Comments: [2006-12-14 12:25:27] ebourlon at mail dot mobistar dot be Description: Assume you have a WSDL including the following ComplexType If you build a SOAP server based on this WSDL and send a SOAP request to it the SOAP server will validate the SOAP request against the WSDL. In the above example if your request contains a priority attribute containing a string for instance, the expected behaviour would be that the SOAP server raises an exception because the attribute does not match the defined type. What it does instead is that it will put the priority attribute value to 0 and I don't find any way to find back the fact that a problem with WSDL validation occured. It is a bug or is it a way at SOAP server code level to know that WSDL validation passed? Br, Eric Bourlon -- Edit this bug report at http://bugs.php.net/?id=39832&edit=1
#39868 [NEW]: Destructor is called allthought constructor is never called
From: jb at ez dot no
Operating system: Kubuntu 6.10
PHP version: 5.2.0
PHP Bug Type: *General Issues
Bug description: Destructor is called allthought constructor is never called
Description:
It is possible for PHP to call the __destruct() on an
object allthough __construct() was never called. This
seems to happen when having nested object creations and
the inner one throws and exception in the constructor.
The attached reproducable code shows the problem:
Child::__construct() [Child]
Master::__destruct() [Master]
If the last line is changed to:
$b = new Child(); $a = new Master( $b );
it works of course.
In general destructors should never be called if the
constructor was not called or even if it did not finish.
Reproduce code:
---
class Master {
public function __construct( $child ) {
echo __CLASS__, "::__construct() [", get_class( $this ), "]\n";
}
public function __destruct() {
echo __CLASS__, "::__destruct() [", get_class( $this ), "]\n";
}
}
class Child {
public function __construct() {
echo __CLASS__, "::__construct() [", get_class( $this ), "]\n";
throw new Exception( "Child failure" );
}
public function __destruct() {
echo __CLASS__, "::__destruct() [", get_class( $this ), "]\n";
}
}
$a = new Master( new Child() );
Expected result:
Child::__construct() [Child]
Actual result:
--
Child::__construct() [Child]
Master::__destruct() [Master]
--
Edit bug report at http://bugs.php.net/?id=39868&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39868&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39868&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39868&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39868&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39868&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39868&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39868&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39868&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39868&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39868&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39868&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39868&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39868&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39868&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39868&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39868&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39868&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39868&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39868&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39868&r=mysqlcfg
#39866 [Opn->Bgs]: simpleXMLElement == behaviur changed
ID: 39866
Updated by: [EMAIL PROTECTED]
Reported By: liatb at marvell dot com
-Status: Open
+Status: Bogus
Bug Type: SimpleXML related
Operating System: windows
PHP Version: 5.2.0
New Comment:
That's right. Object are equal only if they point to the same libxml2
data.
You must cast the objects to strings first if you want to compare them
as strings.
See "Example 5" at http://php.net/simplexml.
Previous Comments:
[2006-12-18 13:22:03] liatb at marvell dot com
Description:
I upgraded my PHP version from 5.1.* to 5.2.0
XML string loaded into two different simpleXML objects.
The result of comparing xml node attributes (without any specific cast)
in version 5.2.0 is different then used to be in 5.0.3 and 5.1.5.
I also checked the last snapshot for windows marked as "PHP Version
5.2.1RC2-dev" and got the same output as 5.2.0
Reproduce code:
---
hello";
$xml_1 = simplexml_load_string($xmlStr);
$xml_2 = simplexml_load_string($xmlStr);
var_dump($xml_1);
var_dump($xml_2);
print("");
if($xml_1['id'] == $xml_2['id']) {
print("equal ids");
}
else
{
print("not equal ids");
}
print("");
if($xml_1->name == $xml_2->name)
{
print("equal names");
}
else
{
print("not equal names");
}
?>
Expected result:
equal ids
equal names
Actual result:
--
not equal ids
not equal names
--
Edit this bug report at http://bugs.php.net/?id=39866&edit=1
#39867 [Opn->Asn]: Openssl: add wrapper functions for PKCS#12 handling
ID: 39867 Updated by: [EMAIL PROTECTED] Reported By: delling at silpion dot de -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: all PHP Version: 5.2.0 Assigned To: pajoye Previous Comments: [2006-12-18 13:36:46] delling at silpion dot de Description: Implements OpenSSL-wrapper functions for PKCS#12 handling. bool openssl_pkcs12_export_to_file(mixed x509, string filename, mixed priv_key, string pass[, array args]) bool openssl_pkcs12_export(mixed x509, string &out, mixed priv_key, string pass[, array args]) bool openssl_pkcs12_read(mixed PKCS12, array &certs, string pass) see posting: http://news.php.net/php.internals/26976 and http://news.php.net/php.internals/26984 the patch: http://news.php.net/getpart.php? group=php.internals&article=26976&part=3 -- Edit this bug report at http://bugs.php.net/?id=39867&edit=1
#39867 [NEW]: Openssl: add wrapper functions for PKCS#12 handling
From: delling at silpion dot de Operating system: all PHP version: 5.2.0 PHP Bug Type: Feature/Change Request Bug description: Openssl: add wrapper functions for PKCS#12 handling Description: Implements OpenSSL-wrapper functions for PKCS#12 handling. bool openssl_pkcs12_export_to_file(mixed x509, string filename, mixed priv_key, string pass[, array args]) bool openssl_pkcs12_export(mixed x509, string &out, mixed priv_key, string pass[, array args]) bool openssl_pkcs12_read(mixed PKCS12, array &certs, string pass) see posting: http://news.php.net/php.internals/26976 and http://news.php.net/php.internals/26984 the patch: http://news.php.net/getpart.php? group=php.internals&article=26976&part=3 -- Edit bug report at http://bugs.php.net/?id=39867&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39867&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39867&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39867&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39867&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39867&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39867&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39867&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39867&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39867&r=support Expected behavior:http://bugs.php.net/fix.php?id=39867&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39867&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39867&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39867&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39867&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39867&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39867&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39867&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39867&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39867&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39867&r=mysqlcfg
#39825 [Fbk->Opn]: foreach produces memory error
ID: 39825 User updated by: krejci at ped dot muni dot cz Reported By: krejci at ped dot muni dot cz -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: WinXP, Win2003 PHP Version: 5CVS-2006-12-13 (snap) New Comment: Unhandled exception at 0x100156e3 (php5ts.dll) in php-win.exe: 0xC005: Access violation reading location 0x. > php5ts.dll!zend_unmangle_property_name(char * mangled_property=0x, int len=222407, char * * class_name=0x00c0fae4, char * * prop_name=0x00c0fae8) Line 2925 + 0xb bytes C php5ts.dll!zend_check_property_access(_zend_object * zobj=0x011ed090, char * prop_info_name=0x, int prop_info_name_len=222407, void * * * tsrm_ls=0x00033fe0) Line 255 C php5ts.dll!ZEND_FE_RESET_SPEC_CV_HANDLER(_zend_execute_data * execute_data=0x00c0fb20, void * * * tsrm_ls=0x011ed0d8) Line 19956 + 0x16 bytes C php5ts.dll!execute(_zend_op_array * op_array=0x01ae9e80, void * * * tsrm_ls=0x00030178) Line 92 + 0xc bytesC ntdll.dll!7c911ad6() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] php5ts.dll!_emalloc(unsigned int size=12647496) Line 1706 + 0x18 bytes C php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x00c0fe9c, void * * * tsrm_ls=0x00033fe0) Line 1752 + 0xd bytes C php-win.exe!WinMain(HINSTANCE__ * hInstance=0x0040, HINSTANCE__ * hPrevInstance=0x, char * lpCmdLine=0x000522d0, int nShowCmd=10) Line 1109 C php-win.exe!_WinMainCRTStartup() + 0x134 bytes kernel32.dll!7c816fd7() Previous Comments: [2006-12-18 10:38:01] [EMAIL PROTECTED] 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. [2006-12-13 23:29:22] krejci at ped dot muni dot cz Description: Our production site with LMS Moodle is haunted by this PHP crash since upgrade to php 5.20. tested on: IIS 5.1, IIS 6.0 PHP 5.20, PHP 5.21dev 2006-12-13 all modules except php_mysql.dll turned off I was able to track it down to one "foreach" line, that is processing mysql object. Reproduce code: --- http://moodlinka.ped.muni.cz/data/moodle2.sql.txt http://moodlinka.ped.muni.cz/data/mod2.php.txt Expected result: standard error message Actual result: -- ISAPI: PHP has encountered an Access Violation at 010256E3 CGI: php-cgi.exe - Application Error The instruction at "0x10015613" referenced memory at "0x0001". The memory could not be "read". -- Edit this bug report at http://bugs.php.net/?id=39825&edit=1
#39866 [NEW]: simpleXMLElement == behaviur changed
From: liatb at marvell dot com
Operating system: windows
PHP version: 5.2.0
PHP Bug Type: SimpleXML related
Bug description: simpleXMLElement == behaviur changed
Description:
I upgraded my PHP version from 5.1.* to 5.2.0
XML string loaded into two different simpleXML objects.
The result of comparing xml node attributes (without any specific cast) in
version 5.2.0 is different then used to be in 5.0.3 and 5.1.5.
I also checked the last snapshot for windows marked as "PHP Version
5.2.1RC2-dev" and got the same output as 5.2.0
Reproduce code:
---
hello";
$xml_1 = simplexml_load_string($xmlStr);
$xml_2 = simplexml_load_string($xmlStr);
var_dump($xml_1);
var_dump($xml_2);
print("");
if($xml_1['id'] == $xml_2['id']) {
print("equal ids");
}
else
{
print("not equal ids");
}
print("");
if($xml_1->name == $xml_2->name)
{
print("equal names");
}
else
{
print("not equal names");
}
?>
Expected result:
equal ids
equal names
Actual result:
--
not equal ids
not equal names
--
Edit bug report at http://bugs.php.net/?id=39866&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39866&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39866&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39866&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39866&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39866&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39866&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39866&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39866&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39866&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39866&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39866&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39866&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39866&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39866&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39866&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39866&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39866&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39866&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39866&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39866&r=mysqlcfg
#39809 [Asn->Fbk]: FastCGI Requests silently dropped
ID: 39809
Updated by: [EMAIL PROTECTED]
Reported By: e at osterman dot com
-Status: Assigned
+Status: Feedback
Bug Type: CGI related
Operating System: FC6
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
No you are :)
But you made a great job writting test script, and I think this
discussion may lead us to some good result.
The fact that connect() returns file descriptor doesn't mean that
accept() was really called. See the folllowing script. You can even
write to socket befor it is really accepted.
Previous Comments:
[2006-12-15 21:35:04] e at osterman dot com
> PHP process DOESN'T accept() new connections
> if it already has persistent connection opened.
> Note that php/fastcgi is one-process-one-connection
> server that doesn't implement multiplexion
If this were actually the case, I'd be satisfied. That would mean the
FCGI clients would get "connection refused" when there are no more
sockets/children available. But what actually happens is that the
connection is established, meaning accept() does get called.
To test this, modify the example like this
// Open up the first connection
$socket1 = FCGI_Connect('localhost', 1234);
// Send a request with FCGI_KEEP_CONN
FCGI_Test($socket1);
// Open up the second connection (should be refused)
$socket2 = FCGI_Connect('localhost', 1234);
printf("socket1:%d socket2:%d\n", feof($socket1), feof($socket2));
Expected output:
socket1:0 socket2:1
Actual output:
socket1:0 socket2:0
In otherwords, both connections are established => accept() was
called.
Am I making sense?
Regards,
Erik Osterman
[2006-12-15 15:00:55] [EMAIL PROTECTED]
> it simply accepts/ignores them
PHP process DOESN'T accept() new connections if it already has
persistent connection opened. Note that php/fastcgi is
one-process-one-connection server that doesn't implement multiplexion
(like apache 1.3).
PHP doesn't try to manage persistent connection itself, however FastCGI
module may do it (especially in multithreaded environment).
[2006-12-13 21:26:46] e at osterman dot com
I know if you open up 1 socket to one child, it works:
> If you only open up 1 socket, and run multiple requests > it works
fine.
That's not the bug. The bug is PHP doesn't handle persistent
connections (FCGI_KEEP_CONN), when the number of persistent connections
exceedes the number of php children. The fcgi spec states that if the
application doesn't have enough resoures to complete the request (e.g
database handles, or in the case of PHP enough children), that it
should return that it's overloaded. PHP does not do this; it simply
accepts/ignores them. What PHP does is rely on the connection queueing,
which doesn't solve the KEEP_CONN problem. Constantly opening up
connections is inefficient.
Regards,
Erik Osterman
[2006-12-13 14:44:51] [EMAIL PROTECTED]
In your example you use persistent FastCGI connections
(FCGI_KEEP_CONN). It means web server connects to PHP and sends SEVERAL
requests using the SAME socket then it can close connection. You can
correct your example in the following way to use persistent conection:
$socket1 = FCGI_Connect('localhost', 1234);
FCGI_Test($socket1);
FCGI_Response($socket1);
FCGI_Test($socket1);
FCGI_Response($socket1);
or you may not to use persistent connection and then you must close
connection
$socket1 = FCGI_Connect('localhost', 1234);
FCGI_Test($socket1);
FCGI_Response($socket1);
fclose($socket1);
$socket2 = FCGI_Connect('localhost', 1234);
FCGI_Test($socket2);
FCGI_Response($socket2);
fclose($socket2);
In case of non-persistent connection usgage of shutdown() right after
sending request is much better then close() after reading response.
[2006-12-13 06:55:06] e at osterman dot com
Reproduce Code:
> 24) | 0x80) . chr(($nlen >> 16) & 0xFF) .
chr(($nlen >> 8) & 0xFF) . chr($nlen & 0xFF);
if ($vlen < 128)
$nvpair .= chr($vlen);
else
$nvpair .= chr(($vlen >> 24) | 0x80) . chr(($vlen >> 16) & 0xFF) .
chr(($vlen >> 8) & 0xFF) . chr($vlen & 0xFF);
return $nvpair . $name . $value;
}
function FCGI_Decode($data)
{
if( strlen($data) < 8 )
die("Packet too small " . strlen($data) . "\n");
$length = (ord($data{4}) << 8)+ord($data{5});
$packet = Array( 'version' => ord($data{0}),
'type'=> ord($data{1}),
'length' => $length,
'content' => substr($data, 8, $length) );
return $packet;
}
function FCGI_Connect($host, $port) {
// Connect to FastCGI server
$socket = fsockopen($host, $port, $errno, $errstr, 5);
if( !$socket )
die("Failed t
#39858 [Com]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858 Comment by: mike at we11er dot co dot uk Reported By: develar at gmail dot com Status: Assigned Bug Type: PDO related Operating System: Windows XP SP2 PHP Version: 5.2.0 Assigned To: wez New Comment: Here are two more bug reports on pecl: http://pecl.php.net/bugs/bug.php?id=7976 http://pecl.php.net/bugs/bug.php?id=5827 Again it seems intermittant with some people. I got a SQL error log which showed this: 061213 11:27:36 [Warning] Aborted connection 1 to db: 'test' user: 'test' host: 'localhost' (Got an error reading communication packets) Before anyone asks, I have been rd /s'ing the PHP directory when I try a snapshot to make sure I'm running a clean version of everything. Adding $this->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, TRUE); does not stop the error. nextRowset() isn't implemented so we can't fetch all the results manually. That is all. Previous Comments: [2006-12-18 12:18:06] mike at we11er dot co dot uk I'm having this issue as well. My bug report here: http://bugs.php.net/bug.php?id=39759 has some more information. To recap: I've tested this with php 5.2 release, as well as various recent snapshots. I've tested with mysql 5.0.22 and 5.0.27. I've tested with the libmysql.dll files that php ships with, as well as the libmysql.dll that mysql ships with - they produce two different errors but the problem is the same. When using PHP's libmysql.dll the error is: SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server during query When using MySQL's libmysql.dll the error is: SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. When running through apache I get this error 100% of the time. When running through the PHP command line interface, I get it about 50% of the time, so perhaps there are performance issues here. I'm running on a celeron 2.4GHz with 512 ram. Windows XP. Please fix this! [2006-12-18 09:28:00] develar at gmail dot com Почитайте http://phpclub.ru/talk/showthread.php?s=&threadid=92764&rand=10 It always worked normally on linux. My first message: "I read #35333 #35637 #35203, but why the given code fine works in Debian?" Only in windows. [2006-12-18 09:20:54] [EMAIL PROTECTED] Works just fine on Linux. Make sure you're really running the snapshot. [2006-12-18 08:43:52] develar at gmail dot com It is not fixed. [2006-12-18 08:34:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip 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/39858 -- Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#39858 [Com]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Comment by: mike at we11er dot co dot uk
Reported By: develar at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
Assigned To: wez
New Comment:
I'm having this issue as well.
My bug report here: http://bugs.php.net/bug.php?id=39759 has some more
information. To recap:
I've tested this with php 5.2 release, as well as various recent
snapshots. I've tested with mysql 5.0.22 and 5.0.27. I've tested with
the libmysql.dll files that php ships with, as well as the libmysql.dll
that mysql ships with - they produce two different errors but the
problem is the same.
When using PHP's libmysql.dll the error is: SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query
When using MySQL's libmysql.dll the error is: SQLSTATE[HY000]: General
error: 2014 Cannot execute queries while other
unbuffered queries are active.
When running through apache I get this error 100% of the time. When
running through the PHP command line interface, I get it about 50% of
the time, so perhaps there are performance issues here. I'm running on
a celeron 2.4GHz with 512 ram. Windows XP.
Please fix this!
Previous Comments:
[2006-12-18 09:28:00] develar at gmail dot com
Почитайте
http://phpclub.ru/talk/showthread.php?s=&threadid=92764&rand=10
It always worked normally on linux. My first message: "I read #35333
#35637 #35203, but why the given code
fine works in Debian?" Only in windows.
[2006-12-18 09:20:54] [EMAIL PROTECTED]
Works just fine on Linux.
Make sure you're really running the snapshot.
[2006-12-18 08:43:52] develar at gmail dot com
It is not fixed.
[2006-12-18 08:34:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-12-17 14:30:25] develar at gmail dot com
Description:
The second call stored procedures causes an error "SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query" with
probability of 50%. I read #35333 #35637 #35203, but why the given code
fine works in Debian?
Reproduce code:
---
CREATE PROCEDURE `foo`()
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
SELECT 2 * 2;
END;
"SET NAMES 'utf8'",
PDO::ATTR_PERSISTENT => true));
$Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo->closeCursor();
?>
Expected result:
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Actual result:
--
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query in C:\home\test\www\pdo.php on line 12
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#39850 [Opn->Asn]: SplFileObject contradictory "failed to open stream: Success"
ID: 39850 Updated by: [EMAIL PROTECTED] Reported By: judas dot iscariote at gmail dot com -Status: Open +Status: Assigned -Bug Type: SPL related +Bug Type: Filesystem function related Operating System: Linux 64bit PHP Version: 5CVS-2006-12-16 (CVS) -Assigned To: +Assigned To: tony2001 New Comment: I got a patch, but I want to hear what Ilia thinks about it first.. http://tony2001.phpclub.net/dev/tmp/bug39850.diff Previous Comments: [2006-12-16 07:08:35] judas dot iscariote at gmail dot com Description: A funny Exception is raised by SplFileObject on certain special situation. Reproduce code: --- Expected result: PHP Fatal error: Uncaught exception 'RuntimeException' with message 'SplFileObject::__construct(php://stdoutd): failed to open stream: (Invalid Wrapper ? , File not found ? or something ;) ) Actual result: -- PHP Fatal error: Uncaught exception 'RuntimeException' with message 'SplFileObject::__construct(php://stdoutd): failed to open stream: **Success** or in other cases without the get_included_files() call I get "Inappropriate ioctl for device" (!!) -- Edit this bug report at http://bugs.php.net/?id=39850&edit=1
#39809 [Opn->Asn]: FastCGI Requests silently dropped
ID: 39809
Updated by: [EMAIL PROTECTED]
Reported By: e at osterman dot com
-Status: Open
+Status: Assigned
Bug Type: CGI related
Operating System: FC6
PHP Version: 5.2.0
Assigned To: dmitry
Previous Comments:
[2006-12-15 21:35:04] e at osterman dot com
> PHP process DOESN'T accept() new connections
> if it already has persistent connection opened.
> Note that php/fastcgi is one-process-one-connection
> server that doesn't implement multiplexion
If this were actually the case, I'd be satisfied. That would mean the
FCGI clients would get "connection refused" when there are no more
sockets/children available. But what actually happens is that the
connection is established, meaning accept() does get called.
To test this, modify the example like this
// Open up the first connection
$socket1 = FCGI_Connect('localhost', 1234);
// Send a request with FCGI_KEEP_CONN
FCGI_Test($socket1);
// Open up the second connection (should be refused)
$socket2 = FCGI_Connect('localhost', 1234);
printf("socket1:%d socket2:%d\n", feof($socket1), feof($socket2));
Expected output:
socket1:0 socket2:1
Actual output:
socket1:0 socket2:0
In otherwords, both connections are established => accept() was
called.
Am I making sense?
Regards,
Erik Osterman
[2006-12-15 15:00:55] [EMAIL PROTECTED]
> it simply accepts/ignores them
PHP process DOESN'T accept() new connections if it already has
persistent connection opened. Note that php/fastcgi is
one-process-one-connection server that doesn't implement multiplexion
(like apache 1.3).
PHP doesn't try to manage persistent connection itself, however FastCGI
module may do it (especially in multithreaded environment).
[2006-12-13 21:26:46] e at osterman dot com
I know if you open up 1 socket to one child, it works:
> If you only open up 1 socket, and run multiple requests > it works
fine.
That's not the bug. The bug is PHP doesn't handle persistent
connections (FCGI_KEEP_CONN), when the number of persistent connections
exceedes the number of php children. The fcgi spec states that if the
application doesn't have enough resoures to complete the request (e.g
database handles, or in the case of PHP enough children), that it
should return that it's overloaded. PHP does not do this; it simply
accepts/ignores them. What PHP does is rely on the connection queueing,
which doesn't solve the KEEP_CONN problem. Constantly opening up
connections is inefficient.
Regards,
Erik Osterman
[2006-12-13 14:44:51] [EMAIL PROTECTED]
In your example you use persistent FastCGI connections
(FCGI_KEEP_CONN). It means web server connects to PHP and sends SEVERAL
requests using the SAME socket then it can close connection. You can
correct your example in the following way to use persistent conection:
$socket1 = FCGI_Connect('localhost', 1234);
FCGI_Test($socket1);
FCGI_Response($socket1);
FCGI_Test($socket1);
FCGI_Response($socket1);
or you may not to use persistent connection and then you must close
connection
$socket1 = FCGI_Connect('localhost', 1234);
FCGI_Test($socket1);
FCGI_Response($socket1);
fclose($socket1);
$socket2 = FCGI_Connect('localhost', 1234);
FCGI_Test($socket2);
FCGI_Response($socket2);
fclose($socket2);
In case of non-persistent connection usgage of shutdown() right after
sending request is much better then close() after reading response.
[2006-12-13 06:55:06] e at osterman dot com
Reproduce Code:
> 24) | 0x80) . chr(($nlen >> 16) & 0xFF) .
chr(($nlen >> 8) & 0xFF) . chr($nlen & 0xFF);
if ($vlen < 128)
$nvpair .= chr($vlen);
else
$nvpair .= chr(($vlen >> 24) | 0x80) . chr(($vlen >> 16) & 0xFF) .
chr(($vlen >> 8) & 0xFF) . chr($vlen & 0xFF);
return $nvpair . $name . $value;
}
function FCGI_Decode($data)
{
if( strlen($data) < 8 )
die("Packet too small " . strlen($data) . "\n");
$length = (ord($data{4}) << 8)+ord($data{5});
$packet = Array( 'version' => ord($data{0}),
'type'=> ord($data{1}),
'length' => $length,
'content' => substr($data, 8, $length) );
return $packet;
}
function FCGI_Connect($host, $port) {
// Connect to FastCGI server
$socket = fsockopen($host, $port, $errno, $errstr, 5);
if( !$socket )
die("Failed to connect to $host:$port\n");
return $socket;
}
function FCGI_Test($socket)
{
// Begin session
$packet = '';
$packet .= FCGI_Packet(FCGI_BEGIN_REQUEST,
chr(0).chr(FCGI_RESPONDER).chr(FCGI_KEEP_CONN).chr(0).chr(0).chr(0).chr(0).chr(0)
);
// Build params
$params = '';
$params .= FCGI_NVPair('GATEWAY_INTERFACE
#39833 [Opn->Fbk]: Session variables overwritten by local variables (register_globals=off)
ID: 39833 Updated by: [EMAIL PROTECTED] Reported By: sup1382 at accedo dot es -Status: Open +Status: Feedback Bug Type: Session related Operating System: OpenBSD 3.9 PHP Version: 5.2.0 New Comment: . Previous Comments: [2006-12-15 11:49:47] sup1382 at accedo dot es If you have any webmail (Gmail-Hotmail, etc) account I'll send you again the URLs, or I'll wait no problem. [2006-12-15 11:46:31] [EMAIL PROTECTED] I am currently away from my computer and don't have access to my mailbox. [2006-12-15 11:31:43] sup1382 at accedo dot es I've send you by mail the URLs, I've forgotten to write here that this script was running under a SSL connection, this seems to be a important fact becouse testing under the standard port doesn't produce any errors, this appears only under SSL, as you can see in the URLs. [2006-12-15 11:10:54] sup1382 at accedo dot es Ups, this is a hosting production server I prefer, too much server info to disclose it to the public, if it is posible I'll send you by mail the url [2006-12-15 09:55:29] [EMAIL PROTECTED] Add phpinfo() to end of this code and put the URL here. 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/39833 -- Edit this bug report at http://bugs.php.net/?id=39833&edit=1
#39824 [Opn->Bgs]: mysql_free_result warning
ID: 39824 Updated by: [EMAIL PROTECTED] Reported By: marcos dot neves at gmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: WINXP PHP Version: 5.2.0 New Comment: >Does this error still happens before 5.2? Sure it does. Just enable trace_mode and you'll see it. >Why no warning before? Because you did not enable mysql.trace_mode before. Previous Comments: [2006-12-18 10:38:08] marcos dot neves at gmail dot com Hide the error msg doesn´t means the error has gone. Does this error still happens before 5.2? Why no warning before? The docs are very clear: "only needs to be called if you are concerned about how much memory is being used for queries that return large result sets. All associated result memory is automatically freed at the end of the script's execution" I hope that this "trick" of hide error messages to "fixes" then, not be used at PHP core code :( [2006-12-18 08:38:48] [EMAIL PROTECTED] Set mysql.trace_mode to Off in your php.ini. [2006-12-13 23:20:33] marcos dot neves at gmail dot com Description: Starting with mysql 5.2.0, mysql_free_result is required be called before end of script Reproduce code: --- Expected result: no warnings, the results should be disposed at end of script, as documentantion saids and as like was before. Actual result: -- Warning: Unknown: 1 result set(s) not freed. Use mysql_free_result to free result sets which were requested using mysql_query() in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=39824&edit=1
#39822 [Opn->Asn]: new PDO() doesn't work with firebird
ID: 39822
Updated by: [EMAIL PROTECTED]
Reported By: bx at clansphere dot de
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2006-12-13 (snap)
-Assigned To:
+Assigned To: wez
Previous Comments:
[2006-12-13 22:08:25] bx at clansphere dot de
Description:
using try/catch doesn't work for firebird like it works with other
rdbms extensions. i think the problem is that firebird returns
something (NULL) so that try expects all went well, but it is not
checking for the PDO object itself.
i am using is_object() currently to look for errors, but that way i
can't get errorcodes like 'database does not exist' for example and
even when track_errors is enabled $php_errormsg is empty.
Reproduce code:
---
try {
$connection = new PDO('firebird:dbname=test.fdb', $user,
$password);
}
catch(PDOException $error) {
echo $error->getMessage();
}
Expected result:
catch can be called to get the exact error
Actual result:
--
try statement thinks everything is ok
--
Edit this bug report at http://bugs.php.net/?id=39822&edit=1
#39825 [Opn->Fbk]: foreach produces memory error
ID: 39825 Updated by: [EMAIL PROTECTED] Reported By: krejci at ped dot muni dot cz -Status: Open +Status: Feedback -Bug Type: Reproducible crash +Bug Type: Unknown/Other Function Operating System: WinXP, Win2003 PHP Version: 5CVS-2006-12-13 (snap) New Comment: 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. Previous Comments: [2006-12-13 23:29:22] krejci at ped dot muni dot cz Description: Our production site with LMS Moodle is haunted by this PHP crash since upgrade to php 5.20. tested on: IIS 5.1, IIS 6.0 PHP 5.20, PHP 5.21dev 2006-12-13 all modules except php_mysql.dll turned off I was able to track it down to one "foreach" line, that is processing mysql object. Reproduce code: --- http://moodlinka.ped.muni.cz/data/moodle2.sql.txt http://moodlinka.ped.muni.cz/data/mod2.php.txt Expected result: standard error message Actual result: -- ISAPI: PHP has encountered an Access Violation at 010256E3 CGI: php-cgi.exe - Application Error The instruction at "0x10015613" referenced memory at "0x0001". The memory could not be "read". -- Edit this bug report at http://bugs.php.net/?id=39825&edit=1
#39824 [Bgs->Opn]: mysql_free_result warning
ID: 39824 User updated by: marcos dot neves at gmail dot com Reported By: marcos dot neves at gmail dot com -Status: Bogus +Status: Open Bug Type: MySQL related Operating System: WINXP PHP Version: 5.2.0 New Comment: Hide the error msg doesn´t means the error has gone. Does this error still happens before 5.2? Why no warning before? The docs are very clear: "only needs to be called if you are concerned about how much memory is being used for queries that return large result sets. All associated result memory is automatically freed at the end of the script's execution" I hope that this "trick" of hide error messages to "fixes" then, not be used at PHP core code :( Previous Comments: [2006-12-18 08:38:48] [EMAIL PROTECTED] Set mysql.trace_mode to Off in your php.ini. [2006-12-13 23:20:33] marcos dot neves at gmail dot com Description: Starting with mysql 5.2.0, mysql_free_result is required be called before end of script Reproduce code: --- Expected result: no warnings, the results should be disposed at end of script, as documentantion saids and as like was before. Actual result: -- Warning: Unknown: 1 result set(s) not freed. Use mysql_free_result to free result sets which were requested using mysql_query() in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=39824&edit=1
#39402 [Csd->Bgs]: Not able to access the desired cookie
ID: 39402 Updated by: [EMAIL PROTECTED] Reported By: pradeep_elixir at yahoo dot com -Status: Closed +Status: Bogus Bug Type: *General Issues Operating System: LINUX PHP Version: 4.4.4 Previous Comments: [2006-12-18 09:45:09] pradeep_elixir at yahoo dot com It is not related with php rather it is an issue of some privecy policies related to the browser. [2006-11-07 14:13:19] [EMAIL PROTECTED] This is a browser issue, not a bug in PHP. [2006-11-06 15:29:25] pradeep_elixir at yahoo dot com Description: I tried to access cookie from a php file using javascript tag: source = "http://mysite.com/accesscookie.php"; document.write('\<\script language="javascript" src="' + source +'"\>\<\/SCRIPT\>'); The php script could not read the cookie stored for the damain mysite.com Browser is Internet explorer 6.0 When I tred the same url directly in the browser it was able to read the cookie. The problem i am facing for the Internet explorer while it is working fine in Mozila Firefox 1.5.0.7 Reproduce code: --- I tried to access cookie from a php file using javascript tag: source = "http://mysite.com/accesscookie.php"; document.write('\<\script language="javascript" src="' + source +'"\>\<\/SCRIPT\>'); The php script could not read the cookie stored for the damain mysite.com Browser is Internet explorer 6.0 When I tred the same url directly in the browser it was able to read the cookie. The problem i am facing for the Internet explorer while it is working fine in Mozila Firefox 1.5.0.7 -- Edit this bug report at http://bugs.php.net/?id=39402&edit=1
#39864 [Csd->Bgs]: php crush without any report
ID: 39864
Updated by: [EMAIL PROTECTED]
Reported By: khulap at mail dot ru
-Status: Closed
+Status: Bogus
Bug Type: Arrays related
Operating System: Debian
PHP Version: 5.2.0
Previous Comments:
[2006-12-18 09:43:40] khulap at mail dot ru
The problem is absence of __toString() method.
[2006-12-18 09:17:29] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-12-18 09:15:28] khulap at mail dot ru
Description:
PHP crush without any output after use array_unique with complex
objects.
With php 5.1.6 all works ok. With primitive types all works ok.
Reproduce code:
---
echo 'Test1';
var_dump($rel_list);
echo 'Test2';
$rel_list=array_unique($rel_list);
echo 'Test3';
var_dump($rel_list);
echo 'Test4';
Expected result:
Test1array(4) {
[0]=>
object(GroupRelation)#204 (13) {
["id:protected"]=>
int(7)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(4)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[1]=>
object(GroupRelation)#207 (13) {
["id:protected"]=>
int(8)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(1)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[2]=>
object(GroupRelation)#209 (13) {
["id:protected"]=>
int(9)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(14)
["related_by:protected"]=>
int(3)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[3]=>
object(GroupRelation)#210 (13) {
["id:protected"]=>
int(10)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(17)
["related_by:protected"]=>
int(4)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
}
Test2
Test3
array(4) {
[0]=>
object(GroupRelation)#204 (13) {
["id:protected"]=>
int(7)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(4)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[1]=>
object(GroupRelation)#207 (13) {
["id:protected"]=>
int(8)
["gr_child:protected"]=>
#39402 [Bgs->Csd]: Not able to access the desired cookie
ID: 39402 User updated by: pradeep_elixir at yahoo dot com Reported By: pradeep_elixir at yahoo dot com -Status: Bogus +Status: Closed Bug Type: *General Issues Operating System: LINUX PHP Version: 4.4.4 New Comment: It is not related with php rather it is an issue of some privecy policies related to the browser. Previous Comments: [2006-11-07 14:13:19] [EMAIL PROTECTED] This is a browser issue, not a bug in PHP. [2006-11-06 15:29:25] pradeep_elixir at yahoo dot com Description: I tried to access cookie from a php file using javascript tag: source = "http://mysite.com/accesscookie.php"; document.write('\<\script language="javascript" src="' + source +'"\>\<\/SCRIPT\>'); The php script could not read the cookie stored for the damain mysite.com Browser is Internet explorer 6.0 When I tred the same url directly in the browser it was able to read the cookie. The problem i am facing for the Internet explorer while it is working fine in Mozila Firefox 1.5.0.7 Reproduce code: --- I tried to access cookie from a php file using javascript tag: source = "http://mysite.com/accesscookie.php"; document.write('\<\script language="javascript" src="' + source +'"\>\<\/SCRIPT\>'); The php script could not read the cookie stored for the damain mysite.com Browser is Internet explorer 6.0 When I tred the same url directly in the browser it was able to read the cookie. The problem i am facing for the Internet explorer while it is working fine in Mozila Firefox 1.5.0.7 -- Edit this bug report at http://bugs.php.net/?id=39402&edit=1
#39864 [Fbk->Csd]: php crush without any report
ID: 39864
User updated by: khulap at mail dot ru
Reported By: khulap at mail dot ru
-Status: Feedback
+Status: Closed
Bug Type: Arrays related
Operating System: Debian
PHP Version: 5.2.0
New Comment:
The problem is absence of __toString() method.
Previous Comments:
[2006-12-18 09:17:29] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-12-18 09:15:28] khulap at mail dot ru
Description:
PHP crush without any output after use array_unique with complex
objects.
With php 5.1.6 all works ok. With primitive types all works ok.
Reproduce code:
---
echo 'Test1';
var_dump($rel_list);
echo 'Test2';
$rel_list=array_unique($rel_list);
echo 'Test3';
var_dump($rel_list);
echo 'Test4';
Expected result:
Test1array(4) {
[0]=>
object(GroupRelation)#204 (13) {
["id:protected"]=>
int(7)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(4)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[1]=>
object(GroupRelation)#207 (13) {
["id:protected"]=>
int(8)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(1)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[2]=>
object(GroupRelation)#209 (13) {
["id:protected"]=>
int(9)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(14)
["related_by:protected"]=>
int(3)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[3]=>
object(GroupRelation)#210 (13) {
["id:protected"]=>
int(10)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(17)
["related_by:protected"]=>
int(4)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
}
Test2
Test3
array(4) {
[0]=>
object(GroupRelation)#204 (13) {
["id:protected"]=>
int(7)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(4)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[1]=>
object(GroupRelation)#207 (13) {
["id:protected"]=>
int(8)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(1)
["related_by:protected"]=>
NULL
["aGen
#39865 [Bgs]: pear is missing in Source
ID: 39865 User updated by: alfred dot stranimaier at mosser dot at Reported By: alfred dot stranimaier at mosser dot at Status: Bogus Bug Type: *General Issues Operating System: linux PHP Version: 5.2.0 New Comment: This I have already done and get the error: make: *** No rule to make target `install-su'. Stop. Previous Comments: [2006-12-18 09:30:37] [EMAIL PROTECTED] Download the .phar archive and then run `make install-su`. [2006-12-18 09:25:37] alfred dot stranimaier at mosser dot at Description: I have download the snapshot from 17.Dec 2006 and there is no PEAR in the source-code! +--+ | The installation process is incomplete. The following resources were | | not installed: | | | | PEAR: PHP Extension and Application Repository | | | | To install these components, | | download http://pear.php.net/install-pear.phar to php-src/pear/ | | become the superuser and execute: | | | | # make install-su | +--+ then I get the following error: make: *** No rule to make target `install-su'. Stop. -- Edit this bug report at http://bugs.php.net/?id=39865&edit=1
#39858 [Opn->Asn]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Updated by: [EMAIL PROTECTED]
Reported By: develar at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
-Assigned To:
+Assigned To: wez
Previous Comments:
[2006-12-18 09:28:00] develar at gmail dot com
Почитайте
http://phpclub.ru/talk/showthread.php?s=&threadid=92764&rand=10
It always worked normally on linux. My first message: "I read #35333
#35637 #35203, but why the given code
fine works in Debian?" Only in windows.
[2006-12-18 09:20:54] [EMAIL PROTECTED]
Works just fine on Linux.
Make sure you're really running the snapshot.
[2006-12-18 08:43:52] develar at gmail dot com
It is not fixed.
[2006-12-18 08:34:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-12-17 14:30:25] develar at gmail dot com
Description:
The second call stored procedures causes an error "SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query" with
probability of 50%. I read #35333 #35637 #35203, but why the given code
fine works in Debian?
Reproduce code:
---
CREATE PROCEDURE `foo`()
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
SELECT 2 * 2;
END;
"SET NAMES 'utf8'",
PDO::ATTR_PERSISTENT => true));
$Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo->closeCursor();
?>
Expected result:
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Actual result:
--
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query in C:\home\test\www\pdo.php on line 12
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#39865 [Opn->Bgs]: pear is missing in Source
ID: 39865 Updated by: [EMAIL PROTECTED] Reported By: alfred dot stranimaier at mosser dot at -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: linux PHP Version: 5.2.0 New Comment: Download the .phar archive and then run `make install-su`. Previous Comments: [2006-12-18 09:25:37] alfred dot stranimaier at mosser dot at Description: I have download the snapshot from 17.Dec 2006 and there is no PEAR in the source-code! +--+ | The installation process is incomplete. The following resources were | | not installed: | | | | PEAR: PHP Extension and Application Repository | | | | To install these components, | | download http://pear.php.net/install-pear.phar to php-src/pear/ | | become the superuser and execute: | | | | # make install-su | +--+ then I get the following error: make: *** No rule to make target `install-su'. Stop. -- Edit this bug report at http://bugs.php.net/?id=39865&edit=1
#39858 [Fbk->Opn]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
User updated by: develar at gmail dot com
Reported By: develar at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
New Comment:
Почитайте
http://phpclub.ru/talk/showthread.php?s=&threadid=92764&rand=10
It always worked normally on linux. My first message: "I read #35333
#35637 #35203, but why the given code
fine works in Debian?" Only in windows.
Previous Comments:
[2006-12-18 09:20:54] [EMAIL PROTECTED]
Works just fine on Linux.
Make sure you're really running the snapshot.
[2006-12-18 08:43:52] develar at gmail dot com
It is not fixed.
[2006-12-18 08:34:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-12-17 14:30:25] develar at gmail dot com
Description:
The second call stored procedures causes an error "SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query" with
probability of 50%. I read #35333 #35637 #35203, but why the given code
fine works in Debian?
Reproduce code:
---
CREATE PROCEDURE `foo`()
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
SELECT 2 * 2;
END;
"SET NAMES 'utf8'",
PDO::ATTR_PERSISTENT => true));
$Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo->closeCursor();
?>
Expected result:
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Actual result:
--
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query in C:\home\test\www\pdo.php on line 12
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#39865 [NEW]: pear is missing in Source
From: alfred dot stranimaier at mosser dot at Operating system: linux PHP version: 5.2.0 PHP Bug Type: *General Issues Bug description: pear is missing in Source Description: I have download the snapshot from 17.Dec 2006 and there is no PEAR in the source-code! +--+ | The installation process is incomplete. The following resources were | | not installed: | | | | PEAR: PHP Extension and Application Repository | | | | To install these components, | | download http://pear.php.net/install-pear.phar to php-src/pear/ | | become the superuser and execute: | | | | # make install-su | +--+ then I get the following error: make: *** No rule to make target `install-su'. Stop. -- Edit bug report at http://bugs.php.net/?id=39865&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39865&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39865&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39865&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39865&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39865&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39865&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39865&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39865&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39865&r=support Expected behavior:http://bugs.php.net/fix.php?id=39865&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39865&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39865&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39865&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39865&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39865&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39865&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39865&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39865&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39865&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39865&r=mysqlcfg
#39858 [Opn->Fbk]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Updated by: [EMAIL PROTECTED]
Reported By: develar at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
New Comment:
Works just fine on Linux.
Make sure you're really running the snapshot.
Previous Comments:
[2006-12-18 08:43:52] develar at gmail dot com
It is not fixed.
[2006-12-18 08:34:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-12-17 14:30:25] develar at gmail dot com
Description:
The second call stored procedures causes an error "SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query" with
probability of 50%. I read #35333 #35637 #35203, but why the given code
fine works in Debian?
Reproduce code:
---
CREATE PROCEDURE `foo`()
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
SELECT 2 * 2;
END;
"SET NAMES 'utf8'",
PDO::ATTR_PERSISTENT => true));
$Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo->closeCursor();
?>
Expected result:
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Actual result:
--
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query in C:\home\test\www\pdo.php on line 12
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#39864 [Opn->Fbk]: php crush without any report
ID: 39864
Updated by: [EMAIL PROTECTED]
Reported By: khulap at mail dot ru
-Status: Open
+Status: Feedback
Bug Type: Arrays related
Operating System: Debian
PHP Version: 5.2.0
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2006-12-18 09:15:28] khulap at mail dot ru
Description:
PHP crush without any output after use array_unique with complex
objects.
With php 5.1.6 all works ok. With primitive types all works ok.
Reproduce code:
---
echo 'Test1';
var_dump($rel_list);
echo 'Test2';
$rel_list=array_unique($rel_list);
echo 'Test3';
var_dump($rel_list);
echo 'Test4';
Expected result:
Test1array(4) {
[0]=>
object(GroupRelation)#204 (13) {
["id:protected"]=>
int(7)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(4)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[1]=>
object(GroupRelation)#207 (13) {
["id:protected"]=>
int(8)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(1)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[2]=>
object(GroupRelation)#209 (13) {
["id:protected"]=>
int(9)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(14)
["related_by:protected"]=>
int(3)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[3]=>
object(GroupRelation)#210 (13) {
["id:protected"]=>
int(10)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(17)
["related_by:protected"]=>
int(4)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
}
Test2
Test3
array(4) {
[0]=>
object(GroupRelation)#204 (13) {
["id:protected"]=>
int(7)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(4)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[1]=>
object(GroupRelation)#207 (13) {
["id:protected"]=>
int(8)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(1)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:
#39864 [NEW]: php crush without any report
From: khulap at mail dot ru
Operating system: Debian
PHP version: 5.2.0
PHP Bug Type: Arrays related
Bug description: php crush without any report
Description:
PHP crush without any output after use array_unique with complex objects.
With php 5.1.6 all works ok. With primitive types all works ok.
Reproduce code:
---
echo 'Test1';
var_dump($rel_list);
echo 'Test2';
$rel_list=array_unique($rel_list);
echo 'Test3';
var_dump($rel_list);
echo 'Test4';
Expected result:
Test1array(4) {
[0]=>
object(GroupRelation)#204 (13) {
["id:protected"]=>
int(7)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(4)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[1]=>
object(GroupRelation)#207 (13) {
["id:protected"]=>
int(8)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(1)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[2]=>
object(GroupRelation)#209 (13) {
["id:protected"]=>
int(9)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(14)
["related_by:protected"]=>
int(3)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[3]=>
object(GroupRelation)#210 (13) {
["id:protected"]=>
int(10)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(17)
["related_by:protected"]=>
int(4)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
}
Test2
Test3
array(4) {
[0]=>
object(GroupRelation)#204 (13) {
["id:protected"]=>
int(7)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(4)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[1]=>
object(GroupRelation)#207 (13) {
["id:protected"]=>
int(8)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(1)
["related_by:protected"]=>
NULL
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["alreadyInValidation:protected"]=>
bool(false)
["validationFailures:protected"]=>
array(0) {
}
["_new:private"]=>
bool(false)
["_deleted:private"]=>
bool(false)
["modifiedColumns:protected"]=>
array(0) {
}
}
[2]=>
object(GroupRelation)#209 (13) {
["id:protected"]=>
int(9)
["gr_child:protected"]=>
int(4)
["gr_parent:protected"]=>
int(14)
["related_by:protected"]=>
int(3)
["aGenGroupRelatedByGrChild:protected"]=>
NULL
["aGenGroupRelatedByGrParent:protected"]=>
NULL
["aGroupRealRelation:protected"]=>
NULL
["alreadyInSave:protected"]=>
bool(false)
["
#39863 [NEW]: file_exists() silently truncates after a null byte
From: djcapelis at gmail dot com Operating system: Linux, x86 PHP version: 4.4.4 PHP Bug Type: *Directory/Filesystem functions Bug description: file_exists() silently truncates after a null byte Description: file_exists() silently truncates anything after a null byte in a string. This produces unexpected results in some circumstances and possibly would result in security problems for limited amounts of poorly written code. include_once() for instance, provides the following: "ALERT - Include filename truncated by a \0 after '/etc/passwd' (attacker 'REMOTE_ADDR not set', file '/home/djc/test.php', line 13)" This seems like a sane way to handle it if truncating has to be done... though frankly since truncation will *always* produce the wrong result it might be nice to throw an error and stop processing. Reproduce code: --- Expected result: Expected: $ php -n test.php The file /etc/passwd.\0someextension does not exist Actual result: -- Actual: $ php -n test.php The file /etc/passwd.someextension exists -- Edit bug report at http://bugs.php.net/?id=39863&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39863&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39863&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39863&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39863&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39863&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39863&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39863&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39863&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39863&r=support Expected behavior:http://bugs.php.net/fix.php?id=39863&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39863&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39863&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39863&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39863&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39863&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39863&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39863&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39863&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39863&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39863&r=mysqlcfg
#39858 [Fbk->Opn]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
User updated by: develar at gmail dot com
Reported By: develar at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
New Comment:
It is not fixed.
Previous Comments:
[2006-12-18 08:34:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-12-17 14:30:25] develar at gmail dot com
Description:
The second call stored procedures causes an error "SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query" with
probability of 50%. I read #35333 #35637 #35203, but why the given code
fine works in Debian?
Reproduce code:
---
CREATE PROCEDURE `foo`()
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
SELECT 2 * 2;
END;
"SET NAMES 'utf8'",
PDO::ATTR_PERSISTENT => true));
$Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo->closeCursor();
?>
Expected result:
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Actual result:
--
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query in C:\home\test\www\pdo.php on line 12
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#39862 [Opn->Bgs]: Informix shared module doesn't compile
ID: 39862 Updated by: [EMAIL PROTECTED] Reported By: dirk dot kreyenberg at googlemail dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: HP-UX 11.11 PHP Version: 5.2.0 New Comment: /home/informix/ids940/lib/esql/checkapi.o is an object from Informix client distro and if it cannot be used during linking, it's not PHP problem. Previous Comments: [2006-12-18 08:40:32] dirk dot kreyenberg at googlemail dot com Description: Hello everybody, it seems like the informix support (not PDO) got broken since PHP 5.1.x on HP-UX 11.11 The configure runs smoothly but when it reaches the informix module, the compilation breaks. - Environment:32 bit, gcc 4.1.1, posix - IBM CSDK: 2.90.HC3 - Tried PHP versions:5.1.6, 5.2.0, php5.2-200612180730 - Last working version: 5.0.5 PDO-informix works fine btw. Thanks for your help! Dirk Reproduce code: --- # ./configure [...] --with-informix=shared,/home/informix/ids940 # gmake Expected result: A clean build ;-) Actual result: -- libtool: link: cannot build libtool library `libphp5.la' from non-libtool objects on this host: /home/informix/ids940/lib/esql/checkapi.o gmake: *** [libphp5.la] Error 1 -- Edit this bug report at http://bugs.php.net/?id=39862&edit=1
#39820 [Opn->Fbk]: ORA-03131: an invalid buffer was provided for the next piece
ID: 39820
Updated by: [EMAIL PROTECTED]
Reported By: alien at mosfasad dot ru
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: win xp
PHP Version: 5.2.0
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2006-12-13 17:09:16] alien at mosfasad dot ru
Description:
when i execute procedure(ORACLE 10 R2) with out param. i catch error
in the version 5.1.4 all is ok.
Procedure wb_utils.ReportOrder is VALID !
PHP Version 5.2.1-dev
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
OCI Revision$Revision: 1.269.2.16.2.26 $
PDO Driver for OCI 8 and later: enabled
Reproduce code:
---
$sSql = 'call wb_utils.ReportOrder(:var0,:out0,:var1,:var2,:var3)';
$aArguments = Array
(
[var0] => 24277102
[var1] =>
[var2] => args
[var3] => cols
)
$oStat = $this->oPDOs->prepare($sSql);
.
$oStat->bindParam('out0',$this->Out0, PDO::PARAM_STR,4096);
.
$oStat->execute($aArguments);
Expected result:
[13-дек-2006 19:49:57] PHP Fatal error: Uncaught in
C:\prj\web\include\db.2.inc.php at 410 code :pdo_execute Param
[HY000,SQLSTATE[HY000]: General error: 3131 OCIStmtExecute: ORA-03131:
an invalid buffer was provided for the next piece
(ext\pdo_oci\oci_statement.c:142),
call wb_utils.ReportOrder(:var0,:out0,:var1,:var2,:var3)
] thrown in C:\prj\web\include\db.2.inc.php on line 410
Actual result:
--
execute procedure and get out param
--
Edit this bug report at http://bugs.php.net/?id=39820&edit=1
#39862 [NEW]: Informix shared module doesn't compile
From: dirk dot kreyenberg at googlemail dot com Operating system: HP-UX 11.11 PHP version: 5.2.0 PHP Bug Type: Compile Failure Bug description: Informix shared module doesn't compile Description: Hello everybody, it seems like the informix support (not PDO) got broken since PHP 5.1.x on HP-UX 11.11 The configure runs smoothly but when it reaches the informix module, the compilation breaks. - Environment:32 bit, gcc 4.1.1, posix - IBM CSDK: 2.90.HC3 - Tried PHP versions:5.1.6, 5.2.0, php5.2-200612180730 - Last working version: 5.0.5 PDO-informix works fine btw. Thanks for your help! Dirk Reproduce code: --- # ./configure [...] --with-informix=shared,/home/informix/ids940 # gmake Expected result: A clean build ;-) Actual result: -- libtool: link: cannot build libtool library `libphp5.la' from non-libtool objects on this host: /home/informix/ids940/lib/esql/checkapi.o gmake: *** [libphp5.la] Error 1 -- Edit bug report at http://bugs.php.net/?id=39862&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39862&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39862&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39862&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39862&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39862&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39862&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39862&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39862&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39862&r=support Expected behavior:http://bugs.php.net/fix.php?id=39862&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39862&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39862&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39862&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39862&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39862&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39862&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39862&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39862&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39862&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39862&r=mysqlcfg
#39830 [Opn->Fbk]: Incorrect (float) variable output after using setlocale
ID: 39830 Updated by: [EMAIL PROTECTED] Reported By: ipa at beta dot lt -Status: Open +Status: Feedback Bug Type: Variables related Operating System: Linux 2.6.10 PHP Version: 4.4.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot reproduce. Previous Comments: [2006-12-14 09:58:01] ipa at beta dot lt Description: Strange behaviour on float variable output after using setlocale() function. Reproduce code: --- Expected result: 19,48 19,48 Actual result: -- 19,48 19.48 -- Edit this bug report at http://bugs.php.net/?id=39830&edit=1
#39824 [Opn->Bgs]: mysql_free_result warning
ID: 39824 Updated by: [EMAIL PROTECTED] Reported By: marcos dot neves at gmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: WINXP PHP Version: 5.2.0 New Comment: Set mysql.trace_mode to Off in your php.ini. Previous Comments: [2006-12-13 23:20:33] marcos dot neves at gmail dot com Description: Starting with mysql 5.2.0, mysql_free_result is required be called before end of script Reproduce code: --- Expected result: no warnings, the results should be disposed at end of script, as documentantion saids and as like was before. Actual result: -- Warning: Unknown: 1 result set(s) not freed. Use mysql_free_result to free result sets which were requested using mysql_query() in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=39824&edit=1
#39852 [Opn->Bgs]: static variable shows abnormal performence
ID: 39852 Updated by: [EMAIL PROTECTED] Reported By: eingmarra at hotmail dot com -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: windowsxp sp2 PHP Version: 5.2.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2006-12-16 12:29:11] eingmarra at hotmail dot com Description: Hi Master! I used php5.2 to write a class for some needs, I was surperised to find the static variable worked in an abnormal way, so I need you help to test it! --- test.php I expect for the result is "bool(false) bool(true) at the first time, And then: bool(true) bool(true) at the second time" I am not a phper, I am a java liker and want to learn the php lanugage, I dont know why it can not performence like java performence, So I report this bug! Thank you and hoping for you responsing... And best Regards to you all! Reproduce code: --- Expected result: bool(false) bool(true) the first time bool(true) bool(true) the second time Actual result: -- bool(false) bool(true) the first time bool(false) bool(true) the second time -- Edit this bug report at http://bugs.php.net/?id=39852&edit=1
#39858 [Opn->Fbk]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Updated by: [EMAIL PROTECTED]
Reported By: develar at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-12-17 14:30:25] develar at gmail dot com
Description:
The second call stored procedures causes an error "SQLSTATE[HY000]:
General error: 2013 Lost connection to MySQL server during query" with
probability of 50%. I read #35333 #35637 #35203, but why the given code
fine works in Debian?
Reproduce code:
---
CREATE PROCEDURE `foo`()
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
SELECT 2 * 2;
END;
"SET NAMES 'utf8'",
PDO::ATTR_PERSISTENT => true));
$Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo = $Db->prepare('CALL foo()');
$Pdo->execute();
print_r($Pdo->fetchAll());
$Pdo->closeCursor();
?>
Expected result:
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Actual result:
--
Array
(
[0] => Array
(
[2 * 2] => 4
)
)
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query in C:\home\test\www\pdo.php on line 12
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#39860 [Opn->Bgs]: PHP returns a blank page
ID: 39860 Updated by: [EMAIL PROTECTED] Reported By: j dot hakvoort at publiceren dot net -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Linux PHP Version: 5.2.0 New Comment: Do not file bugs when you have Zend extensions (zend_extension=) loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache, APC, Xdebug and ionCube loader. These extensions often modify engine behavior which is not related to PHP itself. . Previous Comments: [2006-12-18 04:33:27] j dot hakvoort at publiceren dot net Ok, I was to quick with my reply, it seems to be related to ZEND. This is my configuration in PHP.ini: ;[Zend] zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.2.0 zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.2.0 zend_optimizer.version=3.2.0 zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so When this is disabled, it does work! Please help!! Best Regards, Jan Jaap [2006-12-18 03:38:38] j dot hakvoort at publiceren dot net Ok! Adding display_errors=On did it! Now it works! :) So this might be a real bug, since display_errors=On isn't enabled by default and I presume it shouldn't cause script failure (returning nothing) of any kind when disabled. [2006-12-18 03:34:38] j dot hakvoort at publiceren dot net Hi! It's not about MediaWiki! It allso affects vBulletin and most likely other PHP scripts. It's a default PHP instalation so it should work! Error reporting has been enabled however, but before it was enabled it didn't work either. Best Regards, Jan Jaap [2006-12-18 03:30:28] judas dot iscariote at gmail dot com enable display_errors=On , disable all third party extensions, mediawiki works perfectly with php 5.2.0 , most likely not a PHP problem. [2006-12-18 03:19:52] j dot hakvoort at publiceren dot net Description: CMD php index.php on MediaWiki for example does not return anything (blank) While if you would start the script with a parameter to edit a wiki article it would serve the edit page. If you save it the new page will will be loaded but if you then refresh the page it will be 404 (blank). This does not only occur with MediaWiki but also on my vBulletin forums wich sometimes return a blank screen or 404. This does not occur always but sometimes on the forum while on MediaWiki the index always returns a blank screen. My host has already completely reinstalled PHP 5.2.0 and it still returns the same errors. I did not change anything in MediaWiki or vBulletin so it must be related to PHP. My host is reall verry experienced and knows what they are doing. PHP has been installed 2 times now by 2 difrent techs during the past 10 hours. Is this a known bug? Please help! Best Regards, Jan Jaap Reproduce code: --- http://www.celebrityprofiler.com/ (MediaWiki) http://www.papegaaienforum.nl/ (vBulletin forum, just click arround a few times untill a 404 is given) Expected result: Blank screen (no output) wich is interpreted by IE as 404. Actual result: -- Serving the script. -- Edit this bug report at http://bugs.php.net/?id=39860&edit=1
