Bug #60080 [Opn->Bgs]: out of memory error
Edit report at https://bugs.php.net/bug.php?id=60080&edit=1 ID: 60080 Updated by: larue...@php.net Reported by:pnkrocks at gmail dot com Summary:out of memory error -Status: Open +Status: Bogus Type: Bug Package:*General Issues Operating System: Solaris 10 PHP Version:Irrelevant Block user comment: N Private report: N 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: [2011-10-17 17:17:55] pnkrocks at gmail dot com Description: using mysqli Fatal error: Out of memory (allocated 6291456) (tried to allocate 4294967294 bytes) in /opt/piwik/libs/Zend/Db/Statement/Mysqli.php on line 255 -- Edit this bug report at https://bugs.php.net/bug.php?id=60080&edit=1
Bug #60090 [Opn->Bgs]: string "<" bug
Edit report at https://bugs.php.net/bug.php?id=60090&edit=1 ID: 60090 Updated by: larue...@php.net Reported by:karunungan dot odesk at gmail dot com Summary:string "<" bug -Status: Open +Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Windows 7 PHP Version:5.3.8 Block user comment: N Private report: N 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 I think you meaning in Browser. you can run the script in CMD to look at the result Previous Comments: [2011-10-19 03:31:19] karunungan dot odesk at gmail dot com Description: Variables containing a less than sign at the start immediately followed by a character does not evaluate (nothing is returned). If the character is followed by other characters such as or \n, the correct string is returned. Test script: --- $foobar = "https://bugs.php.net/bug.php?id=60090&edit=1
[PHP-BUG] Bug #60090 [NEW]: string "<" bug
From: Operating system: Windows 7 PHP version: 5.3.8 Package: Scripting Engine problem Bug Type: Bug Bug description:string "<" bug Description: Variables containing a less than sign at the start immediately followed by a character does not evaluate (nothing is returned). If the character is followed by other characters such as or \n, the correct string is returned. Test script: --- $foobar = "https://bugs.php.net/bug.php?id=60090&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60090&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60090&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60090&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60090&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60090&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60090&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60090&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60090&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60090&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60090&r=support Expected behavior: https://bugs.php.net/fix.php?id=60090&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60090&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60090&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60090&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60090&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60090&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60090&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60090&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60090&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60090&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60090&r=mysqlcfg
Bug #60074 [Com]: Stack trace truncated for long paths
Edit report at https://bugs.php.net/bug.php?id=60074&edit=1
ID: 60074
Comment by: anon at anon dot anon
Reported by:tyr...@php.net
Summary:Stack trace truncated for long paths
Status: Bogus
Type: Bug
Package:Scripting Engine problem
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
When would you ever need a thousand character path, honestly?!
Previous Comments:
[2011-10-18 23:03:15] fel...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You have to change the log_errors_max_len INI entry. (defaults to 1024)
[2011-10-16 22:44:04] tyr...@php.net
Description:
running the test script(via php -n -f test.php) in my home directory gives me:
Fatal error: Uncaught exception 'Exception' with message 'Foo' in
/home/tyrael/test.php:8
Stack trace:
#0 /home/tyrael/test.php(4): b()
#1 /home/tyrael/test.php(11): a()
#2 {main}
thrown in /home/tyrael/test.php on line 8
running the same script in a directory with a long path gives me:
Fatal error: Uncaught exception 'Exception' with message 'Foo' in
/home/tyrael/12345678901234567890123456789012345678901234567890/1234567890123456
7890123456789012345678901234567890/123456789012345678901234567890123456789012345
67890/12345678901234567890123456789012345678901234567890/12345678901234567890123
456789012345678901234567890/12345678901234567890123456789012345678901234567890/1
2345678901234567890123456789012345678901234567890/123456789012345678901234567890
12345678901234567890/foo/12345678901234567890123456789012345678901234567890/1234
5678901234567890123456789012345678901234567890/123456789012345678901234567890123
45678901234567890/12345678901234567890123456789012345678901234567890/12345678901
234567890123456789012345678901234567890/1234567890123456789012345678901234567890
1234567890/12345678901234567890123456789012345678901234567890/123456789012345678
90123456789012345678901234567890/12345678901234567890123456789012345678901234567
890/12345678901234567890123456789012345678901234567890/1234567890123456789012345
67890123456 in
/home/tyrael/12345678901234567890123456789012345678901234567890/1234567890123456
7890123456789012345678901234567890/123456789012345678901234567890123456789012345
67890/12345678901234567890123456789012345678901234567890/12345678901234567890123
456789012345678901234567890/12345678901234567890123456789012345678901234567890/1
2345678901234567890123456789012345678901234567890/123456789012345678901234567890
12345678901234567890/foo/12345678901234567890123456789012345678901234567890/1234
5678901234567890123456789012345678901234567890/123456789012345678901234567890123
45678901234567890/12345678901234567890123456789012345678901234567890/12345678901
234567890123456789012345678901234567890/1234567890123456789012345678901234567890
1234567890/12345678901234567890123456789012345678901234567890/123456789012345678
90123456789012345678901234567890/12345678901234567890123456789012345678901234567
890/12345678901234567890123456789012345678901234567890/1234567890123456789012345
6789012345678901234567890/12345678901234567890123456789012345678901234567890/123
45678901234567890123456789012345678901234567890/12345678901234567890123456789012
345678901234567890/12345678901234567890123456789012345678901234567890/1234567890
1234567890123456789012345678901234567890/123456789012345678901234567890123456789
01234567890/12345678901234567890123456789012345678901234567890/test.php on line
8
As you can see, the output doesn't contain the Stack trace anymore.
Test script:
---
// create a directory with a long path and run this script from that directory
https://bugs.php.net/bug.php?id=60074&edit=1
Bug #55737 [Com]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737&edit=1 ID: 55737 Comment by: richardpq at gmail dot com Reported by:stefan dot kaifer at hartmann dot info Summary:LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio Status: Feedback Type: Bug Package:MySQL related Operating System: opensuse 11.0 PHP Version:5.3.8 Assigned To:mysql Block user comment: N Private report: N New Comment: No, I dont have enable, my php.ini: ; open_basedir, if set, limits all file operations to the defined directory ; and below. This directive makes most sense if used in a per-directory ; or per-virtualhost web server configuration file. This directive is ; *NOT* affected by whether Safe Mode is turned On or Off. ; http://php.net/open-basedir ;open_basedir = Also has the first guy said... I can use LOAD DATA LOCAL INFILE, from MySql client but not from an application using PHP. Previous Comments: [2011-10-18 20:23:34] and...@php.net mysqlnd allows LOAD DATA LOCAL in all cases but if open_basedir is enabled. If open_basedir is set it is disabled regardless where the file to be loaded resides. This might be too strict for shared envs. Do you have open_basedir enabled? [2011-10-18 16:27:34] denis_truffaut at hotmail dot com Related bugs : https://bugs.php.net/bug.php?id=46964 https://bugs.php.net/bug.php?id=54158 A PHP Dev said it was resolved in 5.3.6, but it came back. As it is a very common usage of MySQL, especialy to save/import data, it had to be fixed in priority. The override PDO::MYSQL_ATTR_LOCAL_INFILE => 1 also doesn't not work. What to do ?! :O [2011-10-03 21:08:08] richardpq at gmail dot com Hi I have exact the same problem, like you I compile php using those options, I have the same php version and mysql 5.5.15, have you resolve the problem? [2011-09-20 09:49:56] stefan dot kaifer at hartmann dot info Description: Hello I've compiled php myself with this command: ./configure --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd Now my php-applications can't use "LOAD DATA LOCAL INFILE '/tmp/import-20110919173927-78613.txt' INTO TABLE ..." anymore! On the command prompt I can use "LOAD DATA LOCAL INFILE", that means mysql server allows me to use "LOAD DATA LOCAL INFILE", the server variable "local infile" is setted to "ON" (with "local-infile=1" in the my.cnf). It seems a php-mysqlnd problem. Neither the mysql nor the mysqli extensions allows me to use "LOAD DATA LOCAL INFILE". This is the Connect-line in my code: $Connect = mysql_connect($DB_Host .":".$DB_Port,$DB_User,$DB_Password, FALSE, 128); The error is: #1148 - The used command is not allowed with this MySQL version Mysql-server: 5.5.16 PHP: 5.3.8 PHP-MYSQL-client: mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ PHPINFO: mysql MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Directive Local Value Master Value mysql.allow_local_infileOn On mysql.allow_persistent Off Off mysql.connect_timeout 60 60 mysql.default_host no valueno value mysql.default_password no valueno value mysql.default_port no valueno value mysql.default_socketno valueno value mysql.default_user no valueno value mysql.max_links Unlimited Unlimited mysql.max_persistentUnlimited Unlimited mysql.trace_modeOff Off mysqli MysqlI Support enabled Client API library version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Active Persistent Links 0 Inactive Persistent Links 0 Active Links0 Directive Local Value Master Value mysqli.allow_local_infile On On mysqli.allow_persistent On On mysqli.default_host no valueno value mysqli.default_port 33063306 mysqli.default_pw no valueno value mysqli.default_socket no valueno value mysqli.default_user no valueno value mysqli.max_linksUnlimited Unlimited mysqli.max_persistent Unlimited Unlimited mysqli.reconnectOff Off mysqlnd mysqlnd enabled Version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Compression supported SSL supported Command buffer size 4096 Read buffer size32768 Read timeout31536000 Collecting statistics Yes Collecting memory statisticsNo Tracing n/a I hope, that somebody can help. Best regards Stefan Test
php-bugs@lists.php.net
Edit report at https://bugs.php.net/bug.php?id=60082&edit=1 ID: 60082 Updated by: larue...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject(&$ref). Status: Open Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 -Assigned To: +Assigned To:helly Block user comment: N Private report: N New Comment: helly, plz look at this. thanks :) Previous Comments: [2011-10-18 12:51:03] larue...@php.net The following patch has been added/updated: Patch Name: bug60082.phpt Revision: 1318942263 URL: https://bugs.php.net/patch-display.php?bug=60082&patch=bug60082.phpt&revision=1318942263 [2011-10-18 12:46:20] larue...@php.net The following patch has been added/updated: Patch Name: bug60082.patch Revision: 1318941980 URL: https://bugs.php.net/patch-display.php?bug=60082&patch=bug60082.patch&revision=1318941980 [2011-10-18 09:38:44] larue...@php.net $test = new ArrayObject(&$test) will make the intern->array a object; thus, there will be a infinite loop between spl_array_get_properties and spl_array_get_hash_table(call to HASH_OF which will call to spl_array_get_properties). then PHP will segfault due to stack overflow... I have tried to use SEPARATE_ARG_IF_REF to fix this segfault, but there is a test faild (ext/spl/tests/array_004.phpt) thanks [2011-10-17 22:30:44] tklingenberg at lastflood dot net Description: 100% CPU / when using references with ArrayObject(&$ref). Passing a copy works. Test script: --- $test = array(); $test = new ArrayObject(&$test); $test['a'] = $test['b']; or: $GLOBALS = new ArrayObject(&$GLOBALS); $a = $GLOBALS['b']; Expected result: Set $test['a'] or $a to NULL with an undefined offset/index warning. Actual result: -- Endless Loop / CPU goes up 100% and stays. -- Edit this bug report at https://bugs.php.net/bug.php?id=60082&edit=1
Bug #60074 [Opn->Bgs]: Stack trace truncated for long paths
Edit report at https://bugs.php.net/bug.php?id=60074&edit=1
ID: 60074
Updated by: fel...@php.net
Reported by:tyr...@php.net
Summary:Stack trace truncated for long paths
-Status: Open
+Status: Bogus
Type: Bug
Package:Scripting Engine problem
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
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
You have to change the log_errors_max_len INI entry. (defaults to 1024)
Previous Comments:
[2011-10-16 22:44:04] tyr...@php.net
Description:
running the test script(via php -n -f test.php) in my home directory gives me:
Fatal error: Uncaught exception 'Exception' with message 'Foo' in
/home/tyrael/test.php:8
Stack trace:
#0 /home/tyrael/test.php(4): b()
#1 /home/tyrael/test.php(11): a()
#2 {main}
thrown in /home/tyrael/test.php on line 8
running the same script in a directory with a long path gives me:
Fatal error: Uncaught exception 'Exception' with message 'Foo' in
/home/tyrael/12345678901234567890123456789012345678901234567890/1234567890123456
7890123456789012345678901234567890/123456789012345678901234567890123456789012345
67890/12345678901234567890123456789012345678901234567890/12345678901234567890123
456789012345678901234567890/12345678901234567890123456789012345678901234567890/1
2345678901234567890123456789012345678901234567890/123456789012345678901234567890
12345678901234567890/foo/12345678901234567890123456789012345678901234567890/1234
5678901234567890123456789012345678901234567890/123456789012345678901234567890123
45678901234567890/12345678901234567890123456789012345678901234567890/12345678901
234567890123456789012345678901234567890/1234567890123456789012345678901234567890
1234567890/12345678901234567890123456789012345678901234567890/123456789012345678
90123456789012345678901234567890/12345678901234567890123456789012345678901234567
890/12345678901234567890123456789012345678901234567890/1234567890123456789012345
67890123456 in
/home/tyrael/12345678901234567890123456789012345678901234567890/1234567890123456
7890123456789012345678901234567890/123456789012345678901234567890123456789012345
67890/12345678901234567890123456789012345678901234567890/12345678901234567890123
456789012345678901234567890/12345678901234567890123456789012345678901234567890/1
2345678901234567890123456789012345678901234567890/123456789012345678901234567890
12345678901234567890/foo/12345678901234567890123456789012345678901234567890/1234
5678901234567890123456789012345678901234567890/123456789012345678901234567890123
45678901234567890/12345678901234567890123456789012345678901234567890/12345678901
234567890123456789012345678901234567890/1234567890123456789012345678901234567890
1234567890/12345678901234567890123456789012345678901234567890/123456789012345678
90123456789012345678901234567890/12345678901234567890123456789012345678901234567
890/12345678901234567890123456789012345678901234567890/1234567890123456789012345
6789012345678901234567890/12345678901234567890123456789012345678901234567890/123
45678901234567890123456789012345678901234567890/12345678901234567890123456789012
345678901234567890/12345678901234567890123456789012345678901234567890/1234567890
1234567890123456789012345678901234567890/123456789012345678901234567890123456789
01234567890/12345678901234567890123456789012345678901234567890/test.php on line
8
As you can see, the output doesn't contain the Stack trace anymore.
Test script:
---
// create a directory with a long path and run this script from that directory
https://bugs.php.net/bug.php?id=60074&edit=1
Bug #55712 [Asn]: FastCGI causes event 1000 application error when using number_format(0)
Edit report at https://bugs.php.net/bug.php?id=55712&edit=1 ID: 55712 User updated by:ken at simplecommerce dot com Reported by:ken at simplecommerce dot com Summary:FastCGI causes event 1000 application error when using number_format(0) Status: Assigned Type: Bug Package:IIS related Operating System: Windows server 2008 R2 PHP Version:5.3.8 Assigned To:mattficken Block user comment: N Private report: N New Comment: Any update on this issue? Previous Comments: [2011-09-25 21:37:56] paj...@php.net Matt, please take the hand here. [2011-09-25 21:31:58] ken at simplecommerce dot com Here is an update. We made our own function to bypass number_format. We found another error which causes php fastcgi to crash. round(0). I am assuming that number_format uses round? So we are bypassing round for the moment to see if we encounter any other problems. But right now both number_format and round 0 crashes. I hope you guys are aware of this or are testing this also. [2011-09-23 11:23:09] ken at simplecommerce dot com Ok so we had a local expert go through the debugging and see if he could find anything wrong with our setup, and from what he tells me, it really is number_format(0) that seems to crash the IIS7/FastCGI server with a 500 error. [2011-09-18 17:57:19] ken at simplecommerce dot com I have used Debug Diag 1.2 to create a crash hang report on the php-cgi.exe process. Here is the result I have got from the analysis. If it can help figure out if this is indeed a bug or it's something else. I am trying to narrow it down to get a possible fix. http://www.mediafire.com/?ezxjt68v0axozif [2011-09-18 17:11:48] ken at simplecommerce dot com Thanks for the link. It is a good alternative, but if possible I would prefer a solution to my current problem without having to go through all my files and re-code using this new method. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55712 -- Edit this bug report at https://bugs.php.net/bug.php?id=55712&edit=1
Bug #54864 [Opn->Fbk]: Memory leak associated with mysql connector
Edit report at https://bugs.php.net/bug.php?id=54864&edit=1
ID: 54864
Updated by: and...@php.net
Reported by:jas at rephunter dot net
Summary:Memory leak associated with mysql connector
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: FreeBSD
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Hi,
I suppose there is no problem but the following occurs. Before 5.3 PHP used
libmysql as underlying library. Since 5.3 there is an option to use PHP's
implementation of the client/server protocol, the mysqlnd library. This library
uses PHP's memory allocation functions, thus affects memory_get_usage(). When
you used libmysql and it allocated memory, this memory wasn't reported by
memory_get_usage() because the latter counts only the memory allocated by the
PHP's memory allocator.
To see if there is really a leak, you have to free your result sets and then
dereference all the variables which point to the result set. If the memory
usage is still high, there could be a problem. There is no problem, if you have
created big SQL statement and later the reported used memory is still high,
because mysqlnd has a buffer onto which data packets are created. When big SQL
statement comes, the buffer needs to be enlarged and later it is not made
smaller.
Previous Comments:
[2011-07-05 17:54:56] jas at rephunter dot net
A complete script was requested. To run the test you will need some mysql
tables. I can provide sanitized versions of production data. Please advise as
to how to upload.
Here is the script.
DATE_ADD(CURDATE(), INTERVAL 5 - 1 DAY)
AND d.datestart <= DATE_ADD(CURDATE(), INTERVAL 5 DAY)
UNION
SELECT
12 as usertypeid,
u.userid,
opt_out,
DATE_FORMAT(dateentry, '%Y/%m/%d'),
DATE_FORMAT(dateentry, '%m/%d/%Y'),
DATE_FORMAT(dateupdate, '%Y/%m/%d'),
DATE_FORMAT(dateupdate, '%m/%d/%Y %h:%i %p'),
referrerid,
referralcnt,
phone1,
email1,
u.status,
DATE_FORMAT(datestatus, '%Y/%m/%d'),
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, '','','','','','','','','',''
, fname, lname, address1, address2, city, state, postal
FROM user u
WHERE u.status NOT IN ('R')
AND profile_complete & 7 <> 7 ORDER BY userid DESC
SQL;
}
[2011-05-26 14:57:36] johan...@php.net
Please provide a _complete_ script for testing. Also mind that increasing
memory_get_usage() values don't necessarily represent memory leaks but includes
different cache data or memory which will be re-used.
[2011-05-19 18:32:45] jas at rephunter dot net
Description:
I have found a memory leak in connection with several production PHP scripts.
While there are many bug reports relating to memory leaks, I did not find
anything similar to our situation, which is very easy to reproduce.
The scripts that have been affected by this memory leak have been in continuous
production use since 2006. We did not notice a memory leak prior to when we
first upgraded to PHP 5.3.5. It is possible that there was a smaller leak prior
to this time that merely escaped notice. However, before reporting the problem,
we upgraded to 5.3.6 to make sure it had not been corrected. The results in
this
ticket are thus for 5.3.6.
Below I have given the main loop of a "small reproducible code." As you can
see,
the only thing done in this test is to fetch the rows, and print out memory
usage every 3000 rows.
Regarding the mysql connector: originally the test was run with mysqli_connect.
It was suggested via Experts-Exchange to try the mysql_connector. This was done
but the results were identical. The full script can works with both
mysql_connect and mysqli_connect, controlled by a define.
The bug signs:
1. On 5.3.6, the "after SQL" memory usage jumps to 13MB, whereas on 5.2.4 it
stays at the initial low value (262144 on 5.2.4 but 786432 on 5.3.6).
2. On 5.3.6, the memory usage grows dramatically, whereas on 5.2.4 it does not
(the "id" lines are displayed after each 3000 rows, where the id is the primary
key for the row). In the production scripts, this leads to a crash when the
memory limit is exceeded.
Please note:
1. the SQL statement is composed of a UNION of 5 relatively simple SELECTs,
making the single statement relatively complex.
2. The expected and actual results shown below are achieved by connecting to
the
same database.
I you would like the URL of the actual script,
Bug #60089 [PATCH]: DateTime::createFromFormat() U after u nukes microtime
Edit report at https://bugs.php.net/bug.php?id=60089&edit=1
ID: 60089
Patch added by: sala...@php.net
Reported by:sala...@php.net
Summary:DateTime::createFromFormat() U after u nukes
microtime
Status: Assigned
Type: Bug
Package:Date/time related
PHP Version:trunk-SVN-2011-10-18 (SVN)
Assigned To:derickr
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: trunk-60089-quickfix
Revision: 1318972043
URL:
https://bugs.php.net/patch-display.php?bug=60089&patch=trunk-60089-quickfix&revision=1318972043
Previous Comments:
[2011-10-18 21:03:32] sala...@php.net
Description:
A format string containing a Unix timestamp at any point after a microsecond
value
leaves the microseconds unset in the resulting DateTime object.
Test script:
---
format('U u'));
?>
Expected result:
string(16) "123456790 123456"
Actual result:
--
string(16) "123456790 00"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60089&edit=1
[PHP-BUG] Bug #60089 [NEW]: DateTime::createFromFormat() U after u nukes microtime
From:
Operating system:
PHP version: trunk-SVN-2011-10-18 (SVN)
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::createFromFormat() U after u nukes microtime
Description:
A format string containing a Unix timestamp at any point after a
microsecond value
leaves the microseconds unset in the resulting DateTime object.
Test script:
---
format('U
u'));
?>
Expected result:
string(16) "123456790 123456"
Actual result:
--
string(16) "123456790 00"
--
Edit bug report at https://bugs.php.net/bug.php?id=60089&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60089&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60089&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60089&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60089&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60089&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60089&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60089&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60089&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60089&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60089&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60089&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60089&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60089&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60089&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60089&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60089&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60089&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60089&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60089&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60089&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60089&r=mysqlcfg
Bug #55860 [Opn]: mysqli_refresh still exists and is undocumented
Edit report at https://bugs.php.net/bug.php?id=55860&edit=1
ID: 55860
Updated by: and...@php.net
Reported by:u...@php.net
Summary:mysqli_refresh still exists and is undocumented
Status: Open
Type: Bug
-Package:MySQLi related
+Package:Documentation problem
PHP Version:5.4SVN-2011-10-06 (snap)
-Assigned To:
+Assigned To:philip
Block user comment: N
Private report: N
New Comment:
This function needs documentation. Here is the mysql documentation:
http://dev.mysql.com/doc/refman/5.0/en/mysql-refresh.html
Previous Comments:
[2011-10-06 13:06:48] u...@php.net
Description:
mysqli_refresh() exists in 5.4
sapi/cli/php -r 'mysqli_refresh("foo");'
PHP Warning: mysqli_refresh() expects exactly 2 parameters, 1 given in Command
line code on line 1
According to the documentation is it only available until 5.3
nixnutz@linux-fuxh:~/php/phpdoc> grep -R refresh en/reference/mysqli/
en/reference/mysqli/versions.xml:
en/reference/mysqli/.svn/text-base/versions.xml.svn-base:
Test script:
---
See above
Expected result:
Either update docs or remove function ?! Deprecate it at least...
--
Edit this bug report at https://bugs.php.net/bug.php?id=55860&edit=1
[PHP-BUG] Bug #60088 [NEW]: Code Error in cairo_surface.c
From: Operating system: ubuntu 10.04 PHP version: 5.3SVN-2011-10-18 (SVN) Package: *Graphics related Bug Type: Bug Bug description:Code Error in cairo_surface.c Description: I found a small coding bug in cairo_surface.c. Trying to do a "make" of the cairo code I get an error message on line 647 of cairo_surface.c (transcript partially truncated at front):- Downloads/pecl-cairo/cairo_surface.c: In function âphp_cairo_get_surface_ceâ: Downloads/pecl-cairo/cairo_surface.c:647: error: âCAIRO_SURFACE_TYPE_RECORDINGâ undeclared (first use in this function) Downloads/pecl-cairo/cairo_surface.c:647: error: (Each undeclared identifier is reported only once Downloads/pecl-cairo/cairo_surface.c:647: error: for each function it appears in.) When I check the relevant section of the source file (cairo_surface.c) I see the following (in part): == #ifdef CAIRO_HAS_SVG_SURFACE case CAIRO_SURFACE_TYPE_SVG: type = cairo_ce_cairosvgsurface; break; #endif #ifdef CAIRO_HAS_PS_SURFACE case CAIRO_SURFACE_TYPE_PS: type = cairo_ce_cairopssurface; break; #endif #ifdef CAIRO_HAS_PS_SURFACE case CAIRO_SURFACE_TYPE_RECORDING: type = cairo_ce_cairorecordingsurface; break; #endif == The #ifdef CAIRO_HAS_PS_SURFACE has been duplicated [in error]. Test script: --- I was able to fix this simply by changing the *second* instance of the ifdef statement to read:- #ifdef CAIRO_HAS_RECORDING_SURFACE case CAIRO_SURFACE_TYPE_RECORDING: type = cairo_ce_cairorecordingsurface; break; #endif [i.e. replace _PS_ with _RECORDING_ ] That seems to solve the problem and I can get the source to compile and install cleanly from that point onwards. I hope I'm reporting this at the right place!!! -- Edit bug report at https://bugs.php.net/bug.php?id=60088&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60088&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60088&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60088&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60088&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60088&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60088&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60088&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60088&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60088&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60088&r=support Expected behavior: https://bugs.php.net/fix.php?id=60088&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60088&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60088&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60088&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60088&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60088&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60088&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60088&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60088&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60088&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60088&r=mysqlcfg
Bug #55737 [Opn->Fbk]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737&edit=1 ID: 55737 Updated by: and...@php.net Reported by:stefan dot kaifer at hartmann dot info Summary:LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio -Status: Open +Status: Feedback Type: Bug Package:MySQL related Operating System: opensuse 11.0 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: mysqlnd allows LOAD DATA LOCAL in all cases but if open_basedir is enabled. If open_basedir is set it is disabled regardless where the file to be loaded resides. This might be too strict for shared envs. Do you have open_basedir enabled? Previous Comments: [2011-10-18 16:27:34] denis_truffaut at hotmail dot com Related bugs : https://bugs.php.net/bug.php?id=46964 https://bugs.php.net/bug.php?id=54158 A PHP Dev said it was resolved in 5.3.6, but it came back. As it is a very common usage of MySQL, especialy to save/import data, it had to be fixed in priority. The override PDO::MYSQL_ATTR_LOCAL_INFILE => 1 also doesn't not work. What to do ?! :O [2011-10-03 21:08:08] richardpq at gmail dot com Hi I have exact the same problem, like you I compile php using those options, I have the same php version and mysql 5.5.15, have you resolve the problem? [2011-09-20 09:49:56] stefan dot kaifer at hartmann dot info Description: Hello I've compiled php myself with this command: ./configure --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd Now my php-applications can't use "LOAD DATA LOCAL INFILE '/tmp/import-20110919173927-78613.txt' INTO TABLE ..." anymore! On the command prompt I can use "LOAD DATA LOCAL INFILE", that means mysql server allows me to use "LOAD DATA LOCAL INFILE", the server variable "local infile" is setted to "ON" (with "local-infile=1" in the my.cnf). It seems a php-mysqlnd problem. Neither the mysql nor the mysqli extensions allows me to use "LOAD DATA LOCAL INFILE". This is the Connect-line in my code: $Connect = mysql_connect($DB_Host .":".$DB_Port,$DB_User,$DB_Password, FALSE, 128); The error is: #1148 - The used command is not allowed with this MySQL version Mysql-server: 5.5.16 PHP: 5.3.8 PHP-MYSQL-client: mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ PHPINFO: mysql MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Directive Local Value Master Value mysql.allow_local_infileOn On mysql.allow_persistent Off Off mysql.connect_timeout 60 60 mysql.default_host no valueno value mysql.default_password no valueno value mysql.default_port no valueno value mysql.default_socketno valueno value mysql.default_user no valueno value mysql.max_links Unlimited Unlimited mysql.max_persistentUnlimited Unlimited mysql.trace_modeOff Off mysqli MysqlI Support enabled Client API library version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Active Persistent Links 0 Inactive Persistent Links 0 Active Links0 Directive Local Value Master Value mysqli.allow_local_infile On On mysqli.allow_persistent On On mysqli.default_host no valueno value mysqli.default_port 33063306 mysqli.default_pw no valueno value mysqli.default_socket no valueno value mysqli.default_user no valueno value mysqli.max_linksUnlimited Unlimited mysqli.max_persistent Unlimited Unlimited mysqli.reconnectOff Off mysqlnd mysqlnd enabled Version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Compression supported SSL supported Command buffer size 4096 Read buffer size32768 Read timeout31536000 Collecting statistics Yes Collecting memory statisticsNo Tracing n/a I hope, that somebody can help. Best regards Stefan Test script: --- $Connect = mysql_connect($DB_Host .":".$DB_Port,$DB_User,$DB_Password, FALSE, 128); $StrSQL = "LOAD DATA LOCAL INFILE '/tmp/test.txt' INTO TABLE testtable FIELDS TERMINATED BY '' LINES STARTING BY '' TERMINATED BY '' IGNORE 1 LINES ."; $Result1 = mysql_db_query($DB,$StrSQL,$Connect); -- Edit this bug report at https://bugs.php.net/bug.php?id=55737&edit=1
Bug #55741 [Asn->Fbk]: Warning thrown
Edit report at https://bugs.php.net/bug.php?id=55741&edit=1
ID: 55741
Updated by: and...@php.net
Reported by:patrick_adrichem at hotmail dot com
Summary:Warning thrown
-Status: Assigned
+Status: Feedback
Type: Bug
Package:MySQL related
Operating System: linux
PHP Version:5.3SVN-2011-09-20 (SVN)
Assigned To:uw
Block user comment: N
Private report: N
New Comment:
Hi,
I wasn't able to reproduce with 5.3-svn and two builds:
- mysqlnd
- libmysql
Here is my mysqlnd output:
$ ./php -r
'error_reporting(E_ALL);$c=mysql_connect("127.0.0.1","root","root");var_dump($c);var_dump(mysql_query("set
@@wait_timeout=5",$c));sleep(7);var_dump(mysql_ping($c));'
resource(6) of type (mysql link)
bool(true)
Warning: mysql_ping(): MySQL server has gone away in Command line code on line 1
bool(false)
Here is my libmysql output:
$ ./php -r
'error_reporting(E_ALL);$c=mysql_connect("127.0.0.1","root","root");var_dump($c);var_dump(mysql_query("set
@@wait_timeout=5",$c));sleep(7);var_dump(mysql_ping($c));'
resource(4) of type (mysql link)
bool(true)
bool(false)
I suspect how it could be shut up, but I can't reproduce it to be able to test
it.
Previous Comments:
[2011-09-20 14:50:21] larue...@php.net
ulf, plz look at this.
[2011-09-20 14:47:19] patrick_adrichem at hotmail dot com
Description:
---
>From manual page:
>http://www.php.net/function.mysql-ping#refsect1-function.mysql-ping-description
---
Mysql_ping is in my vision used to check wether your connection is still alive,
by pinging the server since PHP 5.0.38 this function no longer autoreconnects,
so its a real "Check if connection is alive" function. However if the
connection is not alive it still throws a warning:
mysql_ping(): 8 is not a valid MySQL-Link resource
Which is obvious, because thats why you use this function...
Test script:
---
https://bugs.php.net/bug.php?id=55741&edit=1
Req #60087 [Com]: release() function and __release() method
Edit report at https://bugs.php.net/bug.php?id=60087&edit=1
ID: 60087
Comment by: luke at cywh dot com
Reported by:luke at cywh dot com
Summary:release() function and __release() method
Status: Open
Type: Feature/Change Request
Package:Class/Object related
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Here's another demo that demonstrates the exact functionality I describe:
gc_disable();
class A {
function __construct() {
$this->b = new B($this);
}
// function __release() {
// unset($this->b);
// }
}
class B {
function __construct($parent = NULL) {
$this->parent = $parent;
}
}
function release(&$var) {
if(is_object($var)){
if(method_exists($var, '__release')) {
$var->__release();
}
else {
foreach(array_keys(get_object_vars($var)) as $k) {
$v = $var->$k;
$var->$k = NULL;
release($v);
}
}
}
else if(is_array($var)) {
foreach($var as &$c) {
release($c);
}
}
$obj = NULL;
}
for($i = 0; $i < 100; $i++) {
$a = new A();
release($a);
}
I realize that "array_keys(get_object_vars($var))" is horrible, especially
since
it's limited by scope. An internal version wouldn't have this sort of
limitation.
Previous Comments:
[2011-10-18 19:39:30] luke at cywh dot com
Description:
This is in reference to circular references, as outlined in this bug:
https://bugs.php.net/bug.php?id=33595
The "solution" in PHP 5.3 is the garbage collector, which seems to work well.
But it's lazy, meaning it only frees memory when it has to. On a complex web
application I came across a situation where the garbage collector didn't free
memory like it should have. Eventually the script ran out of memory. Granted it
got a lot farther than 5.2 did.
The most common occurrence (only?) of a circular reference is a parent and
child
relationship with objects. The unset() function is useless because a reference
is held, so __destruct is never ran.
I propose an additional more aggressive function called release(). It would
function just like unset(), but would additionally call a __release() method
within the object allowing for cleanup before unsetting the object.
If the __release() method doen't exist perhaps PHP could unset the properties
itself, and call __release() on any objects that may be stored in an
array/property.
I've added a demo of how this could work. The demo is different in that it
requires __release(). An internal solution may not.
Test script:
---
gc_disable();
interface Release {
function __release();
}
class A implements Release {
function __construct() {
$this->b = new B($this);
}
function __release() {
unset($this->b);
}
}
function release(Release &$obj) {
$obj->__release();
$obj = NULL;
}
class B {
function __construct($parent = NULL) {
$this->parent = $parent;
}
}
for($i = 0; $i < 100; $i++) {
$a = new A();
release($a);
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60087&edit=1
[PHP-BUG] Req #60087 [NEW]: release() function and __release() method
From:
Operating system:
PHP version: 5.3.8
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:release() function and __release() method
Description:
This is in reference to circular references, as outlined in this bug:
https://bugs.php.net/bug.php?id=33595
The "solution" in PHP 5.3 is the garbage collector, which seems to work
well.
But it's lazy, meaning it only frees memory when it has to. On a complex
web
application I came across a situation where the garbage collector didn't
free
memory like it should have. Eventually the script ran out of memory.
Granted it
got a lot farther than 5.2 did.
The most common occurrence (only?) of a circular reference is a parent and
child
relationship with objects. The unset() function is useless because a
reference
is held, so __destruct is never ran.
I propose an additional more aggressive function called release(). It would
function just like unset(), but would additionally call a __release()
method
within the object allowing for cleanup before unsetting the object.
If the __release() method doen't exist perhaps PHP could unset the
properties
itself, and call __release() on any objects that may be stored in an
array/property.
I've added a demo of how this could work. The demo is different in that it
requires __release(). An internal solution may not.
Test script:
---
gc_disable();
interface Release {
function __release();
}
class A implements Release {
function __construct() {
$this->b = new B($this);
}
function __release() {
unset($this->b);
}
}
function release(Release &$obj) {
$obj->__release();
$obj = NULL;
}
class B {
function __construct($parent = NULL) {
$this->parent = $parent;
}
}
for($i = 0; $i < 100; $i++) {
$a = new A();
release($a);
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60087&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60087&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60087&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60087&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60087&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60087&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60087&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60087&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60087&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60087&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60087&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60087&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60087&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60087&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60087&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60087&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60087&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60087&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60087&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60087&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60087&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60087&r=mysqlcfg
Req #55609 [Opn->Csd]: mysqlnd cannot be built shared
Edit report at https://bugs.php.net/bug.php?id=55609&edit=1 ID: 55609 Updated by: and...@php.net Reported by:johan...@php.net Summary:mysqlnd cannot be built shared -Status: Open +Status: Closed Type: Feature/Change Request Package:MySQL related Operating System: * PHP Version:trunk-SVN-2011-09-05 (SVN) -Assigned To: +Assigned To:andrey Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-09-06 16:41:12] johan...@php.net This bug has been fixed in SVN. 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. [2011-09-06 16:38:09] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=316281 Log: - Fix bug #55609 (mysqlnd cannot be built shared) # This adds an option --enable-mysqlnd to explicitly built mysqlnd, like any # other extension it can be used with =shared to build mysqlnd shared; # mysqlnd will implicitly enabled when requested from another extension [2011-09-05 18:25:01] johan...@php.net The following patch has been added/updated: Patch Name: mysqlnd_build_shared.diff Revision: 1315247101 URL: https://bugs.php.net/patch-display.php?bug=55609&patch=mysqlnd_build_shared.diff&revision=1315247101 [2011-09-05 18:23:50] johan...@php.net The following patch has been added/updated: Patch Name: mysqlnd_build_shared.diff Revision: 1315247030 URL: https://bugs.php.net/patch-display.php?bug=55609&patch=mysqlnd_build_shared.diff&revision=1315247030 [2011-09-05 16:48:49] johan...@php.net The attached patch adds an option --enable-mysqlnd which can be used like any other normal configure option. Therefore mysqlnd could be built even when no other MySQL extension was activated. It's also possible to use --enable-mysqlnd=shared After applying this patch myslqnd won't compile shared due to issues in mysqlnd_compat.h The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55609 -- Edit this bug report at https://bugs.php.net/bug.php?id=55609&edit=1
Bug #55385 [Opn->Fbk]: mysqlnd doesn't connect using ssl
Edit report at https://bugs.php.net/bug.php?id=55385&edit=1
ID: 55385
Updated by: and...@php.net
Reported by:fuxa_kos at unihost dot cz
Summary:mysqlnd doesn't connect using ssl
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQL related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Hi, can you provide a packet dump from the wire. mysqlnd + ssl doesn't work for
localhost (unix socket) because of the limitations the PHP Streams impose on
mysqlnd, but here the case seems to be different?
Previous Comments:
[2011-10-03 20:43:52] dnsdns at gmail dot com
I forgot to mention that PHP was compiled with openssl support so mysqlnd could
have used it to connect.
There was no error about the connection, just the access denied coming from
mysql
5.1.
[2011-10-03 20:34:26] dnsdns at gmail dot com
Using PDO Mysql compiled with mysqlnd it doesnt work, if I recompile it with
libmysql the same code works.
It seems mysqlnd doesnt use the supplied keys and doesnt initiate ssl.
I am using PHP 5.3.8
$DB = new PDO("mysql:host=hostname;dbname=ssltest", 'test','mypass', array(
PDO::MYSQL_ATTR_SSL_KEY => '/path/client-key.pem',
PDO::MYSQL_ATTR_SSL_CERT => '/path/client-cert.pem',
PDO::MYSQL_ATTR_SSL_CA => '/path/cacert.pem'
));
[2011-08-11 13:27:41] fuxa_kos at unihost dot cz
PHP compiled by same way (and same OS and Mysql RPM's) with mysqlnd __can__
connect from Mysql 5.5 box to 5.1. But from 5.1 to 5.5 with mysqlnd __can not__
(but with libmysql works fine) - as I reported.
[2011-08-11 13:20:12] fuxa_kos at unihost dot cz
sry, box where I wrote that works fine haven't mysqlnd. When PHP is compiled
with mysqlnd (at this same box) doesn't work too.
I confirm for mysqlnd return
real_connect: false
var_dump($mirm->connect_error); var_dump($mirm->connect_errno);
NULL
int(0)
[2011-08-11 13:12:26] fuxa_kos at unihost dot cz
returns
connect_error: NULL
connect_errno: int(0)
I test it from other box with same OS and Mysql 5.1, works fine! But difference
this box have Mysql-server with have_openssl = YES. First case haven't Mysql
server.
I can test it from another box, with PHP from Zend Server CE, then give
additional fdb.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55385
--
Edit this bug report at https://bugs.php.net/bug.php?id=55385&edit=1
Req #27643 [Com]: include behavior (revisit #11326 and #9673)
Edit report at https://bugs.php.net/bug.php?id=27643&edit=1
ID: 27643
Comment by: clarkke8 at yahoo dot com
Reported by:schapht at drexel dot edu
Summary:include behavior (revisit #11326 and #9673)
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Mac OS 10.3.2
PHP Version:4.3.4
Block user comment: N
Private report: N
New Comment:
Still seeing this issue in 5.2. Very annoying. Ideally the include functions
(include, include_once, require, require_once) would not use the current
working
directory, but rather the value of dirname(__FILE__) when looking for an
included
file.
Previous Comments:
[2004-03-18 20:07:40] schapht at drexel dot edu
Description:
Php 4.3.4 still has this the issue reported in bugs
#11326 and #9673. Even though #11326 lists it as fixed
in (CVS/4.0.7).
Did the behavior change again? Is there a switch
somewhere I'm missing?
If not, would it be possible to add a switch (or another
function) so that includes could be based on the file
calling the include?
Reproduce code:
---
//index.php in ./
include_once("./include/A.class.php");
$a = new A();
echo $a->printer();
//A.class.php in ./include
include_once("./B.class.php");
class A {
function printer() {
$b = new B();
return $b->printer();
}
}
//B.class.php in ./include
class B {
function printer() {
return "did it work?";
}
}
Expected result:
did it work?
Actual result:
--
Warning: main(./B.class.php): failed to open stream: No
such file or directory in /Users/schapht/Sites/test/
include/A.class.php on line 3
Warning: main(): Failed opening './B.class.php' for
inclusion (include_path='.:/usr/local/lib/php') in /
Users/schapht/Sites/test/include/A.class.php on line 3
Fatal error: Cannot instantiate non-existent class: b in
/Users/schapht/Sites/test/include/A.class.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=27643&edit=1
Bug #54158 [Com]: MYSQLND + PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE
Edit report at https://bugs.php.net/bug.php?id=54158&edit=1 ID: 54158 Comment by: richardpq at gmail dot com Reported by:tamas at ideaweb dot hu Summary:MYSQLND + PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE Status: Closed Type: Bug Package:PDO related Operating System: Linux PHP Version:5.3.5 Assigned To:mysql Block user comment: N Private report: N New Comment: I don't get it, after 5.3.6 release was working? because I have 5.3.8 and it is no working https://bugs.php.net/bug.php?id=55737 Previous Comments: [2011-09-09 07:03:01] and...@php.net This bug has been fixed in SVN. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2011-09-02 13:53:30] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=316039 Log: Fix for Bug #54158 MYSQLND + PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE and a bunch of other small preprocessor fixes [2011-04-03 03:57:48] anthon dot pang at gmail dot com Sorry, you're right. My "workaround" is actually because MySQL is compiled with --enable-local-infile. [2011-04-03 01:08:09] anthon dot pang at gmail dot com As a workaround, I use PDO::ATTR_EMULATE_PREPARES. With 5.2.17 and 5.3.6 (using mysqlndb), both LOAD DATA INFILE and LOAD DATA LOCAL INFILE work on my Ubuntu 10.04 box, using PDO_MYSQL and MYSQLI extensions. [2011-03-04 10:21:43] and...@php.net to be fixed after 5.3.6 is released The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54158 -- Edit this bug report at https://bugs.php.net/bug.php?id=54158&edit=1
Bug #55737 [Com]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737&edit=1 ID: 55737 Comment by: denis_truffaut at hotmail dot com Reported by:stefan dot kaifer at hartmann dot info Summary:LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio Status: Open Type: Bug Package:MySQL related Operating System: opensuse 11.0 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Related bugs : https://bugs.php.net/bug.php?id=46964 https://bugs.php.net/bug.php?id=54158 A PHP Dev said it was resolved in 5.3.6, but it came back. As it is a very common usage of MySQL, especialy to save/import data, it had to be fixed in priority. The override PDO::MYSQL_ATTR_LOCAL_INFILE => 1 also doesn't not work. What to do ?! :O Previous Comments: [2011-10-03 21:08:08] richardpq at gmail dot com Hi I have exact the same problem, like you I compile php using those options, I have the same php version and mysql 5.5.15, have you resolve the problem? [2011-09-20 09:49:56] stefan dot kaifer at hartmann dot info Description: Hello I've compiled php myself with this command: ./configure --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd Now my php-applications can't use "LOAD DATA LOCAL INFILE '/tmp/import-20110919173927-78613.txt' INTO TABLE ..." anymore! On the command prompt I can use "LOAD DATA LOCAL INFILE", that means mysql server allows me to use "LOAD DATA LOCAL INFILE", the server variable "local infile" is setted to "ON" (with "local-infile=1" in the my.cnf). It seems a php-mysqlnd problem. Neither the mysql nor the mysqli extensions allows me to use "LOAD DATA LOCAL INFILE". This is the Connect-line in my code: $Connect = mysql_connect($DB_Host .":".$DB_Port,$DB_User,$DB_Password, FALSE, 128); The error is: #1148 - The used command is not allowed with this MySQL version Mysql-server: 5.5.16 PHP: 5.3.8 PHP-MYSQL-client: mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ PHPINFO: mysql MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Directive Local Value Master Value mysql.allow_local_infileOn On mysql.allow_persistent Off Off mysql.connect_timeout 60 60 mysql.default_host no valueno value mysql.default_password no valueno value mysql.default_port no valueno value mysql.default_socketno valueno value mysql.default_user no valueno value mysql.max_links Unlimited Unlimited mysql.max_persistentUnlimited Unlimited mysql.trace_modeOff Off mysqli MysqlI Support enabled Client API library version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Active Persistent Links 0 Inactive Persistent Links 0 Active Links0 Directive Local Value Master Value mysqli.allow_local_infile On On mysqli.allow_persistent On On mysqli.default_host no valueno value mysqli.default_port 33063306 mysqli.default_pw no valueno value mysqli.default_socket no valueno value mysqli.default_user no valueno value mysqli.max_linksUnlimited Unlimited mysqli.max_persistent Unlimited Unlimited mysqli.reconnectOff Off mysqlnd mysqlnd enabled Version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Compression supported SSL supported Command buffer size 4096 Read buffer size32768 Read timeout31536000 Collecting statistics Yes Collecting memory statisticsNo Tracing n/a I hope, that somebody can help. Best regards Stefan Test script: --- $Connect = mysql_connect($DB_Host .":".$DB_Port,$DB_User,$DB_Password, FALSE, 128); $StrSQL = "LOAD DATA LOCAL INFILE '/tmp/test.txt' INTO TABLE testtable FIELDS TERMINATED BY '' LINES STARTING BY '' TERMINATED BY '' IGNORE 1 LINES ."; $Result1 = mysql_db_query($DB,$StrSQL,$Connect); -- Edit this bug report at https://bugs.php.net/bug.php?id=55737&edit=1
Bug #39130 [Com]: Compile failure when using VC++ 2005
Edit report at https://bugs.php.net/bug.php?id=39130&edit=1 ID: 39130 Comment by: josephmdaly at gmail dot com Reported by:ben dot yan at msn dot com Summary:Compile failure when using VC++ 2005 Status: Wont fix Type: Bug Package:Compile Failure Operating System: Windows PHP Version:5.2CVS-2007-07-22 Assigned To:pajoye Block user comment: N Private report: N New Comment: I just came across this myself with 5.3.8. If you are an extension writer with this issue, try moving php.h to the first include of your source files. Previous Comments: [2009-03-04 00:11:11] paj...@php.net We support VC6 only for 5.2.x, it may work with VS2008 (vc9) but there is no guarantee. PHP 5.3 supports 2008 out of the box. [2009-03-03 23:58:11] jmckenna at gatewaygeomatics dot com I have the exact same problem with PHP 5.2.9 and VS 2008. -jeff [2008-05-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-05-12 09:54:03] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-02-12 03:54:48] someone at farpost dot com Fixed this error adding symbol _USE_32BIT_TIME_T to all projects in the Preprocessor Definitions. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=39130 -- Edit this bug report at https://bugs.php.net/bug.php?id=39130&edit=1
Bug #60076 [Opn->Fbk]: mb_substr reaches max execution time even on 200 character text
Edit report at https://bugs.php.net/bug.php?id=60076&edit=1 ID: 60076 Updated by: cataphr...@php.net Reported by:boris at east dot fi Summary:mb_substr reaches max execution time even on 200 character text -Status: Open +Status: Feedback Type: Bug Package:mbstring related Operating System: linux/ubuntu 10.04 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I can't reproduce this. I'd say the error is somewhere else. Can you reproduce this from the command line? If possible, can you profile PHP (or at least attach a debugger and show the stack trace)? Previous Comments: [2011-10-17 12:15:04] boris at east dot fi Description: mb_substr reaches max execution time of 30s even when it should subtract small amount of characters. In our case blog posts content (around 200 characters) was not been substracted to 140 with mb_substr. Workaround which does not bypass the max execution time is to use the following instead: utf8_encode(substr(utf8_decode($str),$start,$length)) which looks ugly but at least works :) Test script: --- $utf8Text = "Terveisiä Pohjanmaalta! Anoppilaan kävi matka näin syyslomaviikon edellä ja ajattelin tehdä pienen tilannekatsauksen kesärenkaiden suhteen. Kilometrit 15.10.2011 Hakka Bluet ovat rullanneet auton alla noin 1200 kilometriä, eivätkä renkaat ole aiheuttaneet hämmennystä. Sekä allekirjoittanut että muut autoa käyttäneet ovat tyytyväisiä. Koska ajo on ollut lähinnä työmatka-ajoa sekä rauhallista maantieajoa, ei mitään suuria ajo-ominaisuuskoitoksia ole matkan varrelle sattunut. Lähinnä tällä viikolla pari pakkasaamua ovat aiheuttaneet kiinnostusta pidon suhteen, mutta mustaa jäätäkään ei ole löytynyt sen vertaa, että ajonvakautus olisi edes herännyt. Kaikki siis hyvin, mennään hiljaa ja matalalla."; $short = mb_substr($utf8Text, 0, 140, "UTF-8"); Expected result: subtracted result. ie $short == "Terveisiä Pohjanmaalta! Anoppilaan kävi matka näin syyslomaviikon edellä ja ajattelin tehdä pienen tilannekatsauksen kesärenkaiden suhteen. Kilometrit" Actual result: -- max execution time of 30s reached error -- Edit this bug report at https://bugs.php.net/bug.php?id=60076&edit=1
Bug #60086 [Opn->Bgs]: leading zeros used in array gives problems
Edit report at https://bugs.php.net/bug.php?id=60086&edit=1 ID: 60086 Updated by: cataphr...@php.net Reported by:bartdeliefde at gmail dot com Summary:leading zeros used in array gives problems -Status: Open +Status: Bogus Type: Bug Package:Arrays related PHP Version:5.3.8 Block user comment: N Private report: N 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. Leading zeros are for octal notation. Previous Comments: [2011-10-18 13:45:58] bartdeliefde at gmail dot com Description: leading zeros used in arrays gives problems . Test script: --- Expected result: echo $array_alphabet[09]; expected to give me 'j' Actual result: -- but is gives me 'a' -- Edit this bug report at https://bugs.php.net/bug.php?id=60086&edit=1
Bug #48507 [Com]: fgetcsv() ignoring special characters
Edit report at https://bugs.php.net/bug.php?id=48507&edit=1
ID: 48507
Comment by: me at monicag dot it
Reported by:krynble at yahoo dot com dot br
Summary:fgetcsv() ignoring special characters
Status: Bogus
Type: Bug
Package:Filesystem function related
Operating System: Unix
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
Quoting my fellows above: how comes this is not a bug?
Previous Comments:
[2011-10-10 10:03:58] ghosh at q-one dot com
Sorry. I don't understand why this isn't a bug either. Could someone please
elaborate? I tried setting all different kinds of locale to no avail. The first
letter of a string starting with a UTF-8 character is always missing. IMHO,
fgetcsv should work as a simple string operation (or - whatever weird things it
does right now - at least have a parameter to do so - count this as a feature
request if you wish). I think, the current behavior is totally confusing. For
instance, I don't understand why only the first character is missing but the
problem doesnt appear if a character is in the middle of a string.
[2011-07-17 16:19:28] max dot wildgrube at web dot de
The problem does also appears if the special char is preceded by a blank. This
blank also disappears.
I use this ugly workaround:
1. first reading the complete csv file into a variable: $import
2. $import = preg_replace ("{(^|\t)([â¬-ÿ ])}m", "$1~~$2", $import);
3. after fgetcsv; for each $field of the row array: $field = str_replace ('~~',
'', $field);
This means: before using fgetcsv inserting a magic sequence (e.g. ~~) on the
beginning of a field which begins with a blank or a special char; after parsing
with fgetcsv removing it from each field.
Max.
[2011-07-08 08:39:50] php-bug-48507 at bsrealm dot net
This IS a bug. Whatever locale is, I expect this function to read everything
between delimiter characters without stripping the contents. Besides, docs say
that files in one-byte encoding would read wrong, and there is a different
case. This bug causes serious portability issue. In my case, this function was
used to read custom database that was storing descriptions entered by users.
Some descriptions were in utf-8 enconding. Function just had to read whatever
was between delimiter characters and it worked like that on Windows hosting and
stopped working after moving to Unix hosting. Note, file itself is not utf-8
encoded and it should not be. It is not related to locale. It must read data,
even if it's binary, between delimiters.
[2011-02-26 02:46:32] gjorgjioski at gmail dot com
This is short example:
kategorija Å¡irina platiÅ¡Ä Å¡tevilo
read:
kategorija
irina platiÅ¡Ä
tevilo
expected:
kategorija
Å¡irina platiÅ¡Ä
Å¡tevilo
[2011-02-26 02:36:32] gjorgjioski at gmail dot com
This bug occurs also when file is in UTF8 (tab delimited file using Å¡,Ä
characters). I can provide an example.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=48507
--
Edit this bug report at https://bugs.php.net/bug.php?id=48507&edit=1
[PHP-BUG] Bug #60086 [NEW]: leading zeros used in array gives problems
From: Operating system: PHP version: 5.3.8 Package: Arrays related Bug Type: Bug Bug description:leading zeros used in array gives problems Description: leading zeros used in arrays gives problems . Test script: --- Expected result: echo $array_alphabet[09]; expected to give me 'j' Actual result: -- but is gives me 'a' -- Edit bug report at https://bugs.php.net/bug.php?id=60086&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60086&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60086&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60086&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60086&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60086&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60086&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60086&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60086&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60086&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60086&r=support Expected behavior: https://bugs.php.net/fix.php?id=60086&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60086&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60086&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60086&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60086&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60086&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60086&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60086&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60086&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60086&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60086&r=mysqlcfg
Bug #60078 [Opn]: SIGSEGV in xhprof.c
Edit report at https://bugs.php.net/bug.php?id=60078&edit=1
ID: 60078
User updated by:odou...@php.net
Reported by:odou...@php.net
Summary:SIGSEGV in xhprof.c
Status: Open
Type: Bug
Package:xhprof
Operating System: -
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
More debugging :
it seems bug is happening in get_cpu_frequency() that returned 0 on line 1335
so
array hp_globals.cpu_frequencies is
wiped out by function clear_frequencies();
Just before, we have an error ("setaffinity: Invalid argument") thrown by line
1228, so my guess is that function
bind_to_cpu() failed, and at the end program is segfaulting because this has an
impact on an array.
Previous Comments:
[2011-10-17 16:51:21] odou...@php.net
Description:
I'll try to be as precise as possible :
This happens in a special case that can be reproduced 100%, but I cannot
provide
a test
script (it is using 20MB of closed customer code).
This happens only whith xhprof_enable(). No problem is encountered when the
module is just
loaded with no call to xhprof_enable()
In latest clone from git (commit a6bae51236 for file xhprof.c)
Program received signal SIGSEGV, Segmentation fault.
0x73575f49 in hp_mode_shared_endfn_cb (top=0xef0210, symbol=)
at /usr/src/xhprof/extension/xhprof.c:1553
bt
#0 hp_mode_shared_endfn_cb (top=0xef0210, symbol=) at
/usr/src/xhprof/extension/xhprof.c:1553
#1 0x7357609e in hp_mode_hier_endfn_cb (entries=)
at
/usr/src/xhprof/extension/xhprof.c:1573
#2 0x73576e66 in hp_compile_file (file_handle=,
type=8) at
/usr/src/xhprof/extension/xhprof.c:1721
#3 0x007218a4 in ?? ()
#4 0x0071f294 in execute ()
#5 0x006faf7b in zend_execute_scripts ()
#6 0x006b573a in php_execute_script ()
#7 0x00772287 in main ()
Ok so problem is in the function "hp_mode_shared_endfn_cb"
Let's try to see what is the value of each variable here :
print /f hp_globals.cpu_frequencies[hp_globals.cur_cpu_id]
Cannot access memory at address 0x0
ok so problem is in this expression.
print hp_globals.cpu_frequencies
$8 = (double *) 0x0
(gdb) print /f hp_globals.cur_cpu_id
$9 = 0
Ok so I can see that hp_globals.cpu_frequencies equals NULL (right ?), and we
attempt to
access it as an array.
I read the source code quickly, and I can see that this array should be filled
at some
point. Seems it is not.
I made a dirty patch just to avoid the SIGSEGV, but all my timings in xhprof
reports are
inaccurate now.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60078&edit=1
Bug #55796 [Opn->Bgs]: directive mysql.connect_charset missing
Edit report at https://bugs.php.net/bug.php?id=55796&edit=1 ID: 55796 Updated by: and...@php.net Reported by:b dot cropp at srz dot de Summary:directive mysql.connect_charset missing -Status: Open +Status: Bogus Type: Bug Package:MySQL related Operating System: gentoo linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: After some googling : "In setting up this new server I discover to my surprise that the *.connect_charset directives are a Gentoo specific patch to PHP, and RHEL's version of PHP doesn't recognize them! Now how do I set PHP to connect to MySQL with the latin1 charset?" http://serverfault.com/questions/97759/set-default-mysql-connect-charset-for-php-in-rhel Previous Comments: [2011-10-12 10:21:46] git dot user at gmail dot com seems like duplicate of https://bugs.php.net/bug.php?id=33604 [2011-09-27 09:59:19] b dot cropp at srz dot de Description: After updating from PHP-5.3.6 to 5.3.8 directive mysql.connect_charset seems to be missing. Is this a bug or wanted? If it's wanted, how should I now handle the db communication? Please give me a reference for this new behaviour. -- Edit this bug report at https://bugs.php.net/bug.php?id=55796&edit=1
Req #44118 [Wfx]: [PATCH] MySQL: Set connection charset via php.ini option
Edit report at https://bugs.php.net/bug.php?id=44118&edit=1
ID: 44118
Updated by: and...@php.net
Reported by:slava_reg at nsys dot by
Summary:[PATCH] MySQL: Set connection charset via php.ini
option
Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: any
PHP Version:5.2.5
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
mysqli has this. You can create a connection with mysqli_init() or just new
mysql() and then call mysqli_options() or $link->options and set the charset to
be used. It will be negotiated during the client-server handshake and there
will be no additional query like SET NAMES. mysqli_options() works before
connections is established, later it has no effect.
Previous Comments:
[2011-02-24 14:15:45] cavo at ynet dot sk
This is not about making application utf8 compatible. You can do this by "set
names" query. But it may be redundant. For example: All my database is in utf8
encoding. All my pages have content-type utf8. All form posts from clients are
in utf8. All strings I process in application are utf8. But what do I need to
do right after I connect to database? - "set names utf8;" Why? Because if I
don't, db will re-encode all strings to latin1. And PHP don't care. If I have
100 new connections to db per second, I need to 100 times run that query. Why
if client and server could negotiate encoding in those 2 obliged packets? (
http://bugs.php.net/bug.php?id=54086 ). It's ok to set latin1 as default
character set used by client to not affect existing applications (I believe
mostly for those, who actualy don't know, what are they doing..). But I think
it's very useful to have option to set encoding manualy via configuration
option or in connect functions like: mysql_connect('localhost', 'user', 'pwd',
true, MYSQL_CLIENT_ENCODING_UTF8);
Or am I somwhere wrong?
http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol#Client_Authentication_Packet
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_default-character-set
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_character-set-client-handshake
http://bugs.php.net/bug.php?id=54086
[2011-01-31 11:52:36] johan...@php.net
The application has to know the encoding being used, else some strange things
might happen. We have seen the trouble in having this globally configurable
when Gentoo decided to use Utf-8 for their MySQL installations by default
instead of MySQL's default. I doubt you can make an application Utf-8
comaptible by just setting such a low-level switch (it won't affect the HTTP
Content-type header or HTML forms, thus receiving data in a wrong encoding from
the user, not re-encode it etc.)
[2011-01-06 16:19:52] u...@php.net
Not sure if this is really needed. It can be done in user land. Its a bit of a
convenience feature. Not many votes for it... Andrey, Johannes...?
[2008-02-14 13:00:54] slava_reg at nsys dot by
Description:
Hi,
As I'm tired of patching various user-installed php-engines to work correctly
with newer MySQL versions (4.1.x +) that require connection character set to be
specified, I decided to solve the problem at the php level.
So, I patched both mysql and mysqli extensions (based on an idea found
somewhere in internet).
Result is available at:
http://bubble.nsys.by/projects/patches/php/php-5.2.5-mysql-client-charset.patch
The patch introduces two more php.ini directives:
mysql.client_charset and
mysqli.client_charset
As those directives are optional, the patch shouldn't break any existing
functionality, but it could *really* help users who's native language is not
latin and who want to use some php-scripted engine with mysql 'out-of-the-box'.
Best,
Vladislav Bogdanov
--
Edit this bug report at https://bugs.php.net/bug.php?id=44118&edit=1
php-bugs@lists.php.net
Edit report at https://bugs.php.net/bug.php?id=60082&edit=1 ID: 60082 Patch added by: larue...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject(&$ref). Status: Open Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60082.phpt Revision: 1318942263 URL: https://bugs.php.net/patch-display.php?bug=60082&patch=bug60082.phpt&revision=1318942263 Previous Comments: [2011-10-18 12:46:20] larue...@php.net The following patch has been added/updated: Patch Name: bug60082.patch Revision: 1318941980 URL: https://bugs.php.net/patch-display.php?bug=60082&patch=bug60082.patch&revision=1318941980 [2011-10-18 09:38:44] larue...@php.net $test = new ArrayObject(&$test) will make the intern->array a object; thus, there will be a infinite loop between spl_array_get_properties and spl_array_get_hash_table(call to HASH_OF which will call to spl_array_get_properties). then PHP will segfault due to stack overflow... I have tried to use SEPARATE_ARG_IF_REF to fix this segfault, but there is a test faild (ext/spl/tests/array_004.phpt) thanks [2011-10-17 22:30:44] tklingenberg at lastflood dot net Description: 100% CPU / when using references with ArrayObject(&$ref). Passing a copy works. Test script: --- $test = array(); $test = new ArrayObject(&$test); $test['a'] = $test['b']; or: $GLOBALS = new ArrayObject(&$GLOBALS); $a = $GLOBALS['b']; Expected result: Set $test['a'] or $a to NULL with an undefined offset/index warning. Actual result: -- Endless Loop / CPU goes up 100% and stays. -- Edit this bug report at https://bugs.php.net/bug.php?id=60082&edit=1
php-bugs@lists.php.net
Edit report at https://bugs.php.net/bug.php?id=60082&edit=1 ID: 60082 Patch added by: larue...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject(&$ref). Status: Open Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60082.patch Revision: 1318941980 URL: https://bugs.php.net/patch-display.php?bug=60082&patch=bug60082.patch&revision=1318941980 Previous Comments: [2011-10-18 09:38:44] larue...@php.net $test = new ArrayObject(&$test) will make the intern->array a object; thus, there will be a infinite loop between spl_array_get_properties and spl_array_get_hash_table(call to HASH_OF which will call to spl_array_get_properties). then PHP will segfault due to stack overflow... I have tried to use SEPARATE_ARG_IF_REF to fix this segfault, but there is a test faild (ext/spl/tests/array_004.phpt) thanks [2011-10-17 22:30:44] tklingenberg at lastflood dot net Description: 100% CPU / when using references with ArrayObject(&$ref). Passing a copy works. Test script: --- $test = array(); $test = new ArrayObject(&$test); $test['a'] = $test['b']; or: $GLOBALS = new ArrayObject(&$GLOBALS); $a = $GLOBALS['b']; Expected result: Set $test['a'] or $a to NULL with an undefined offset/index warning. Actual result: -- Endless Loop / CPU goes up 100% and stays. -- Edit this bug report at https://bugs.php.net/bug.php?id=60082&edit=1
Bug #59743 [Opn->Fbk]: doesn't install neither on os x or linux
Edit report at https://bugs.php.net/bug.php?id=59743&edit=1 ID: 59743 Updated by: u...@php.net Reported by:sathia dot musso at gmail dot com Summary:doesn't install neither on os x or linux -Status: Open +Status: Feedback Type: Bug Package:mysqlnd_ms Operating System: Os x / linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Please, describe how you installed PHP: - what is your PHPs' configure line? - have you enabled mysqlnd? - have you installed PHP after the build? - which version of PHP are you using (several people reporting, thus double-checking)? This all smells like an incomplete installation. Thanks, Ulf Previous Comments: [2011-09-30 12:46:38] sathia dot musso at gmail dot com trying to install this extension on my dev server, but it fails consistently both via pecl and via manual installation. /usr/src/mysqlnd_ms- 1.1.0/ext/mysqlnd/mysqlnd_portability.h:40:46: fatal error: ext/mysqlnd/php_mysqlnd_config.h: No such file or directory this is the error, i tried to symlink the ext dir from the sources of my php version (5.3.8.1) but still it won't work. I was eager to try the lazy connections. any help on this? [2011-05-04 09:32:32] johannes at schlueters dot de Are you sure your PHP installation is using mysqlnd? (Check output of `php -m` or such which should list mysqlnd) [2011-05-02 14:29:06] sathia dot musso at gmail dot com it does work if you: root@host:/tmp/pear/temp/mysqlnd_ms# cp -a /usr/src/php- 5.3.6/ext/ . [2011-05-02 14:23:45] sathia dot musso at gmail dot com Description: Hi, I've tried a lot of combinations over different OS's but the error is always the same: /pecl install channel://pecl.php.net/mysqlnd_ms-1.0.1 [...] /tmp/pear/temp/mysqlnd_ms/php_mysqlnd_ms.c:28:33: fatal error: ext/mysqlnd/mysqlnd.h: No such file or directory compilation terminated. i was eager to try this extension, any idea how to fix it? thanks -- Edit this bug report at https://bugs.php.net/bug.php?id=59743&edit=1
Bug #60083 [Opn->Csd]: NumberFormatter::formatCurrency wrong for CHF (Swiss Francs)
Edit report at https://bugs.php.net/bug.php?id=60083&edit=1
ID: 60083
User updated by:gman at xrbr dot com
Reported by:gman at xrbr dot com
Summary:NumberFormatter::formatCurrency wrong for CHF (Swiss
Francs)
-Status: Open
+Status: Closed
Type: Bug
Package:intl
Operating System: SuSE Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
They do not have "1 Rappen" coins! That is the reason.
Previous Comments:
[2011-10-18 10:26:53] gman at xrbr dot com
Description:
I am not from Switzerland, but as far as I know they do have "Rappen", and 1
CHF is equal to 100 Rappen.
So putting float 12.99 to NumberFormatter::formatCurrency should return the
said 12,99 ("," is the correct decimal separator for de_DE), but what it does
is to output 13,00 which is not correct!
Test script:
---
$varNumberFormatter1 = new NumberFormatter("de_DE", NumberFormatter::CURRENCY);
var_dump($varNumberFormatter1->formatCurrency(12.99, "CHF"));
$varNumberFormatter2 = new NumberFormatter("de_DE", NumberFormatter::CURRENCY);
var_dump($varNumberFormatter2->formatCurrency(12.99, "EUR"));
Expected result:
string(10) "12,99 CHF"
string(10) "12,99 â¬"
Actual result:
--
string(10) "13,00 CHF"
string(10) "12,99 â¬"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60083&edit=1
[PHP-BUG] Bug #60083 [NEW]: NumberFormatter::formatCurrency wrong for CHF (Swiss Francs)
From:
Operating system: SuSE Linux
PHP version: 5.3.8
Package: intl
Bug Type: Bug
Bug description:NumberFormatter::formatCurrency wrong for CHF (Swiss Francs)
Description:
I am not from Switzerland, but as far as I know they do have "Rappen", and
1 CHF is equal to 100 Rappen.
So putting float 12.99 to NumberFormatter::formatCurrency should return the
said 12,99 ("," is the correct decimal separator for de_DE), but what it
does is to output 13,00 which is not correct!
Test script:
---
$varNumberFormatter1 = new NumberFormatter("de_DE",
NumberFormatter::CURRENCY);
var_dump($varNumberFormatter1->formatCurrency(12.99, "CHF"));
$varNumberFormatter2 = new NumberFormatter("de_DE",
NumberFormatter::CURRENCY);
var_dump($varNumberFormatter2->formatCurrency(12.99, "EUR"));
Expected result:
string(10) "12,99 CHF"
string(10) "12,99 â¬"
Actual result:
--
string(10) "13,00 CHF"
string(10) "12,99 â¬"
--
Edit bug report at https://bugs.php.net/bug.php?id=60083&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60083&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60083&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60083&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60083&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60083&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60083&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60083&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60083&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60083&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60083&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60083&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60083&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60083&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60083&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60083&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60083&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60083&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60083&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60083&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60083&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60083&r=mysqlcfg
php-bugs@lists.php.net
Edit report at https://bugs.php.net/bug.php?id=60082&edit=1 ID: 60082 Updated by: larue...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject(&$ref). Status: Open Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: $test = new ArrayObject(&$test) will make the intern->array a object; thus, there will be a infinite loop between spl_array_get_properties and spl_array_get_hash_table(call to HASH_OF which will call to spl_array_get_properties). then PHP will segfault due to stack overflow... I have tried to use SEPARATE_ARG_IF_REF to fix this segfault, but there is a test faild (ext/spl/tests/array_004.phpt) thanks Previous Comments: [2011-10-17 22:30:44] tklingenberg at lastflood dot net Description: 100% CPU / when using references with ArrayObject(&$ref). Passing a copy works. Test script: --- $test = array(); $test = new ArrayObject(&$test); $test['a'] = $test['b']; or: $GLOBALS = new ArrayObject(&$GLOBALS); $a = $GLOBALS['b']; Expected result: Set $test['a'] or $a to NULL with an undefined offset/index warning. Actual result: -- Endless Loop / CPU goes up 100% and stays. -- Edit this bug report at https://bugs.php.net/bug.php?id=60082&edit=1
