#50023 [NEW]: pdo_mysql doesn't use PHP_MYSQL_UNIX_SOCK_ADDR
From: six at aegis-corp dot org
Operating system: linux 2.6
PHP version: 5.3.1RC2
PHP Bug Type: PDO related
Bug description: pdo_mysql doesn't use PHP_MYSQL_UNIX_SOCK_ADDR
Description:
since 5.3.0, the PDO Mysql driver doesn't use the --with-mysql-sock
configure option (help says : --with-mysql-sock[=DIR]
MySQL/MySQLi/PDO_MYSQL: Location of the MySQL unix socket pointer.) and
always uses /tmp/mysql.sock.
Patch below:
--- pdo_mysql.c.orig2009-10-27 18:02:56.0 +0100
+++ pdo_mysql.c 2009-10-27 19:15:38.0 +0100
@@ -40,7 +40,11 @@
#ifndef PHP_WIN32
# ifndef PDO_MYSQL_UNIX_ADDR
-# define PDO_MYSQL_UNIX_ADDR "/tmp/mysql.sock"
+# ifdef PHP_MYSQL_UNIX_SOCK_ADDR
+# define PDO_MYSQL_UNIX_ADDR PHP_MYSQL_UNIX_SOCK_ADDR
+# else
+# define PDO_MYSQL_UNIX_ADDR "/tmp/mysql.sock"
+# endif
# endif
#endif
Reproduce code:
---
./configure --with-mysql-sock=/var/run/mysqld/mysqld.sock [...] && make &&
make install
and then:
php -r 'new PDO("mysql:host=localhost");'
Expected result:
nothing
Actual result:
--
Warning: PDO::__construct(): [2002] No such file or directory (trying to
connect via unix:///tmp/mysql.sock) in Command line code on line 1
--
Edit bug report at http://bugs.php.net/?id=50023&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50023&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50023&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50023&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50023&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50023&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50023&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50023&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50023&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50023&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50023&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50023&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50023&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50023&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50023&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50023&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50023&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50023&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50023&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50023&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50023&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50023&r=mysqlcfg
#47014 [NEW]: callbacks are not looked up in the current namespace
From: six at aegis-corp dot org
Operating system: Linux 2.6
PHP version: 5.3.0alpha3
PHP Bug Type: Scripting Engine problem
Bug description: callbacks are not looked up in the current namespace
Description:
functions that accept callbacks do not look up the current namespace when
searching for the callback name. I have observed this with
register_shutdown_function() and pcntl_signal() but it's probably more than
these two.
sample code below works if we pass the fqn, ie:
register_shutdown_function("test\\shutdown");
Reproduce code:
---
Expected result:
bye
Actual result:
--
Warning: register_shutdown_function(): Invalid shutdown callback
'shutdown' passed in /root/php-5.3.0alpha3/ext/pcntl/- on line 11
--
Edit bug report at http://bugs.php.net/?id=47014&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47014&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47014&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47014&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47014&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47014&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47014&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47014&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47014&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47014&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47014&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47014&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47014&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47014&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47014&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47014&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47014&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47014&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47014&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47014&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47014&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47014&r=mysqlcfg
#45808 [NoF->Opn]: stream_socket_enable_crypto() blocks and eats CPU
ID: 45808 User updated by: six at aegis-corp dot org Reported By: six at aegis-corp dot org -Status: No Feedback +Status: Open Bug Type: Streams related Operating System: Linux 2.6 PHP Version: 5.3.0alpha1 New Comment: the bug is still present in php5.3-200809232030 Previous Comments: [2008-09-24 01:20:29] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-23 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-09-15 07:22:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-08-13 17:41:01] six at aegis-corp dot org Description: The documentation says about stream_socket_enable_crypto : Returns TRUE on success, FALSE if negotiation has failed or 0 if there isn't enough data and you should try again (only for non-blocking sockets). In practice, if you feed a non blocking server socket to it, it will block and consume lots of CPU until the SSL/TLS handshake is done or the client connection is dropped. Reproduce code: --- then just "telnet localhost " from another term Expected result: script should print "int(0)" and exit Actual result: -- script blocks at the stream_socket_enable_crypto() call and is stuck in a CPU consuming loop until the client connection is either handshaked or dropped. -- Edit this bug report at http://bugs.php.net/?id=45808&edit=1
#45808 [Com]: stream_socket_enable_crypto() blocks and eats CPU
ID: 45808 Comment by: six at aegis-corp dot org Reported By: six at aegis-corp dot org Status: No Feedback Bug Type: Streams related Operating System: Linux 2.6 PHP Version: 5.3.0alpha1 New Comment: the bug is still present in php5.3-200809232030 Previous Comments: [2008-09-23 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-09-15 07:22:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-08-13 17:41:01] six at aegis-corp dot org Description: The documentation says about stream_socket_enable_crypto : Returns TRUE on success, FALSE if negotiation has failed or 0 if there isn't enough data and you should try again (only for non-blocking sockets). In practice, if you feed a non blocking server socket to it, it will block and consume lots of CPU until the SSL/TLS handshake is done or the client connection is dropped. Reproduce code: --- then just "telnet localhost " from another term Expected result: script should print "int(0)" and exit Actual result: -- script blocks at the stream_socket_enable_crypto() call and is stuck in a CPU consuming loop until the client connection is either handshaked or dropped. -- Edit this bug report at http://bugs.php.net/?id=45808&edit=1
#41371 [NEW]: stream_set_blocking bug with sockets
From: six at aegis-corp dot org
Operating system: Linux 2.6
PHP version: 5.2.2
PHP Bug Type: Streams related
Bug description: stream_set_blocking bug with sockets
Description:
When a stream has been obtained using stream_socket_accept from a
non-blocking server, php believes that it is itself non-blocking and
refuses to set it non blocking after a call to stream_set_blocking.
Reproduce code:
---
Expected result:
Expected result is that $c is non-blocking, which it is *not* unless the
previous stream_set_blocking($c, true) is uncommented (this may reset some
internal cache ?)
Actual result:
--
reproduce code strace:
listen(3, 5)= 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP, revents=POLLIN}], 1, 6) =
1
accept(3, {sa_family=AF_INET, sin_port=htons(58901),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
[stream_set_blocking($c, false) does nothing here]
close(4)= 0
close(3)= 0
[script ends]
reproduce code strace with second call uncommented :
listen(3, 5)= 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP, revents=POLLIN}], 1, 6) =
1
accept(3, {sa_family=AF_INET, sin_port=htons(58901),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR) = 0
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[the two stream_set_blocking calls work here]
close(4)= 0
close(3)= 0
[script ends]
--
Edit bug report at http://bugs.php.net/?id=41371&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41371&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41371&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41371&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41371&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41371&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41371&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41371&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41371&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41371&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41371&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41371&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41371&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41371&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41371&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41371&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41371&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41371&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41371&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41371&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41371&r=mysqlcfg
#34700 [Fbk->Opn]: performance problem with date()
ID: 34700
User updated by: six at aegis-corp dot org
Reported By: six at aegis-corp dot org
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: linux 2.4
PHP Version: 5.1.0RC1
New Comment:
sniper: the latest cvs exhibits the same problem.
rasmus: $_SERVER["REQUEST_TIME"] is a nice addition, but in my case I
just want to convert timestamps stored in a db to a readable format,
hence no need for the current time at all ...
the following patch address the unneeded call to time(NULL), strace
confirms it, but the performance is still not on par with 5.0
--- php5-200510011430/ext/date/php_date.c.orig 2005-10-01
18:16:55.0 +0200
+++ php5-200510011430/ext/date/php_date.c 2005-10-01
18:17:48.0 +0200
@@ -479,11 +479,23 @@
{
char *format;
int format_len;
- time_t ts = time(NULL);
+ time_t ts;
char *string;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s|l",
&format, &format_len, &ts) == FAILURE) {
- RETURN_FALSE;
+ switch (ZEND_NUM_ARGS()) {
+ case 2:
+ if (zend_parse_parameters(2 TSRMLS_CC, "sl", &format,
&format_len, &ts) == FAILURE) {
+ RETURN_FALSE;
+ }
+ break;
+ case 1:
+ if (zend_parse_parameters(1 TSRMLS_CC, "s", &format,
&format_len) == FAILURE) {
+ RETURN_FALSE;
+ }
+ ts = time(NULL);
+ break;
+ default:
+ WRONG_PARAM_COUNT;
}
string = php_format_date(format, format_len, ts, localtime
TSRMLS_CC);
Previous Comments:
[2005-10-01 17:13:34] [EMAIL PROTECTED]
One of the new things in PHP 5.1 is the $_SERVER['REQUEST_TIME']
variable that gets set to the request time. When running under Apache
this comes directly from the time syscall Apache makes for every
request, so by using this you can actually eliminate any time-related
syscalls at the PHP level and still do time stuff in a PHP script. But
yes, it looks like there are a few things that can be cleaned up here.
[2005-10-01 17:05:36] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
--------------------
[2005-10-01 16:07:27] six at aegis-corp dot org
Description:
performance of the date() function has taken a huge hit between PHP 5.0
and 5.1. i believe this is because of an unneeded syscall when a second
argument is given.
Reproduce code:
---
Expected result:
time /usr/local/bin/php-cli-5.0.4 datetest.php
real 0m2.022s
user 0m1.910s
sys 0m0.000s
Actual result:
--
time /usr/local/bin/php-cli-5.1.0RC1 datetest.php
real 0m10.001s
user 0m8.120s
sys 0m0.130s
5.1.0 takes more than 4x the time to complete than 5.0.4
with an strace, I can see that 5.1.0RC1 makes one (probably unneeded)
time() syscall per call to date(), which 5.0.4 does not
--
Edit this bug report at http://bugs.php.net/?id=34700&edit=1
#34700 [NEW]: performance problem with date()
From: six at aegis-corp dot org Operating system: linux 2.4 PHP version: 5.1.0RC1 PHP Bug Type: Date/time related Bug description: performance problem with date() Description: performance of the date() function has taken a huge hit between PHP 5.0 and 5.1. i believe this is because of an unneeded syscall when a second argument is given. Reproduce code: --- Expected result: time /usr/local/bin/php-cli-5.0.4 datetest.php real 0m2.022s user 0m1.910s sys 0m0.000s Actual result: -- time /usr/local/bin/php-cli-5.1.0RC1 datetest.php real 0m10.001s user 0m8.120s sys 0m0.130s 5.1.0 takes more than 4x the time to complete than 5.0.4 with an strace, I can see that 5.1.0RC1 makes one (probably unneeded) time() syscall per call to date(), which 5.0.4 does not -- Edit bug report at http://bugs.php.net/?id=34700&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34700&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34700&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34700&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34700&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34700&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34700&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34700&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34700&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34700&r=support Expected behavior: http://bugs.php.net/fix.php?id=34700&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34700&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34700&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34700&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34700&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34700&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34700&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34700&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34700&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34700&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34700&r=mysqlcfg
