Bug #52799 [Com]: Old password authentication with (PDO) MySQL native driver
Edit report at http://bugs.php.net/bug.php?id=52799edit=1
ID: 52799
Comment by: php at diptyque dot net
Reported by:php at diptyque dot net
Summary:Old password authentication with (PDO) MySQL native
driver
Status: Bogus
Type: Bug
Package:PDO related
Operating System: FreeBSD
PHP Version:5.3.3
Block user comment: N
New Comment:
Found! [1]
IMHO it should also be replicated in the MySQL native driver section [2]
[1] http://www.php.net/manual/en/migration53.incompatible.php
[2] http://fr.php.net/manual/en/book.mysqlnd.php
Previous Comments:
[2010-09-08 19:41:44] u...@php.net
Thanks for the feedback! I'm quite sure its in the docs. I double check.
Closing upon request of the bug reporter.
[2010-09-08 19:23:51] php at diptyque dot net
Oops, my mistake. Wrote the test script and ext/mysql code cannot
effectively connect using old authentication w/ enabled MYSQLND. The
ext/mysql code I previously tested wasn't running on the same server
(DNS changes for the hostname weren't applied yet; code was still
running on the old server platform.)
Problem solved. Bogus report. Two alternatives. Either build ext/mysql,
ext/mysqli and PDO MySQL w/o MYSQLND option to preserve compatibility
with old passwords. Either update all MySQL passwords with enhanced
authentication.
I believe a note stating that the old authentication scheme is not
supported anymore should be added to the MySQL Native Driver manual.
[2010-09-08 18:34:09] u...@php.net
Because mysqlnd does not support it, ext/mysql - if using mysqlnd -
can't support it. Please provide a test script which shows ext/mysql
connecting while PDO_MySQL does not.
[2010-09-08 18:16:02] php at diptyque dot net
Description:
Some PHP legacy code no longer works with the 5.3.3 MYSQLND-enabled [1]
PDO MySQL driver -- I got 2 warnings and an exception is raised:
[07-Sep-2010 14:31:16] PHP Warning: PDO::__construct(): Premature end of
data (mysqlnd_wireprotocol.c:554) in /my/path/to/php/auto/append.php on
line xx
[07-Sep-2010 14:31:16] PHP Warning: PDO::__construct(): OK packet 1
bytes shorter than expected in /my/path/to/php/auto/append.php on line
xx
Exception says that mysqlnd cannot connect to MySQL 4.1+ using the old
insecure authentication.
This is inconsistent with the behavior of the 5.3.3 MySQL extension
built with MYSQLND support: I have even older PHP code that can connect
to MySQL 4.1+ using the old insecure authentication scheme (!?) Go
figure.
Of course, reverting to the PDO MySQL driver w/ classic MySQL client
library support works.
[1] mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $
Test script:
---
?php
try {
$dbh = new PDO($sql-dsn, $sql-username, $sql-password);
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
}
catch (Exception $e) { /* ... */ }
// failure
?
vs.
?php
$dbh = mysql_pconnect(
$mysql['hostname'], $mysql['username'], $mysql['password']
);
// success
?
Expected result:
Why does old password authentication still works with MYSQLND-enabled
MySQL extension but not with MYSQLND-enabled PDO MySQL driver?
Actual result:
--
SQLSTATE[HY000] [2000] mysqlnd cannot connect to MySQL 4.1+ using the
old insecure authentication. Please use an administration tool to reset
your password with the command SET PASSWORD =
PASSWORD('your_existing_password'). This will store a new, and more
secure, hash value in mysql.user. If this user is used in other scripts
executed by PHP 5.2 or earlier you might need to remove the
old-passwords flag from your my.cnf file
--
Edit this bug report at http://bugs.php.net/bug.php?id=52799edit=1
[PHP-BUG] Bug #52799 [NEW]: Old password authentication with (PDO) MySQL native driver
From:
Operating system: FreeBSD
PHP version: 5.3.3
Package: PDO related
Bug Type: Bug
Bug description:Old password authentication with (PDO) MySQL native driver
Description:
Some PHP legacy code no longer works with the 5.3.3 MYSQLND-enabled [1] PDO
MySQL driver -- I got 2 warnings and an exception is raised:
[07-Sep-2010 14:31:16] PHP Warning: PDO::__construct(): Premature end of
data (mysqlnd_wireprotocol.c:554) in /my/path/to/php/auto/append.php on
line xx
[07-Sep-2010 14:31:16] PHP Warning: PDO::__construct(): OK packet 1 bytes
shorter than expected in /my/path/to/php/auto/append.php on line xx
Exception says that mysqlnd cannot connect to MySQL 4.1+ using the old
insecure authentication.
This is inconsistent with the behavior of the 5.3.3 MySQL extension built
with MYSQLND support: I have even older PHP code that can connect to MySQL
4.1+ using the old insecure authentication scheme (!?) Go figure.
Of course, reverting to the PDO MySQL driver w/ classic MySQL client
library support works.
[1] mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $
Test script:
---
?php
try {
$dbh = new PDO($sql-dsn, $sql-username, $sql-password);
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
}
catch (Exception $e) { /* ... */ }
// failure
?
vs.
?php
$dbh = mysql_pconnect(
$mysql['hostname'], $mysql['username'], $mysql['password']
);
// success
?
Expected result:
Why does old password authentication still works with MYSQLND-enabled MySQL
extension but not with MYSQLND-enabled PDO MySQL driver?
Actual result:
--
SQLSTATE[HY000] [2000] mysqlnd cannot connect to MySQL 4.1+ using the old
insecure authentication. Please use an administration tool to reset your
password with the command SET PASSWORD =
PASSWORD('your_existing_password'). This will store a new, and more secure,
hash value in mysql.user. If this user is used in other scripts executed by
PHP 5.2 or earlier you might need to remove the old-passwords flag from
your my.cnf file
--
Edit bug report at http://bugs.php.net/bug.php?id=52799edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52799r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52799r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52799r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52799r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52799r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52799r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52799r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52799r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52799r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52799r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52799r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52799r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52799r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52799r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52799r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52799r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52799r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52799r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52799r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52799r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52799r=mysqlcfg
Bug #52799 [Com]: Old password authentication with (PDO) MySQL native driver
Edit report at http://bugs.php.net/bug.php?id=52799edit=1
ID: 52799
Comment by: php at diptyque dot net
Reported by:php at diptyque dot net
Summary:Old password authentication with (PDO) MySQL native
driver
Status: Feedback
Type: Bug
Package:PDO related
Operating System: FreeBSD
PHP Version:5.3.3
Block user comment: N
New Comment:
Oops, my mistake. Wrote the test script and ext/mysql code cannot
effectively connect using old authentication w/ enabled MYSQLND. The
ext/mysql code I previously tested wasn't running on the same server
(DNS changes for the hostname weren't applied yet; code was still
running on the old server platform.)
Problem solved. Bogus report. Two alternatives. Either build ext/mysql,
ext/mysqli and PDO MySQL w/o MYSQLND option to preserve compatibility
with old passwords. Either update all MySQL passwords with enhanced
authentication.
I believe a note stating that the old authentication scheme is not
supported anymore should be added to the MySQL Native Driver manual.
Previous Comments:
[2010-09-08 18:34:09] u...@php.net
Because mysqlnd does not support it, ext/mysql - if using mysqlnd -
can't support it. Please provide a test script which shows ext/mysql
connecting while PDO_MySQL does not.
[2010-09-08 18:16:02] php at diptyque dot net
Description:
Some PHP legacy code no longer works with the 5.3.3 MYSQLND-enabled [1]
PDO MySQL driver -- I got 2 warnings and an exception is raised:
[07-Sep-2010 14:31:16] PHP Warning: PDO::__construct(): Premature end of
data (mysqlnd_wireprotocol.c:554) in /my/path/to/php/auto/append.php on
line xx
[07-Sep-2010 14:31:16] PHP Warning: PDO::__construct(): OK packet 1
bytes shorter than expected in /my/path/to/php/auto/append.php on line
xx
Exception says that mysqlnd cannot connect to MySQL 4.1+ using the old
insecure authentication.
This is inconsistent with the behavior of the 5.3.3 MySQL extension
built with MYSQLND support: I have even older PHP code that can connect
to MySQL 4.1+ using the old insecure authentication scheme (!?) Go
figure.
Of course, reverting to the PDO MySQL driver w/ classic MySQL client
library support works.
[1] mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $
Test script:
---
?php
try {
$dbh = new PDO($sql-dsn, $sql-username, $sql-password);
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
}
catch (Exception $e) { /* ... */ }
// failure
?
vs.
?php
$dbh = mysql_pconnect(
$mysql['hostname'], $mysql['username'], $mysql['password']
);
// success
?
Expected result:
Why does old password authentication still works with MYSQLND-enabled
MySQL extension but not with MYSQLND-enabled PDO MySQL driver?
Actual result:
--
SQLSTATE[HY000] [2000] mysqlnd cannot connect to MySQL 4.1+ using the
old insecure authentication. Please use an administration tool to reset
your password with the command SET PASSWORD =
PASSWORD('your_existing_password'). This will store a new, and more
secure, hash value in mysql.user. If this user is used in other scripts
executed by PHP 5.2 or earlier you might need to remove the
old-passwords flag from your my.cnf file
--
Edit this bug report at http://bugs.php.net/bug.php?id=52799edit=1
#38577 [Bgs]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net Status: Bogus Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: IMHO, the latest mbstring-related bug fix in PHP 5.2.1 has much more in common with the problem I reported than those bug report numbers you previously pointed to (!?) see http://bugs.php.net/bug.php?id=39361 ; mbstring function overloading - done although not activated Previous Comments: [2006-10-18 21:09:18] [EMAIL PROTECTED] See bug #38670 and bug #38566. Please use bug #38760 for further comments. [2006-09-08 09:02:47] php at diptyque dot net I'm not trying anything. You told me to download and install the latest CVS snapshot. That's what I did but the erratic function overloading behavior is still there. Considering no drastic changes have been made since v4.4.4 either at the Apache SAPI level (mod_php4.c) or in Mbstring (mbstring.c) source code, this isn't very surprising. Regarding Xdebug, this particular extension also overrides two core functions -- namely var_dump() and set_time_limit (). Don't you think it would be interesting to know if the function overloading that Xdebug performs is sticky or not when running under the Apache 1.3 SAPI? I have the strong feeling that the original PHP function table state is not restored properly by Mbstring but I don't have the time nor the resources needed to nail down further the origin of the leak -- i.e. the overridden functions stickiness or whatever you may call it. [2006-09-07 16:48:46] [EMAIL PROTECTED] I'm not sure I understand what you're trying to do and to say. [2006-09-07 16:39:49] php at diptyque dot net FYI, I do *NOT* have any Zend or Xdebug extension installed... I have downloaded Xdebug only to compare its overriding technique with the one used in Mbstring extension. =begin [diptyque] % php -m [PHP Modules] bz2 ctype curl gd imap mbstring mysql openssl overload pcre posix readline session sqlite standard tokenizer xml zlib [Zend Modules] =end BTW, I compared source files for apache SAPI (./sapi/apache/mod_php4.c) and mbstring extension (./ext/mbstring/mbstring.c) between version 4.4.4 and latest stable version and did not find anything different (!?) [2006-09-07 15:25:39] [EMAIL PROTECTED] Please remove all zend_extensions, including XDebug and try again. 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [Fbk-Opn]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net -Status: Feedback +Status: Open Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Sorry but it doesn't make it. Mbstring function overloading setting is unfortunately persistent once an Apache process has served content from a vhost where this ini parameter is assigned a value distinct from zero. Previous Comments: [2006-09-06 16:31:20] [EMAIL PROTECTED] Fixed, thanks. What about your issue? [2006-09-06 16:13:00] php at diptyque dot net Just downloaded the latest stable release, built it and ran the test suite and mb_strlen() test case failed because AFAIK this version of PHP (4.4.5-dev) doesn't emit catchable errors yet (E_RECOVERABLE_ERROR). Anyway I'm going to install it tomorrow morning and will let you know ASAP if it does fix the ini settings leak between virtual hosts. === = /usr/local/src/php4-STABLE-200609061230/ext/mbstring/tests/ mb_strlen.phpt === = EXPECTED OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Catchable fatal error ERR: Notice 6 ERR: Warning ACTUAL OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Notice 6 ERR: Warning FAILED === = 019- ERR: Catchable fatal error 019+ ERR: Notice 020- ERR: Notice 020+ 6 021- 6 021+ ERR: Warning 022- ERR: Warning === = [2006-09-06 09:58:07] [EMAIL PROTECTED] 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 [2006-08-28 15:56:47] php at diptyque dot net Dunno for PHP 5 -- I have to make some tests before trying to switch -- but I wonder if this bug could be related to http://bugs.php.net/bug.php?id=37932. [2006-08-25 15:51:25] judas dot iscariote at gmail dot com PHP5 produces the same effects for you ? 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [Opn]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net Status: Open Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Antony, I'm not very familiar with Zend Engine 1.3 innards but I had a look at how Xdebug is overriding both var_dump() and set_time_limit() functions in PHP_RINIT_FUNCTION(xdebug) and how it does restore the original function pointers in PHP_RSHUTDOWN_FUNCTION(xdebug). Peeking at mbstring extension source code, this looks a bit more verbose and it doesn't fiddle directly with orig-internal_function.handler (!?) to restore the original function. Instead it calls subsequently zend_hash_update() and zend_hash_del() using the info it gathered inside its mb_overload_def struct... IMHO, mbstring ini settings are properly reset (please see http://bugs.php.net/bug.php?id=25753) but not the initial PHP function table state. Previous Comments: [2006-09-07 09:29:53] php at diptyque dot net Sorry but it doesn't make it. Mbstring function overloading setting is unfortunately persistent once an Apache process has served content from a vhost where this ini parameter is assigned a value distinct from zero. [2006-09-06 16:31:20] [EMAIL PROTECTED] Fixed, thanks. What about your issue? [2006-09-06 16:13:00] php at diptyque dot net Just downloaded the latest stable release, built it and ran the test suite and mb_strlen() test case failed because AFAIK this version of PHP (4.4.5-dev) doesn't emit catchable errors yet (E_RECOVERABLE_ERROR). Anyway I'm going to install it tomorrow morning and will let you know ASAP if it does fix the ini settings leak between virtual hosts. === = /usr/local/src/php4-STABLE-200609061230/ext/mbstring/tests/ mb_strlen.phpt === = EXPECTED OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Catchable fatal error ERR: Notice 6 ERR: Warning ACTUAL OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Notice 6 ERR: Warning FAILED === = 019- ERR: Catchable fatal error 019+ ERR: Notice 020- ERR: Notice 020+ 6 021- 6 021+ ERR: Warning 022- ERR: Warning === = [2006-09-06 09:58:07] [EMAIL PROTECTED] 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 [2006-08-28 15:56:47] php at diptyque dot net Dunno for PHP 5 -- I have to make some tests before trying to switch -- but I wonder if this bug could be related to http://bugs.php.net/bug.php?id=37932. 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [Fbk-Opn]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net -Status: Feedback +Status: Open Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Just downloaded the latest stable release, built it and ran the test suite and mb_strlen() test case failed because AFAIK this version of PHP (4.4.5-dev) doesn't emit catchable errors yet (E_RECOVERABLE_ERROR). Anyway I'm going to install it tomorrow morning and will let you know ASAP if it does fix the ini settings leak between virtual hosts. === = /usr/local/src/php4-STABLE-200609061230/ext/mbstring/tests/ mb_strlen.phpt === = EXPECTED OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Catchable fatal error ERR: Notice 6 ERR: Warning ACTUAL OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Notice 6 ERR: Warning FAILED === = 019- ERR: Catchable fatal error 019+ ERR: Notice 020- ERR: Notice 020+ 6 021- 6 021+ ERR: Warning 022- ERR: Warning === = Previous Comments: [2006-09-06 09:58:07] [EMAIL PROTECTED] 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 [2006-08-28 15:56:47] php at diptyque dot net Dunno for PHP 5 -- I have to make some tests before trying to switch -- but I wonder if this bug could be related to http://bugs.php.net/bug.php?id=37932. [2006-08-25 15:51:25] judas dot iscariote at gmail dot com PHP5 produces the same effects for you ? [2006-08-25 13:39:31] [EMAIL PROTECTED] Reclassified as Apache-related issue. [2006-08-25 13:32:22] php at diptyque dot net I forgot to mention that mbstring.func_overload is enabled on a per-vhost basis for some other web sites I'm hosting on this platform. 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [Opn]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net Status: Open Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Dunno for PHP 5 -- I have to make some tests before trying to switch -- but I wonder if this bug could be related to http://bugs.php.net/bug.php?id=37932. Previous Comments: [2006-08-25 15:51:25] judas dot iscariote at gmail dot com PHP5 produces the same effects for you ? [2006-08-25 13:39:31] [EMAIL PROTECTED] Reclassified as Apache-related issue. [2006-08-25 13:32:22] php at diptyque dot net I forgot to mention that mbstring.func_overload is enabled on a per-vhost basis for some other web sites I'm hosting on this platform. [2006-08-24 16:20:24] php at diptyque dot net Agreed but I'm not making things up, you know. Something is obviously wrong on my Apache 1.3.34 setup. Could this be a conflict with some extension or Apache module? Of course, no opcode cache is running. Any tip welcome. This weird behavior has been plaguing me for 2 months now and rebuilding PHP doesn't seem to help. I wrote a second test case which demonstrates that function overloading is effectively taking place sporadically while running under apache SAPI -- strlen() may accept the optional encoding argument (!?) as shown in the script output below. http://www.diptyque.net/bugs/mbinfo2.php http://www.diptyque.net/bugs/mbinfo2.phps ; source code =begin [diptyque] % GET http://www.diptyque.net/bugs/mbinfo2.php preint(72208) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) int(18) /pre =end If I do run the same script through PHP CLI or FastCGI, I get the following expected warnings: PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 17 PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 25 [2006-08-24 15:15:31] [EMAIL PROTECTED] Please try with minimal configuration (like ./configure --enable-mbstring) and PHP CLI. If you're still able to reproduce it, you're likely to be the only person who can help you, since I really doubt anyone else can do it. 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [Opn]: Changing internal character encoding affects function overloading
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net Status: Open Bug Type: mbstring related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: I forgot to mention that mbstring.func_overload is enabled on a per-vhost basis for some other web sites I'm hosting on this platform. Previous Comments: [2006-08-24 16:20:24] php at diptyque dot net Agreed but I'm not making things up, you know. Something is obviously wrong on my Apache 1.3.34 setup. Could this be a conflict with some extension or Apache module? Of course, no opcode cache is running. Any tip welcome. This weird behavior has been plaguing me for 2 months now and rebuilding PHP doesn't seem to help. I wrote a second test case which demonstrates that function overloading is effectively taking place sporadically while running under apache SAPI -- strlen() may accept the optional encoding argument (!?) as shown in the script output below. http://www.diptyque.net/bugs/mbinfo2.php http://www.diptyque.net/bugs/mbinfo2.phps ; source code =begin [diptyque] % GET http://www.diptyque.net/bugs/mbinfo2.php preint(72208) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) int(18) /pre =end If I do run the same script through PHP CLI or FastCGI, I get the following expected warnings: PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 17 PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 25 [2006-08-24 15:15:31] [EMAIL PROTECTED] Please try with minimal configuration (like ./configure --enable-mbstring) and PHP CLI. If you're still able to reproduce it, you're likely to be the only person who can help you, since I really doubt anyone else can do it. [2006-08-24 15:04:03] php at diptyque dot net I moved mbstring function overload initial setting (6) from my php.ini to specific virtual hosts configuration sections but to no avail. It would seem that some Apache processes get it right while others get it wrong (!) This is quite weird -- for example, process #58902 returns int(18) while #58914 returns int(19). [diptyque] % GET http://localhost/bugs/mbinfo2.php preint(58902) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) /pre [diptyque] % GET http://localhost/bugs/mbinfo2.php preint(58914) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) /pre [2006-08-24 12:41:06] [EMAIL PROTECTED] Right, int(19) is what I get on Linux and FreeBSD 5.4. [2006-08-24 12:33:17] php at diptyque dot net Oops, my mistake. You should swap Expected and Actual results. Actual result is int(18) !? Expected result is int(19). 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [NEW]: Changing internal character encoding affects function overloading
From: php at diptyque dot net Operating system: FreeBSD 4.4 PHP version: 4.4.4 PHP Bug Type: mbstring related Bug description: Changing internal character encoding affects function overloading Description: Changing internal character encoding during script execution apparently affects mbstring function overloading: strlen() returns the length of the string based on current internal encoding although function overloading is disabled (either through php.ini, vhost and/or .htaccess settings.) On apache 1.3 startup or graceful restart, script may run as expected but repeated requests would inevitably trigger the bug -- on my server setup, MediaWiki cannot run reliably because of this weird behavior :-/ The bug is not triggered when I do run this script under other SAPIs such as CLI or FastCGI. ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local --with-openssl=/usr/local/apache --with-gd=/usr/local --with-zlib --with-bz2 --with-xml --with-freetype-dir=/usr/local --with-ttf --with-imap --with-curl --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-readline=/usr/local --prefix=/usr/local/apache --with-config-file-path=/usr/local/apache/etc --enable-mbstring --enable-mbregex --enable-zend-multibyte ; configure line Reproduce code: --- http://www.diptyque.net/bugs/mbinfo.php ; running PHP 4.4 as an apache module ; display charset is set to UTF-8 ; when internal encoding is set to UTF-8, ; strlen() returns the wrong character count ; (e.g. 18 instead of 19) http://www.diptyque.net/bugs/mbinfo.phps ; source code Expected result: string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage Actual result: -- string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage -- Edit bug report at http://bugs.php.net/?id=38577edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38577r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38577r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38577r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38577r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38577r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38577r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38577r=needscript Try newer version:http://bugs.php.net/fix.php?id=38577r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38577r=support Expected behavior:http://bugs.php.net/fix.php?id=38577r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38577r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38577r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38577r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38577r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38577r=dst IIS Stability:http://bugs.php.net/fix.php?id=38577r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38577r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38577r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38577r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38577r=mysqlcfg
#38577 [Fbk-Opn]: Changing internal character encoding affects function overloading
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net -Status: Feedback +Status: Open Bug Type: mbstring related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Granted I could not reproduce either this bug using a WAMP setup but did you follow the hyperlink I gave on my FreeBSD-based server, where you can consistently replicate this bug on each GET request? Previous Comments: [2006-08-24 11:03:09] [EMAIL PROTECTED] Can't reproduce. I get int(19) in all cases. [2006-08-24 10:17:16] php at diptyque dot net Description: Changing internal character encoding during script execution apparently affects mbstring function overloading: strlen() returns the length of the string based on current internal encoding although function overloading is disabled (either through php.ini, vhost and/or .htaccess settings.) On apache 1.3 startup or graceful restart, script may run as expected but repeated requests would inevitably trigger the bug -- on my server setup, MediaWiki cannot run reliably because of this weird behavior :-/ The bug is not triggered when I do run this script under other SAPIs such as CLI or FastCGI. ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local --with-openssl=/usr/local/apache --with-gd=/usr/local --with-zlib --with-bz2 --with-xml --with-freetype-dir=/usr/local --with-ttf --with-imap --with-curl --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-readline=/usr/local --prefix=/usr/local/apache --with-config-file-path=/usr/local/apache/etc --enable-mbstring --enable-mbregex --enable-zend-multibyte ; configure line Reproduce code: --- http://www.diptyque.net/bugs/mbinfo.php ; running PHP 4.4 as an apache module ; display charset is set to UTF-8 ; when internal encoding is set to UTF-8, ; strlen() returns the wrong character count ; (e.g. 18 instead of 19) http://www.diptyque.net/bugs/mbinfo.phps ; source code Expected result: string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage Actual result: -- string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [Opn]: Changing internal character encoding affects function overloading
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net Status: Open Bug Type: mbstring related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Oops, my mistake. You should swap Expected and Actual results. Actual result is int(18) !? Expected result is int(19). Previous Comments: [2006-08-24 12:28:30] php at diptyque dot net Granted I could not reproduce either this bug using a WAMP setup but did you follow the hyperlink I gave on my FreeBSD-based server, where you can consistently replicate this bug on each GET request? [2006-08-24 11:03:09] [EMAIL PROTECTED] Can't reproduce. I get int(19) in all cases. [2006-08-24 10:17:16] php at diptyque dot net Description: Changing internal character encoding during script execution apparently affects mbstring function overloading: strlen() returns the length of the string based on current internal encoding although function overloading is disabled (either through php.ini, vhost and/or .htaccess settings.) On apache 1.3 startup or graceful restart, script may run as expected but repeated requests would inevitably trigger the bug -- on my server setup, MediaWiki cannot run reliably because of this weird behavior :-/ The bug is not triggered when I do run this script under other SAPIs such as CLI or FastCGI. ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local --with-openssl=/usr/local/apache --with-gd=/usr/local --with-zlib --with-bz2 --with-xml --with-freetype-dir=/usr/local --with-ttf --with-imap --with-curl --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-readline=/usr/local --prefix=/usr/local/apache --with-config-file-path=/usr/local/apache/etc --enable-mbstring --enable-mbregex --enable-zend-multibyte ; configure line Reproduce code: --- http://www.diptyque.net/bugs/mbinfo.php ; running PHP 4.4 as an apache module ; display charset is set to UTF-8 ; when internal encoding is set to UTF-8, ; strlen() returns the wrong character count ; (e.g. 18 instead of 19) http://www.diptyque.net/bugs/mbinfo.phps ; source code Expected result: string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage Actual result: -- string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [Fbk-Opn]: Changing internal character encoding affects function overloading
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net -Status: Feedback +Status: Open Bug Type: mbstring related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: I moved mbstring function overload initial setting (6) from my php.ini to specific virtual hosts configuration sections but to no avail. It would seem that some Apache processes get it right while others get it wrong (!) This is quite weird -- for example, process #58902 returns int(18) while #58914 returns int(19). [diptyque] % GET http://localhost/bugs/mbinfo2.php preint(58902) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) /pre [diptyque] % GET http://localhost/bugs/mbinfo2.php preint(58914) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) /pre Previous Comments: [2006-08-24 12:41:06] [EMAIL PROTECTED] Right, int(19) is what I get on Linux and FreeBSD 5.4. [2006-08-24 12:33:17] php at diptyque dot net Oops, my mistake. You should swap Expected and Actual results. Actual result is int(18) !? Expected result is int(19). [2006-08-24 12:28:30] php at diptyque dot net Granted I could not reproduce either this bug using a WAMP setup but did you follow the hyperlink I gave on my FreeBSD-based server, where you can consistently replicate this bug on each GET request? [2006-08-24 11:03:09] [EMAIL PROTECTED] Can't reproduce. I get int(19) in all cases. [2006-08-24 10:17:16] php at diptyque dot net Description: Changing internal character encoding during script execution apparently affects mbstring function overloading: strlen() returns the length of the string based on current internal encoding although function overloading is disabled (either through php.ini, vhost and/or .htaccess settings.) On apache 1.3 startup or graceful restart, script may run as expected but repeated requests would inevitably trigger the bug -- on my server setup, MediaWiki cannot run reliably because of this weird behavior :-/ The bug is not triggered when I do run this script under other SAPIs such as CLI or FastCGI. ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local --with-openssl=/usr/local/apache --with-gd=/usr/local --with-zlib --with-bz2 --with-xml --with-freetype-dir=/usr/local --with-ttf --with-imap --with-curl --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-readline=/usr/local --prefix=/usr/local/apache --with-config-file-path=/usr/local/apache/etc --enable-mbstring --enable-mbregex --enable-zend-multibyte ; configure line Reproduce code: --- http://www.diptyque.net/bugs/mbinfo.php ; running PHP 4.4 as an apache module ; display charset is set to UTF-8 ; when internal encoding is set to UTF-8, ; strlen() returns the wrong character count ; (e.g. 18 instead of 19) http://www.diptyque.net/bugs/mbinfo.phps ; source code Expected result: string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage Actual result: -- string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
#38577 [Fbk-Opn]: Changing internal character encoding affects function overloading
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net -Status: Feedback +Status: Open Bug Type: mbstring related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Agreed but I'm not making things up, you know. Something is obviously wrong on my Apache 1.3.34 setup. Could this be a conflict with some extension or Apache module? Of course, no opcode cache is running. Any tip welcome. This weird behavior has been plaguing me for 2 months now and rebuilding PHP doesn't seem to help. I wrote a second test case which demonstrates that function overloading is effectively taking place sporadically while running under apache SAPI -- strlen() may accept the optional encoding argument (!?) as shown in the script output below. http://www.diptyque.net/bugs/mbinfo2.php http://www.diptyque.net/bugs/mbinfo2.phps ; source code =begin [diptyque] % GET http://www.diptyque.net/bugs/mbinfo2.php preint(72208) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) int(18) /pre =end If I do run the same script through PHP CLI or FastCGI, I get the following expected warnings: PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 17 PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 25 Previous Comments: [2006-08-24 15:15:31] [EMAIL PROTECTED] Please try with minimal configuration (like ./configure --enable-mbstring) and PHP CLI. If you're still able to reproduce it, you're likely to be the only person who can help you, since I really doubt anyone else can do it. [2006-08-24 15:04:03] php at diptyque dot net I moved mbstring function overload initial setting (6) from my php.ini to specific virtual hosts configuration sections but to no avail. It would seem that some Apache processes get it right while others get it wrong (!) This is quite weird -- for example, process #58902 returns int(18) while #58914 returns int(19). [diptyque] % GET http://localhost/bugs/mbinfo2.php preint(58902) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(18) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) /pre [diptyque] % GET http://localhost/bugs/mbinfo2.php preint(58914) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(5) UTF-8 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) -- bool(true) string(10) ISO-8859-1 string(10) ISO-8859-1 string(1) 0 string(19) Méthodes de codage int(19) /pre [2006-08-24 12:41:06] [EMAIL PROTECTED] Right, int(19) is what I get on Linux and FreeBSD 5.4. [2006-08-24 12:33:17] php at diptyque dot net Oops, my mistake. You should swap Expected and Actual results. Actual result is int(18) !? Expected result is int(19). [2006-08-24 12:28:30] php at diptyque dot net Granted I could not reproduce either this bug using a WAMP setup but did you follow the hyperlink I gave on my FreeBSD-based server, where you can consistently replicate this bug on each GET request? 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577edit=1
