[PHP-BUG] Bug #60091 [NEW]: \Yaf\Bootstrap\Abstract
From: laruence Operating system: * PHP version: Irrelevant Package: yaf Bug Type: Bug Bug description:\Yaf\Bootstrap\Abstract Description: Yaf can use namespace as it's class names, but Abstract is a keyword, can not used for a class name Test script: --- none Expected result: none Actual result: -- none -- Edit bug report at https://bugs.php.net/bug.php?id=60091edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60091r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60091r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60091r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60091r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60091r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60091r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60091r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60091r=needscript Try newer version: https://bugs.php.net/fix.php?id=60091r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60091r=support Expected behavior: https://bugs.php.net/fix.php?id=60091r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60091r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60091r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60091r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60091r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60091r=dst IIS Stability: https://bugs.php.net/fix.php?id=60091r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60091r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60091r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60091r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60091r=mysqlcfg
Bug #60074 [Com]: Stack trace truncated for long paths
Edit report at https://bugs.php.net/bug.php?id=60074edit=1
ID: 60074
Comment by: tyr...@php.net
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?!
the problem is reproducible with a much shorter path, as Felipe pointed out the
log_errors_max_len defaults to 1024, so you can easily bump into this either
with
a moderately long path, or with a long error/stack trace.
I purposely used a very long path in my report to point out that it is possible
to
completely truncate the stack trace.
Previous Comments:
[2011-10-19 03:00:42] anon at anon dot anon
When would you ever need a thousand character path, honestly?!
[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
?php
function a(){
b();
}
function b(){
throw new Exception(Foo);
}
a();
Expected result:
it should contain the full stack trace
Actual result:
--
the stack trace gets truncated
--
Edit this bug report at https://bugs.php.net/bug.php?id=60074edit=1
Bug #60091 [Asn-Csd]: \Yaf\Bootstrap\Abstract
Edit report at https://bugs.php.net/bug.php?id=60091edit=1 ID: 60091 Updated by: larue...@php.net Reported by:larue...@php.net Summary:\Yaf\Bootstrap\Abstract -Status: Assigned +Status: Closed Type: Bug Package:yaf Operating System: * PHP Version:Irrelevant Assigned To:laruence 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-10-19 07:03:41] larue...@php.net Description: Yaf can use namespace as it's class names, but Abstract is a keyword, can not used for a class name Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=60091edit=1
Bug #55801 [Fbk]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801edit=1 ID: 55801 Updated by: m...@php.net Reported by:mapi at pdepend dot org Summary:Behavior of unserialize has changed Status: Feedback Type: Bug Package:Variables related Operating System: Linux (Fedora 15) PHP Version:5.4.0beta1 Assigned To:mike Block user comment: N Private report: N New Comment: So? Running your original test script seems to work fine with this patch... Previous Comments: [2011-10-13 16:21:18] m...@php.net The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318522878 URL: https://bugs.php.net/patch-display.php?bug=55801patch=fix-serialize-in-sleep-and-wakeuprevision=1318522878 [2011-10-13 14:39:40] m...@php.net Could you try attached patch, please? [2011-10-13 14:39:10] m...@php.net The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318516750 URL: https://bugs.php.net/patch-display.php?bug=55801patch=fix-serialize-in-sleep-and-wakeuprevision=1318516750 [2011-10-04 16:34:49] mapi at pdepend dot org To answer your question, I did't know my initial intention about the __temp__ property, but I remember that there was a reason. But it seems that this property is obsolete now. [2011-10-04 16:20:39] mapi at pdepend dot org Cool that you came up with a reproducable, I have tried it for a couple of hours and didn't get a working reproducable outside of PHP_Depend. But is it such an uncommon use case to serialize/unserialize additional data in an object's __sleep() or __wakeup() 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=55801 -- Edit this bug report at https://bugs.php.net/bug.php?id=55801edit=1
Bug #55801 [Com]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801edit=1 ID: 55801 Comment by: mapi at pdepend dot org Reported by:mapi at pdepend dot org Summary:Behavior of unserialize has changed Status: Feedback Type: Bug Package:Variables related Operating System: Linux (Fedora 15) PHP Version:5.4.0beta1 Assigned To:mike Block user comment: N Private report: N New Comment: Hello Mike, I just tested a patched version of branches/PHP_5_4/ and trunk/ with the original implementation that uses serialize() and unserialize() within __sleep()/__wakeup(). Everything works as expected and there are no NULL filled arrays anymore. Thank you very much for help Previous Comments: [2011-10-19 08:15:02] m...@php.net So? Running your original test script seems to work fine with this patch... [2011-10-13 16:21:18] m...@php.net The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318522878 URL: https://bugs.php.net/patch-display.php?bug=55801patch=fix-serialize-in-sleep-and-wakeuprevision=1318522878 [2011-10-13 14:39:40] m...@php.net Could you try attached patch, please? [2011-10-13 14:39:10] m...@php.net The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318516750 URL: https://bugs.php.net/patch-display.php?bug=55801patch=fix-serialize-in-sleep-and-wakeuprevision=1318516750 [2011-10-04 16:34:49] mapi at pdepend dot org To answer your question, I did't know my initial intention about the __temp__ property, but I remember that there was a reason. But it seems that this property is obsolete now. 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=55801 -- Edit this bug report at https://bugs.php.net/bug.php?id=55801edit=1
Bug #55801 [Fbk-Csd]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801edit=1 ID: 55801 Updated by: m...@php.net Reported by:mapi at pdepend dot org Summary:Behavior of unserialize has changed -Status: Feedback +Status: Closed Type: Bug Package:Variables related Operating System: Linux (Fedora 15) PHP Version:5.4.0beta1 Assigned To:mike 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-10-19 10:09:23] m...@php.net Automatic comment from SVN on behalf of mike Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318210 Log: Fix Bug #55801 Behavior of unserialize has changed: (un)serialize in __wakeup/__sleep now use clean var_hashes [2011-10-19 08:55:53] mapi at pdepend dot org Hello Mike, I just tested a patched version of branches/PHP_5_4/ and trunk/ with the original implementation that uses serialize() and unserialize() within __sleep()/__wakeup(). Everything works as expected and there are no NULL filled arrays anymore. Thank you very much for help [2011-10-19 08:15:02] m...@php.net So? Running your original test script seems to work fine with this patch... [2011-10-13 16:21:18] m...@php.net The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318522878 URL: https://bugs.php.net/patch-display.php?bug=55801patch=fix-serialize-in-sleep-and-wakeuprevision=1318522878 [2011-10-13 14:39:40] m...@php.net Could you try attached patch, please? 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=55801 -- Edit this bug report at https://bugs.php.net/bug.php?id=55801edit=1
Bug #55385 [Com]: mysqlnd doesn't connect using ssl
Edit report at https://bugs.php.net/bug.php?id=55385edit=1 ID: 55385 Comment by: dnsdns at gmail dot com Reported by:fuxa_kos at unihost dot cz Summary:mysqlnd doesn't connect using ssl Status: Feedback Type: Bug Package:MySQL related Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I know its not connecting with SSL, because I put a restriction on the user in MySQL. It connects fine if PHP is not compiled with mysqlnd. If it is compiled with that the sample code I provided only works if I drop the SSL restriction from MySQL (thats why I get access denied). Will try to get a packet dump, but it takes time. I have reproduced this behaviour on Gentoo (trying to connect to MySQL 5.1.59 on the same box but connecting with ip) and SLES11 (using MySQL client 5.0.67 connecting to another computer having 5.1) also. Previous Comments: [2011-10-18 18:56:14] and...@php.net 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? [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) 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=55385edit=1
[PHP-BUG] Bug #60092 [NEW]: inappropriate use of st_blksize and st_blocks
From: Operating system: HP NonStop PHP version: 5.3.8 Package: Compile Failure Bug Type: Bug Bug description:inappropriate use of st_blksize and st_blocks Description: using st_blksite and st_blocks outside of HAVE_ST_BLKSIZE resp. HABE_ST_BLOCKS in several files, uses !PHP_WIN32 resp. !__BEOS__ instead: ...ext/phar/function_interceptors.c ...ext/phar/stream.c ...ext/sqlite3/libsqlite/sqlite3.c ...main/streams/memory.c This of course fails on platforms other than WIN32 or BEOS that don't have these, like uin my cace, HP NonStop (#ifdef __TANDEM). -- Edit bug report at https://bugs.php.net/bug.php?id=60092edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60092r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60092r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60092r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60092r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60092r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60092r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60092r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60092r=needscript Try newer version: https://bugs.php.net/fix.php?id=60092r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60092r=support Expected behavior: https://bugs.php.net/fix.php?id=60092r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60092r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60092r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60092r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60092r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60092r=dst IIS Stability: https://bugs.php.net/fix.php?id=60092r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60092r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60092r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60092r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60092r=mysqlcfg
[PHP-BUG] Bug #60093 [NEW]: HP NonStop not detected by configure
From: Operating system: HP NonStop PHP version: 5.3.8 Package: Compile Failure Bug Type: Bug Bug description:HP NonStop not detected by configure Description: HP NonStop not detected by configure Newer configure versions have been fixed, so please get and use a newer one -- Edit bug report at https://bugs.php.net/bug.php?id=60093edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60093r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60093r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60093r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60093r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60093r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60093r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60093r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60093r=needscript Try newer version: https://bugs.php.net/fix.php?id=60093r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60093r=support Expected behavior: https://bugs.php.net/fix.php?id=60093r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60093r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60093r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60093r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60093r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60093r=dst IIS Stability: https://bugs.php.net/fix.php?id=60093r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60093r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60093r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60093r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60093r=mysqlcfg
[PHP-BUG] Bug #60094 [NEW]: C++ comment fails in c89
From: Operating system: HP NonStop PHP version: 5.3.8 Package: Compile Failure Bug Type: Bug Bug description:C++ comment fails in c89 Description: C++ comment fails in c89, the file .../ext/fileinfo/libmagic/cdf_time.c uses a C++ comment (//) in one place, in line 120. Simply change it to a C-style comment and al will be well ;-) -- Edit bug report at https://bugs.php.net/bug.php?id=60094edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60094r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60094r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60094r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60094r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60094r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60094r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60094r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60094r=needscript Try newer version: https://bugs.php.net/fix.php?id=60094r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60094r=support Expected behavior: https://bugs.php.net/fix.php?id=60094r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60094r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60094r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60094r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60094r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60094r=dst IIS Stability: https://bugs.php.net/fix.php?id=60094r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60094r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60094r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60094r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60094r=mysqlcfg
Bug #55385 [Fbk-Opn]: mysqlnd doesn't connect using ssl
Edit report at https://bugs.php.net/bug.php?id=55385edit=1 ID: 55385 User updated by:fuxa_kos at unihost dot cz Reported by:fuxa_kos at unihost dot cz Summary:mysqlnd doesn't connect using ssl -Status: Feedback +Status: Open Type: Bug Package:MySQL related Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: In my case it is connect via TCP (to other box), not thru socket. Previous Comments: [2011-10-19 12:09:08] dnsdns at gmail dot com I know its not connecting with SSL, because I put a restriction on the user in MySQL. It connects fine if PHP is not compiled with mysqlnd. If it is compiled with that the sample code I provided only works if I drop the SSL restriction from MySQL (thats why I get access denied). Will try to get a packet dump, but it takes time. I have reproduced this behaviour on Gentoo (trying to connect to MySQL 5.1.59 on the same box but connecting with ip) and SLES11 (using MySQL client 5.0.67 connecting to another computer having 5.1) also. [2011-10-18 18:56:14] and...@php.net 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? [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. 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=55385edit=1
Bug #55385 [Opn-Fbk]: mysqlnd doesn't connect using ssl
Edit report at https://bugs.php.net/bug.php?id=55385edit=1 ID: 55385 Updated by: paj...@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: What Andrey is asking is a wireshark dump of the network traffic between php and mysql while your script is trying to connect. Previous Comments: [2011-10-19 13:30:49] fuxa_kos at unihost dot cz In my case it is connect via TCP (to other box), not thru socket. [2011-10-19 12:09:08] dnsdns at gmail dot com I know its not connecting with SSL, because I put a restriction on the user in MySQL. It connects fine if PHP is not compiled with mysqlnd. If it is compiled with that the sample code I provided only works if I drop the SSL restriction from MySQL (thats why I get access denied). Will try to get a packet dump, but it takes time. I have reproduced this behaviour on Gentoo (trying to connect to MySQL 5.1.59 on the same box but connecting with ip) and SLES11 (using MySQL client 5.0.67 connecting to another computer having 5.1) also. [2011-10-18 18:56:14] and...@php.net 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? [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' )); 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=55385edit=1
Bug #55385 [Fbk]: mysqlnd doesn't connect using ssl
Edit report at https://bugs.php.net/bug.php?id=55385edit=1 ID: 55385 Updated by: paj...@php.net Reported by:fuxa_kos at unihost dot cz Summary:mysqlnd doesn't connect using ssl Status: Feedback Type: Bug Package:MySQL related Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: @fuxa_kos at unihost dot cz Socket does not support SSL. Previous Comments: [2011-10-19 13:49:26] paj...@php.net What Andrey is asking is a wireshark dump of the network traffic between php and mysql while your script is trying to connect. [2011-10-19 13:30:49] fuxa_kos at unihost dot cz In my case it is connect via TCP (to other box), not thru socket. [2011-10-19 12:09:08] dnsdns at gmail dot com I know its not connecting with SSL, because I put a restriction on the user in MySQL. It connects fine if PHP is not compiled with mysqlnd. If it is compiled with that the sample code I provided only works if I drop the SSL restriction from MySQL (thats why I get access denied). Will try to get a packet dump, but it takes time. I have reproduced this behaviour on Gentoo (trying to connect to MySQL 5.1.59 on the same box but connecting with ip) and SLES11 (using MySQL client 5.0.67 connecting to another computer having 5.1) also. [2011-10-18 18:56:14] and...@php.net 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? [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. 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=55385edit=1
Bug #59851 [Opn-Fbk]: HTTP Requests will intermittently timeout
Edit report at https://bugs.php.net/bug.php?id=59851edit=1
ID: 59851
Updated by: m...@php.net
Reported by:dh at cross-solutions dot se
Summary:HTTP Requests will intermittently timeout
-Status: Open
+Status: Feedback
Type: Bug
Package:pecl_http
Operating System: Arch Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2011-07-16 11:38:35] dh at cross-solutions dot se
The exact exception is:
exception 'HttpInvalidParamException' with message 'Empty or too short HTTP
message: ''' in /srv/http/food/request_preapprove_key.php:0 inner exception
'HttpRequestException' with message 'Timeout was reached; Connection time-out
(https://svcs.sandbox.paypal.com/AdaptivePayments/Preapproval)' in
/srv/http/food/request_preapprove_key.php:81 Stack trace: #0
/srv/http/food/request_preapprove_key.php(0): HttpRequest-send() #1 {main}
[2011-07-16 11:15:24] dh at cross-solutions dot se
Description:
I create a HttpRequest object for an SSL site (paypal) with METH_POST method.
Every hour or so I have to restart the apache server because all I get is SSL
request reached timeout in my $message-send(). The length of the timeout does
not matter (I've increased it to minutes with setOptions(), it just takes
longer but it still times out).
The funny thing is that while the request times out from PHP, I can make the
exact same one with curl in a shell just fine, which suggests there is a
problem with the php module.
Reproduce code:
---
$message = new HttpRequest(
https://svcs.sandbox.paypal.com/AdaptivePayments/Preapproval;,
HttpRequest::METH_POST );
$message-addHeaders(
array(
X-PAYPAL-SECURITY-USERID = replace_with_userid, // I
have removed our company's user ID here
X-PAYPAL-SECURITY-PASSWORD = replace with password, //
And password
X-PAYPAL-SECURITY-SIGNATURE = replace with signature, // And
signature
X-PAYPAL-REQUEST-DATA-FORMAT = NV,
X-PAYPAL-RESPONSE-DATA-FORMAT = NV,
X-PAYPAL-APPLICATION-ID = replace with app ID ) );
$message-setPostFields( bogus );
try
{
$response = $message-send();
if ( $response-getResponseCode() == 200 )
{
echo Woohoo!;
}
}
catch ( HttpException $exception )
{
echo $exception\n;
}
Expected result:
I get a response back from the server every time I make the request.
Actual result:
--
After a number of successful requests, I only get timeouts until I restart the
apache server.
--
Edit this bug report at https://bugs.php.net/bug.php?id=59851edit=1
Bug #60094 [Asn-Csd]: C++ comment fails in c89
Edit report at https://bugs.php.net/bug.php?id=60094edit=1 ID: 60094 Updated by: larue...@php.net Reported by:jojo at hp dot com Summary:C++ comment fails in c89 -Status: Assigned +Status: Closed Type: Bug Package:Compile Failure Operating System: HP NonStop PHP Version:5.3.8 Assigned To:laruence 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-10-19 15:08:49] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318222 Log: Fixed bug #60094 (C++ comment fails in c89) [2011-10-19 13:18:34] jojo at hp dot com Description: C++ comment fails in c89, the file .../ext/fileinfo/libmagic/cdf_time.c uses a C++ comment (//) in one place, in line 120. Simply change it to a C-style comment and al will be well ;-) -- Edit this bug report at https://bugs.php.net/bug.php?id=60094edit=1
[PHP-BUG] Bug #60096 [NEW]: token_get_all on b$var returns invalid string token
From: nikic
Operating system:
PHP version: 5.4.0beta1
Package: *General Issues
Bug Type: Bug
Bug description:token_get_all on b$var returns invalid string token
Description:
token_get_all('?php b$var') will return 'b' as a string-token, even
though it is not a single character.
--
Edit bug report at https://bugs.php.net/bug.php?id=60096edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60096r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60096r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60096r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60096r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60096r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60096r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60096r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60096r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60096r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60096r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60096r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60096r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60096r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60096r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60096r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60096r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60096r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60096r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60096r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60096r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60096r=mysqlcfg
[PHP-BUG] Bug #60097 [NEW]: token_get_all fails to lex nested heredoc
From: nikic
Operating system:
PHP version: 5.4.0beta1
Package: *General Issues
Bug Type: Bug
Bug description:token_get_all fails to lex nested heredoc
Description:
token_get_all('?php
DOC
{$s(ppp
ppp
)}
DOC;
');
Doesn't recognize DOC; as the heredoc end.
Looks like some of the heredoc LEXING code was put in the PARSER.
--
Edit bug report at https://bugs.php.net/bug.php?id=60097edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60097r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60097r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60097r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60097r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60097r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60097r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60097r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60097r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60097r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60097r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60097r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60097r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60097r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60097r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60097r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60097r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60097r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60097r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60097r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60097r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60097r=mysqlcfg
Bug #55712 [Asn-Fbk]: FastCGI causes event 1000 application error when using number_format(0)
Edit report at https://bugs.php.net/bug.php?id=55712edit=1 ID: 55712 Updated by: paj...@php.net Reported by:ken at simplecommerce dot com Summary:FastCGI causes event 1000 application error when using number_format(0) -Status: Assigned +Status: Feedback 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: hi, We cannot reproduce this crash in any way. Using round(0) or number_format, using 0 or any other kind of random values. Please provide a self contained script (aka no DB usage, but only using number_format and round) to reproduce this crash. Previous Comments: [2011-10-18 21:42:55] ken at simplecommerce dot com Any update on this issue? [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 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=55712edit=1
Bug #55712 [Fbk-Asn]: FastCGI causes event 1000 application error when using number_format(0)
Edit report at https://bugs.php.net/bug.php?id=55712edit=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: Feedback +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: Hi, Did you guys take a look at the diagnostic report I had included to see if any of the information was relevant enough for you guys to discern where the problem was? Also, as I had mentioned before, the error arises more often when I use number_format or round 0 in a script that makes calls to an ODBC link to a accounting database called Acomba. But the error also arises when using number_format or round 0 in a script alone with nothing else. But the problem does not error as frequently as the other scenario with the database link. Did you guys try to reproduce the error using the same environment? I also tried with a windows 7 workstation with IIS 7/FastCGI and that ODBC link and was having the issue also. Previous Comments: [2011-10-19 17:12:45] paj...@php.net hi, We cannot reproduce this crash in any way. Using round(0) or number_format, using 0 or any other kind of random values. Please provide a self contained script (aka no DB usage, but only using number_format and round) to reproduce this crash. [2011-10-18 21:42:55] ken at simplecommerce dot com Any update on this issue? [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. 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=55712edit=1
Bug #60078 [Opn]: SIGSEGV in xhprof.c
Edit report at https://bugs.php.net/bug.php?id=60078edit=1 ID: 60078 Updated by: scott...@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: Any more information about the OS or version of PHP? I have this working fine on OS X with PHP 5.3 and PHP 5.4. Previous Comments: [2011-10-18 13:22:27] odou...@php.net 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. [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=value optimized out) at /usr/src/xhprof/extension/xhprof.c:1553 bt #0 hp_mode_shared_endfn_cb (top=0xef0210, symbol=value optimized out) at /usr/src/xhprof/extension/xhprof.c:1553 #1 0x7357609e in hp_mode_hier_endfn_cb (entries=value optimized out) at /usr/src/xhprof/extension/xhprof.c:1573 #2 0x73576e66 in hp_compile_file (file_handle=value optimized out, 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=60078edit=1
Bug #60078 [Opn]: SIGSEGV in xhprof.c
Edit report at https://bugs.php.net/bug.php?id=60078edit=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: System is Linux 64 x64 (kernel 2.6.36) Bi CPU Intel(R) Xeon(R) CPU L5630 @ 2.13GHz I found this bug on a particular machine where some CPUs are deactivated on purpose (sorry, this is a major information but I only detected it now). Command used to deactivate a thread: echo 0 /sys/devices/system/cpu/cpu1/online function bind_to_cpu failed for cpu 1, and now I can see why. Do you have any idea how to handle this on xhprof ? Maybe not resetting the whole hp_globals.cpu_frequencies array if bind_ failed ? Previous Comments: [2011-10-19 17:39:26] scott...@php.net Any more information about the OS or version of PHP? I have this working fine on OS X with PHP 5.3 and PHP 5.4. [2011-10-18 13:22:27] odou...@php.net 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. [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=value optimized out) at /usr/src/xhprof/extension/xhprof.c:1553 bt #0 hp_mode_shared_endfn_cb (top=0xef0210, symbol=value optimized out) at /usr/src/xhprof/extension/xhprof.c:1553 #1 0x7357609e in hp_mode_hier_endfn_cb (entries=value optimized out) at /usr/src/xhprof/extension/xhprof.c:1573 #2 0x73576e66 in hp_compile_file (file_handle=value optimized out, 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=60078edit=1
[PHP-BUG] Req #60098 [NEW]: Static constructors, or static intializers
From: Operating system: All PHP version: 5.4.0beta1 Package: SPL related Bug Type: Feature/Change Request Bug description:Static constructors, or static intializers Description: I've noticed a fairly large trend in a lot of php frameworks, as well as in my own code, and I was curious about whether this is planned, the reasons as to why it might not be, or if it has even been brought up. I've tried to find any other requests about this, but haven't been very successful. Basically, my request is this: When a class comes into existence (whether the code is in the file you're currently in, or you're including it), a static constructor (a common method for it is ::init) is called. This is called only once, the first time the class exists, and would act as a protected method (allowing parent-child objects to call it incase of a class reset?). This would be pretty awesome, but I don't know if it's practical, or what all your thoughts might have been as I'm sure plenty of you have seen it floating around. Thanks a bunch for taking the time to read my request, I'm excited to hear what you think :) -- Edit bug report at https://bugs.php.net/bug.php?id=60098edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60098r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60098r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60098r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60098r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60098r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60098r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60098r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60098r=needscript Try newer version: https://bugs.php.net/fix.php?id=60098r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60098r=support Expected behavior: https://bugs.php.net/fix.php?id=60098r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60098r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60098r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60098r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60098r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60098r=dst IIS Stability: https://bugs.php.net/fix.php?id=60098r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60098r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60098r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60098r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60098r=mysqlcfg
[PHP-BUG] Bug #60099 [NEW]: __halt_compiler() works in braced namespaces
From: nikic
Operating system:
PHP version: 5.4.0beta1
Package: Scripting Engine problem
Bug Type: Bug
Bug description:__halt_compiler() works in braced namespaces
Description:
?php
namespace A {
__halt_compiler();
The above code will work, but I assume that it should not.
--
Edit bug report at https://bugs.php.net/bug.php?id=60099edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60099r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60099r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60099r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60099r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60099r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60099r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60099r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60099r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60099r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60099r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60099r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60099r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60099r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60099r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60099r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60099r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60099r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60099r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60099r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60099r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60099r=mysqlcfg
[PHP-BUG] Bug #60100 [NEW]: segmentation fault at Zip::extractto()
From:
Operating system: PLD/Linux
PHP version: 5.3.8
Package: Reproducible crash
Bug Type: Bug
Bug description:segmentation fault at Zip::extractto()
Description:
(gdb) bt
#0 0x767a1e34 in free () from /lib64/libc.so.6
#1 0x711439ef in php_zip_extract_file (za=0xb01d40, dest=0xaddc28
test, file=0xb019b0 admin/, file_len=value optimized out)
at /usr/src/debug/php-5.3.8/ext/zip/php_zip.c:226
#2 0x71143d62 in c_ziparchive_extractTo (ht=value optimized out,
return_value=0xadc7f8, return_value_ptr=value optimized out,
this_ptr=value optimized out,
return_value_used=value optimized out) at
/usr/src/debug/php-5.3.8/ext/zip/php_zip.c:2487
#3 0x71a648b4 in ?? () from /usr/lib64/php/suhosin.so
#4 0x77d18b34 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3140) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:322
#5 0x77cb8fcb in execute (op_array=0xb01c50) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#6 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#7 0x77d1881c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3068) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:344
#8 0x77cb8fcb in execute (op_array=0xad9878) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#9 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#10 0x77c94a80 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.8/Zend/zend.c:1308
#11 0x77c40ff0 in php_execute_script (primary_file=0x7fffe440)
at /usr/src/debug/php-5.3.8/main/main.c:2299
#12 0x00404969 in main (argc=2, argv=0x7fffe5f8) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1188
Test script:
---
?
function zip_extract($file, $extractPath) {
$zip = new ZipArchive;
$res = $zip-open($file);
if ($res === TRUE) {
$zip-extractTo($extractPath);
$zip-close();
return TRUE;
} else {
return FALSE;
}
}
zip_extract('file11.zip','test');
--
Edit bug report at https://bugs.php.net/bug.php?id=60100edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60100r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60100r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60100r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60100r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60100r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60100r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60100r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60100r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60100r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60100r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60100r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60100r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60100r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60100r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60100r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60100r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60100r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60100r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60100r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60100r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60100r=mysqlcfg
Bug #60100 [Opn-Fbk]: segmentation fault at Zip::extractto()
Edit report at https://bugs.php.net/bug.php?id=60100edit=1
ID: 60100
Updated by: paj...@php.net
Reported by:adamg at pld-linux dot org
Summary:segmentation fault at Zip::extractto()
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: PLD/Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Please provide the zip file you use to test.
Previous Comments:
[2011-10-19 20:59:47] adamg at pld-linux dot org
Description:
(gdb) bt
#0 0x767a1e34 in free () from /lib64/libc.so.6
#1 0x711439ef in php_zip_extract_file (za=0xb01d40, dest=0xaddc28
test, file=0xb019b0 admin/, file_len=value optimized out)
at /usr/src/debug/php-5.3.8/ext/zip/php_zip.c:226
#2 0x71143d62 in c_ziparchive_extractTo (ht=value optimized out,
return_value=0xadc7f8, return_value_ptr=value optimized out, this_ptr=value
optimized out,
return_value_used=value optimized out) at
/usr/src/debug/php-5.3.8/ext/zip/php_zip.c:2487
#3 0x71a648b4 in ?? () from /usr/lib64/php/suhosin.so
#4 0x77d18b34 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3140) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:322
#5 0x77cb8fcb in execute (op_array=0xb01c50) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#6 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#7 0x77d1881c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffef0a3068) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:344
#8 0x77cb8fcb in execute (op_array=0xad9878) at
/usr/src/debug/php-5.3.8/Zend/zend_vm_execute.h:107
#9 0x71a64e64 in ?? () from /usr/lib64/php/suhosin.so
#10 0x77c94a80 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.8/Zend/zend.c:1308
#11 0x77c40ff0 in php_execute_script (primary_file=0x7fffe440) at
/usr/src/debug/php-5.3.8/main/main.c:2299
#12 0x00404969 in main (argc=2, argv=0x7fffe5f8) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1188
Test script:
---
?
function zip_extract($file, $extractPath) {
$zip = new ZipArchive;
$res = $zip-open($file);
if ($res === TRUE) {
$zip-extractTo($extractPath);
$zip-close();
return TRUE;
} else {
return FALSE;
}
}
zip_extract('file11.zip','test');
--
Edit this bug report at https://bugs.php.net/bug.php?id=60100edit=1
Bug #60097 [Opn]: token_get_all fails to lex nested heredoc
Edit report at https://bugs.php.net/bug.php?id=60097edit=1
ID: 60097
Updated by: fel...@php.net
Reported by:ni...@php.net
Summary:token_get_all fails to lex nested heredoc
Status: Open
Type: Bug
Package:*General Issues
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
It also causes a memory leak.
[Wed Oct 19 20:41:43 2011] Script: '../bug.php'
Zend/zend_language_scanner.l(2113) : Freeing 0xB73DFBA4 (4 bytes),
script=../bug.php
=== Total 1 memory leaks detected ===
Previous Comments:
[2011-10-19 17:06:58] ni...@php.net
Description:
token_get_all('?php
DOC
{$s(ppp
ppp
)}
DOC;
');
Doesn't recognize DOC; as the heredoc end.
Looks like some of the heredoc LEXING code was put in the PARSER.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60097edit=1
[PHP-BUG] Bug #60101 [NEW]: Limit to session_regenerate_id updates
From:
Operating system: Debian Squeeze
PHP version: 5.3.8
Package: Session related
Bug Type: Bug
Bug description:Limit to session_regenerate_id updates
Description:
Was doing some debugging on our session class and wanted to start from
scratch on
a few tests so we came up with the following, just to see how frequently we
his
collisions using the default session configs.
It appears that session_regenerate_id quits regenerating after 114 runs,
after
which the function simply fails.
Test script:
---
$arr = array();
session_id();
session_start();
for( $i = 0; $i = 10; $i++ )
{
$ses = session_id();
if(!session_regenerate_id(true) ) {
exit;
}
echo Session: . $ses. \n;
$arr[$ses]++;
}
print_r( array_count_values( $arr ) );
Expected result:
Every call to session_regenerate_id and then to session_id would result in
a new
ID, and without limit.
--
Edit bug report at https://bugs.php.net/bug.php?id=60101edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60101r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60101r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60101r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60101r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60101r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60101r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60101r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60101r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60101r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60101r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60101r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60101r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60101r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60101r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60101r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60101r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60101r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60101r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60101r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60101r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60101r=mysqlcfg
Bug #60096 [Opn-Bgs]: token_get_all on b$var returns invalid string token
Edit report at https://bugs.php.net/bug.php?id=60096edit=1
ID: 60096
Updated by: fel...@php.net
Reported by:ni...@php.net
Summary:token_get_all on b$var returns invalid string
token
-Status: Open
+Status: Bogus
Type: Bug
Package:*General Issues
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
Currently it's expected, as the 'b' prefix doesn't produces a separated token.
Previous Comments:
[2011-10-19 16:02:23] ni...@php.net
Description:
token_get_all('?php b$var') will return 'b' as a string-token, even though
it is not a single character.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60096edit=1
Bug #60099 [Opn-Bgs]: __halt_compiler() works in braced namespaces
Edit report at https://bugs.php.net/bug.php?id=60099edit=1
ID: 60099
Updated by: fel...@php.net
Reported by:ni...@php.net
Summary:__halt_compiler() works in braced namespaces
-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
why not? __halt_compiler() abort the parsing.
Previous Comments:
[2011-10-19 19:22:03] ni...@php.net
Description:
?php
namespace A {
__halt_compiler();
The above code will work, but I assume that it should not.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60099edit=1
Bug #27777 [Com]: basic authentication broken
Edit report at https://bugs.php.net/bug.php?id=2edit=1 ID: 2 Comment by: dewes at pop dot com dot br Reported by:mikx at mikx dot de Summary:basic authentication broken Status: No Feedback Type: Bug Package:SOAP related Operating System: Windows XP Pro PHP Version:5.0.0RC1 Block user comment: N Private report: N New Comment: The problem still in PHP Version 5.3.5. Previous Comments: [2010-11-15 16:56:31] oliver at teqneers dot de I have the same problem in PHP 5.3.3. It is not possible to fetch a HTTP basic/digest authentication protected WSDL. [2010-01-29 21:38:40] eric dot caron at gmail dot com Still having this problem as of PHP 5.3.2-dev on my Linux boxes. PHP 5.3.1 on my Windows box did not have this problem. [2009-05-07 13:32:47] Christian dot Reingruber at gmail dot com still a problem in 5.2.8 i guess... any ideas? [2008-06-19 14:16:33] trippinbilly25 at gmail dot com This is still a problem in 5.2.6. [2007-04-05 15:21:57] jgarcia at tdg-i dot com Bug still open in PHP 5.1.2 Found information from user post: Arjan van Bentem 12-Aug-2005 08:31 When using HTTP basic authentication, PHP will only send the credentials when invoking the service, not when fetching the WSDL. 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=2 -- Edit this bug report at https://bugs.php.net/bug.php?id=2edit=1
Bug #55777 [Com]: Error starting Apache server
Edit report at https://bugs.php.net/bug.php?id=55777edit=1 ID: 55777 Comment by: jlmueller at optonline dot net Reported by:jlmueller at optonline dot net Summary:Error starting Apache server Status: Open Type: Bug Package:Apache2 related Operating System: win xp sp3 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I tried going back to PHP 5.2.17 and now things work normally. I guess there is problem with the 5.3.x version form my configuration Previous Comments: [2011-10-08 01:20:15] jlmueller at optonline dot net I tried haryo's suggested change of '/' instead of '\'. I still get the same error message as before. [2011-10-07 04:15:39] haryo at ukdw dot ac dot id i've got same error with apache 2.2.21 and php 5.3.8 on windows 2008 server, then i try to change '\' character with '/' and apache run smoothly here's my conf PHPIniDir C:/PHP/ LoadFile C:/PHP/php5ts.dll LoadModule php5_module C:/PHP/php5apache2_2.dll php_value extension_dir C:/PHP/ext/ funny thing is: i have apache 2.2.19 which running okay with '\' char ..sorry for my english, it's not my first language [2011-09-25 01:34:02] jlmueller at optonline dot net Description: Just installed Apache 2.2.21 upgrade and PHP 5.3.8. Had run earlier editions of both without problem. We starting the Apache server it fails with the following error Faulting application httpd.exe, version 2.2.21.0, faulting module php5ts.dll, version 5.3.8.0, fault address 0x000f8a90. It is repeatable. If I comment out the following PHP entries in the Apache hppd.config file entries PHPIniDir C:\Program Files\PHP\ LoadModule php5_module C:\Program Files\PHP\php5apache2_2.dll Apache will start and I can do non-PHP based pages -- Edit this bug report at https://bugs.php.net/bug.php?id=55777edit=1
Bug #60090 [Bgs]: string bug
Edit report at https://bugs.php.net/bug.php?id=60090edit=1
ID: 60090
User updated by:systemcore0v34c10ck-iheartspam at yahoo dot com
Reported by:systemcore0v34c10ck-iheartspam at yahoo dot com
Summary:string bug
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:
Please delete this report, its not a bug in PHP but on Google Chrome. Output is
fine on view source for Firefox.
Previous Comments:
[2011-10-19 04:10:17] larue...@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
I think you meaning in Browser. you can run the script in CMD to look at the
result
[2011-10-19 03:31:19] systemcore0v34c10ck-iheartspam at yahoo 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 br / or \n, the correct string is returned.
Test script:
---
$foobar = A;
echo $foobar; //does not work!
(string) $foobar = A;
echo $foobar; //does not work!
function foobar(){
$foobar = A;
return $foobar;
}
echo foobar(); //does not work!
$foobar = Abr /;
echo $foobar; //works!
$foobar = A\n;
echo $foobar; //works!
Expected result:
A
--
Edit this bug report at https://bugs.php.net/bug.php?id=60090edit=1
Bug #29992 [Com]: foreach by reference corrupts the array
Edit report at https://bugs.php.net/bug.php?id=29992edit=1
ID: 29992
Comment by: bruce at kaskubar dot com
Reported by:fletch at pobox dot com
Summary:foreach by reference corrupts the array
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
With all due respect to those who spend their time developing, debugging, and
explaining PHP, BALDERDASH!
Elsewhere, those of us who continue to claim bug are supposed to be chastened
by all the explanations that have been provided over the years. The fact that
the reports persist and the explanations grow is evidence contrary to the
finding of Bogus and in support of what is expected behavior.
Fletch's example, for example, is real and reproducible through at least v5.3.2.
How in the world can it be expected for a (second) loop and its object to
perform as though no related instructions were executed previously, and then
for that interaction to raise its ugly head for only the last iteration? It
cannot be. It can be explained. But so can an earthquake be. That doesn't make
it expected.
I am unaware of any other case where prior use of a variable affects subsequent
use of the same-named variable where its value is being explicitly reset or, as
in the case of foreach, implicitly reset by virtue of its purpose. (That is, we
can use $i as a loop counter here and as a file handle there and as long as we
don't cross their purposes in the space-time continuum, all is well.)
The only bogus thing about this bug report and all its cousins is their shared
status.
Previous Comments:
[2011-09-02 15:13:42] publcishady at gmail dot com
If you describe how it works that's not an excuse for unexpected results. I
understand why the last element becomes a reference, but I don't understand why
it SHOULD become a reference. That's obviously a bug for me.
[2011-07-18 05:03:24] martijn at twotribes dot com
Well, it is expected by the people who designed the language perhaps, but not
by me. Iterating through an array, without doing anything, shouldn't change the
array. Period. If I do something similar in another language like C++, this
will never be the result.
[2011-07-15 11:57:04] johan...@php.net
daniel,
unsetting it before might also cause a wrong result. Simple example:
?php
function search_element($array, $var) {
foreach ($array as $var) {
if ($condition) {
return true;
}
}
}
$array=array(1,2,3,4,5,6);
$var = null;
search_element($array, $var);
?
This is simplified and probably no good architecture but such designs might
make sense in some situations and breaking that adds a larger inconsistency
than the current surprising but consistent behavior.
martijn,
Of course there is a reference at the end, absolutely expected and consistent
with the language.
[2011-07-13 06:48:49] martijn at twotribes dot com
To elaborate of why I strongly feel this is a bug and not a 'feature':
$a = array('a', 'b', 'c', 'd');
foreach ($a as $v) { }
var_dump($a);
One would expect that every element of $a is a string. Well it was, up until I
did that foreach-with-reference. That changed the last element into string
reference:
array(4) {
[0]=
string(1) a
[1]=
string(1) b
[2]=
string(1) c
[3]=
string(1) d
}
The PHP guys can claim that this is correct behavior all they want, but it is
fundamentally wrong from a design perspective that an array changes, without
doing anything to its elements.
[2011-07-13 06:37:58] martijn at twotribes dot com
Can someone please promote this bogus status to an actual bug? It completely
baffles me why something so obviously wrong, has been present in PHP for almost
7(!) years. Come on guys, fix this!
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=29992
--
Edit this bug report at https://bugs.php.net/bug.php?id=29992edit=1
Bug #60096 [Com]: token_get_all on b$var returns invalid string token
Edit report at https://bugs.php.net/bug.php?id=60096edit=1
ID: 60096
Comment by: ni...@php.net
Reported by:ni...@php.net
Summary:token_get_all on b$var returns invalid string
token
Status: Bogus
Type: Bug
Package:*General Issues
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
I doubt that this is expected. Only single characters can be represented using
a one-char string token, because the token number and token text are identical
in this case.
'b' is not a single character and thus can't be returned as a string token,
because the token number is chr(''), not chr('b') (which is chr('b')).
Previous Comments:
[2011-10-19 22:55:35] 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
Currently it's expected, as the 'b' prefix doesn't produces a separated token.
[2011-10-19 16:02:23] ni...@php.net
Description:
token_get_all('?php b$var') will return 'b' as a string-token, even though
it is not a single character.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60096edit=1
Bug #60099 [Com]: __halt_compiler() works in braced namespaces
Edit report at https://bugs.php.net/bug.php?id=60099edit=1
ID: 60099
Comment by: ni...@php.net
Reported by:ni...@php.net
Summary:__halt_compiler() works in braced namespaces
Status: Bogus
Type: Bug
Package:Scripting Engine problem
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
__halt_compiler is supposed to work only in outermost scope. For example this
would not work:
?php
if ('a') { // or if(): or do { or switch() { or ...
__halt_compiler();
Previous Comments:
[2011-10-19 22:59:29] 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
why not? __halt_compiler() abort the parsing.
[2011-10-19 19:22:03] ni...@php.net
Description:
?php
namespace A {
__halt_compiler();
The above code will work, but I assume that it should not.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60099edit=1
Bug #60082 [PATCH]: 100% CPU / when using references with ArrayObject($ref).
Edit report at https://bugs.php.net/bug.php?id=60082edit=1 ID: 60082 Patch added by: tony2...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject($ref). Status: Assigned Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 Assigned To:helly Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: recursion-detection Revision: 1319089482 URL: https://bugs.php.net/patch-display.php?bug=60082patch=recursion-detectionrevision=1319089482 Previous Comments: [2011-10-19 02:28:53] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318204 Log: Test for #60082 [2011-10-19 02:09:08] larue...@php.net helly, plz look at this. thanks :) [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=60082patch=bug60082.phptrevision=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=60082patch=bug60082.patchrevision=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 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=60082 -- Edit this bug report at https://bugs.php.net/bug.php?id=60082edit=1
Bug #60082 [Asn]: 100% CPU / when using references with ArrayObject($ref).
Edit report at https://bugs.php.net/bug.php?id=60082edit=1 ID: 60082 Updated by: tony2...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject($ref). Status: Assigned Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 Assigned To:helly Block user comment: N Private report: N New Comment: I'd suggest to try to detect recursion in this case. Unfortunately, I don't see any way to do it except by adding another field to spl_array internal struct. But on the other hand, this struct is not used anywhere except spl_array.c itself, so it should be fine. The patch is attached. Previous Comments: [2011-10-20 05:44:42] tony2...@php.net The following patch has been added/updated: Patch Name: recursion-detection Revision: 1319089482 URL: https://bugs.php.net/patch-display.php?bug=60082patch=recursion-detectionrevision=1319089482 [2011-10-19 02:28:53] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318204 Log: Test for #60082 [2011-10-19 02:09:08] larue...@php.net helly, plz look at this. thanks :) [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=60082patch=bug60082.phptrevision=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=60082patch=bug60082.patchrevision=1318941980 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=60082 -- Edit this bug report at https://bugs.php.net/bug.php?id=60082edit=1
