Bug #49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867&edit=1 ID: 49867 Comment by: Reported by: nicolas dot lepage at yahoo dot fr Summary: spl_autoload crashes when called in write function of custom sessionSaveHandler Status: No Feedback Type: Bug Package: SPL related Operating System: * PHP Version: 5.3.0 New Comment: After many hours I finally found this bug report and I am experiencing this same issue. With a little guidance (I don't claim to be an expert) I'd be happy to provide a self contained script. Previous Comments: [2010-02-19 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". [2010-02-11 13:55:47] tomas dot plesek at gmail dot com Ok, I will provide test suite some time later in the evening, as this issue is not easily demonstrated. [2010-02-11 10:58:35] paj...@php.net Can you please provid a small reproduce script, self contained, so we can run a diagnostic and try to fix this issue. Please post this script here, this bug report seems to be valid but the infos are splitted between blog posts, external forums and extensive explanations, that does not help. [2010-02-11 10:41:12] nicolas dot lepage at yahoo dot fr Reopening [2010-02-11 10:36:31] tomas dot plesek at gmail dot com I think more insight is welcome, so here we go: As to the article on stackoverflow referenced above, it works, but in somewhat different context. The fact mentioned there work arounds the problem with Zend Framework and opcode cachers. It is true, that if you have no custom session handler ant you won't call either Zend_Session::writeClose() (or session_write_close() for that matter), it will crash yout sp_autoload in described manner. What are we dealing with here is when a custom handler is defined as a class and it tries to instantiate another class (say some wrapper object around the session data), the issue will occur in these situations: * calling new on non-defined class altogether * calling new on a class that is to be autoloaded through autoloader * the class instatiated through new hasDEPENDENT CLASS(es) THAT USE AUTOLOADER for their function, i.e.: I can require_once the class giving me trouble, but if it depends on other classes, we are back to square one. What is the most confusing fact, the autoloader complains about non- loadable classes, but it can be a class half-way down the dependency tree. (and that is why I've seen this bug reported on Doctrine project bugtracker, because if you use Doctrine class for session saving like I do, the autoloader will probably complain about not able to load some Doctrine class) It is as if the autoloader crashes, but not immidiately in the write function of the session class. As I mentioned before, 5.2.6 was working for me, so was 5.3.0 (but from Zend server CE version), the rest in between and the latest build (5.3.1) give me the trouble. I can supply more detail to developers, I studied this phenomenon rather thoroughly, as you can imagine. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49867 -- Edit this bug report at http://bugs.php.net/bug.php?id=49867&edit=1
Bug #51190 [Csd]: ftp_put() returns false when transfer was successful
Edit report at http://bugs.php.net/bug.php?id=51190&edit=1 ID: 51190 User updated by: alexclifford47 at gmail dot com Reported by: alexclifford47 at gmail dot com Summary: ftp_put() returns false when transfer was successful Status: Closed Type: Bug Package: FTP related Operating System: Windows Server 2003 R2 32-bit PHP Version: 5.3.1 Assigned To: iliaa New Comment: I notice you added a check for the 200 response in ftp.c. This didn't fix the problem for me. But also adding a check for a 221 response did. Is it possible to have this added into the codebase too? Previous Comments: [2010-03-05 04:11:34] alexclifford47 at gmail dot com I will give this a try when I get a chance. How long until these fixes are into a stable release? Thanks. [2010-03-04 13:53:12] il...@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. [2010-03-04 13:52:59] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=295820 Log: Fixed bug #51190 (ftp_put() returns false when transfer was successful). [2010-03-03 15:55:56] araje at usimagingnetwork dot com I'm having the exact same problem.. The upload is successful , however ftp_put returns false... Any info would be appreciated. Thanks Ameya [2010-03-03 05:47:50] alexclifford47 at gmail dot com Description: Hi, I am getting the following warning message when trying to use ftp_put(): Warning: ftp_put(): Transfer OK This is causing the function to return false, when in fact the file is transferred successfully. I have Googled this warning message but no one else has ever received it. Where is this warning coming from and why is PHP reporting a "Transfer OK" as a warning? Destination server is Windows Server 2008 64-bit running FileZilla Server (latest version). Alex Test script: --- $conn_id = ftp_connect($ftp_server); ftp_login($conn_id, $ftp_user, $ftp_pass); if (ftp_put($conn_id, Expected result: 1 Actual result: -- Warning: ftp_put(): Transfer OK 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=51190&edit=1
Bug #51242 [Asn->Csd]: Empty mysql.default_port does not default to 3306 anymore, but 0
Edit report at http://bugs.php.net/bug.php?id=51242&edit=1
ID: 51242
Updated by: ahar...@php.net
Reported by: php-bugs at thequod dot de
Summary: Empty mysql.default_port does not default to 3306 anymore,
but 0
-Status: Assigned
+Status: Closed
Type:Bug
Package: MySQL related
PHP Version: 5.3.2
Assigned To: aharvey
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-03-09 06:08:33] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=295982
Log: Fixed bug #51242 (Empty mysql.default_port does not default to 3306
anymore, but 0).
[2010-03-09 05:20:50] ahar...@php.net
I can reproduce this with a current, unpatched PHP_5_3 build. It does
require an
unusual and rather specific set of circumstances, though:
1. PHP has to be configured with --with-mysql-sock set and mysqlnd
support.
2. mysql.default_port= must be in a configuration file without a value.
3. mysql_connect() must be called without a port specified.
Effectively, the empty string for the port setting gets converted by the
atoi()
call in OnMySQLPort to 0, which results in mysqlnd's connect method
being called
with port = 0. Said connect method has a test where the port is set to
3306 if
both the port and socket aren't specified. In this case, of course, the
socket
is specified, even though it's unused, and hence the port number never
gets
reset.
This works with an external libmysqlclient because mysql_real_connect()
handles
the port being 0.
Fix forthcoming shortly, once I've satisfied myself it doesn't break
anything
else.
[2010-03-09 00:54:48] php-bugs at thequod dot de
TML could not reproduce this on ##php:
php -d mysql.default_port="" -r '$db = mysql_connect("127.0.0.1") or
die(mysql_error()); var_dump($db);'
I can (although using another IP).
The difference is also that I'm using the Suhosin patch (via dotdeb.org)
and TML
is not.
[2010-03-09 00:33:35] php-bugs at thequod dot de
Description:
I've upgraded a server to PHP 5.3.2 (from dotdeb.org), and got
"Connection
refused" errors from mysql_connect.
The cause was that I've not specified a port with $host, and PHP used
"0"
apparently:
Connection refused (trying to connect via tcp://10.122.42.42:0)
I have âmysql.default_port = â in the ini file, which is the default
(I assume),
and it defaulted to 3306 then previously (5.3.1 from dotdeb), but not
anymore.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51242&edit=1
Bug #51242 [Opn->Asn]: Empty mysql.default_port does not default to 3306 anymore, but 0
Edit report at http://bugs.php.net/bug.php?id=51242&edit=1
ID: 51242
Updated by: ahar...@php.net
Reported by: php-bugs at thequod dot de
Summary: Empty mysql.default_port does not default to 3306 anymore,
but 0
-Status: Open
+Status: Assigned
Type:Bug
Package: MySQL related
PHP Version: 5.3.2
Assigned To: aharvey
New Comment:
I can reproduce this with a current, unpatched PHP_5_3 build. It does
require an
unusual and rather specific set of circumstances, though:
1. PHP has to be configured with --with-mysql-sock set and mysqlnd
support.
2. mysql.default_port= must be in a configuration file without a value.
3. mysql_connect() must be called without a port specified.
Effectively, the empty string for the port setting gets converted by the
atoi()
call in OnMySQLPort to 0, which results in mysqlnd's connect method
being called
with port = 0. Said connect method has a test where the port is set to
3306 if
both the port and socket aren't specified. In this case, of course, the
socket
is specified, even though it's unused, and hence the port number never
gets
reset.
This works with an external libmysqlclient because mysql_real_connect()
handles
the port being 0.
Fix forthcoming shortly, once I've satisfied myself it doesn't break
anything
else.
Previous Comments:
[2010-03-09 00:54:48] php-bugs at thequod dot de
TML could not reproduce this on ##php:
php -d mysql.default_port="" -r '$db = mysql_connect("127.0.0.1") or
die(mysql_error()); var_dump($db);'
I can (although using another IP).
The difference is also that I'm using the Suhosin patch (via dotdeb.org)
and TML
is not.
[2010-03-09 00:33:35] php-bugs at thequod dot de
Description:
I've upgraded a server to PHP 5.3.2 (from dotdeb.org), and got
"Connection
refused" errors from mysql_connect.
The cause was that I've not specified a port with $host, and PHP used
"0"
apparently:
Connection refused (trying to connect via tcp://10.122.42.42:0)
I have âmysql.default_port = â in the ini file, which is the default
(I assume),
and it defaulted to 3306 then previously (5.3.1 from dotdeb), but not
anymore.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51242&edit=1
[PHP-BUG] Bug #51244 [NEW]: segv on zend_mm_search_large_block
From:
Operating system: CentOS release 5.4
PHP version: 5.3.2
Package: Unknown/Other Function
Bug Type: Bug
Bug description:segv on zend_mm_search_large_block
Description:
I create a extension to use my function written in C++ from PHP.
# I don't talk about the details of my extionsion because it is
proprietary.
configure parameters:
./configure --with-apxs2=/usr/local/apache2/bin/apxs \
--enable-sysvsem \
--enable-maintainer-zts \
--with-tsrm-pthreads
My extension is multi-threaded so PHP is the same.
When I pass hundreds of data to my extension, hundreds of threads are
created, and thousands of emallocs are called (though small size each).
# Physical memory = 256MB, Swap = 512MB
The first time I do it, it normally succeed.
But the second time, segmentation fault raised.
$ sudo gdb /usr/local/apache2/bin/httpd
(gdb) run -X -f /usr/local/apache2/conf/httpd.conf
---snip---
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x32ebb90 (LWP 5878)]
0x013b3d07 in zend_mm_search_large_block (heap=0x9a8cd70, true_size=16)
at /usr/local/src/php-5.3.2/Zend/zend_alloc.c:1792
1792while ((p = p->child[p->child[0] != NULL])) {
(gdb) bt
#0 0x013b3d07 in zend_mm_search_large_block (heap=0x9a8cd70,
true_size=16)
at /usr/local/src/php-5.3.2/Zend/zend_alloc.c:1792
#1 0x013b3e34 in _zend_mm_alloc_int (heap=0x9a8cd70, size=1)
at /usr/local/src/php-5.3.2/Zend/zend_alloc.c:1852
#2 0x013b4d51 in _emalloc (size=1)
at /usr/local/src/php-5.3.2/Zend/zend_alloc.c:2340
#3 0x013b514f in _estrdup (s=0x706abf0 "")
at /usr/local/src/php-5.3.2/Zend/zend_alloc.c:2481
#4 0x06fb31ef in [snip] (arg=0x8cde23c)
at [snip]
#5 0x0098273b in start_thread () from /lib/libpthread.so.0
#6 0x00900cfe in clone () from /lib/libc.so.6
(gdb) p p
$1 = (zend_mm_free_block *) 0x0
(gdb) p *heap
$2 = {use_zend_alloc = 1, _malloc = 0, _free = 0, _realloc = 0,
free_bitmap = 0, large_free_bitmap = 131072, block_size = 262144,
compact_size = 2097152, segments_list = 0x9a8cfd0, storage = 0x9a8cd60,
real_size = 262144, real_peak = 262144, limit = 134217728, size = 10340,
peak = 10340, reserve_size = 8192, reserve = 0x9a8cfe0, overflow = 0,
internal = 0, cached = 76, cache = {0x0, 0x0, 0x9a8efe0, 0x0, 0x0, 0x0,
0x0,
0x0, 0x0, 0x9a8eff8, 0x0 }, free_buckets =
{0x9a8ce38,
0x9a8ce38, 0x9a8ce40, 0x9a8ce40, 0x9a8ce48, 0x9a8ce48, 0x9a8ce50,
0x9a8ce50, 0x9a8ce58, 0x9a8ce58, 0x9a8ce60, 0x9a8ce60, 0x9a8ce68,
0x9a8ce68, 0x9a8ce70, 0x9a8ce70, 0x9a8ce78, 0x9a8ce78, 0x9a8ce80,
0x9a8ce80, 0x9a8ce88, 0x9a8ce88, 0x9a8ce90, 0x9a8ce90, 0x9a8ce98,
0x9a8ce98, 0x9a8cea0, 0x9a8cea0, 0x9a8cea8, 0x9a8cea8, 0x9a8ceb0,
0x9a8ceb0, 0x9a8ceb8, 0x9a8ceb8, 0x9a8cec0, 0x9a8cec0, 0x9a8cec8,
0x9a8cec8, 0x9a8ced0, 0x9a8ced0, 0x9a8ced8, 0x9a8ced8, 0x9a8cee0,
0x9a8cee0, 0x9a8cee8, 0x9a8cee8, 0x9a8cef0, 0x9a8cef0, 0x9a8cef8,
0x9a8cef8, 0x9a8cf00, 0x9a8cf00, 0x9a8cf08, 0x9a8cf08, 0x9a8cf10,
0x9a8cf10, 0x9a8cf18, 0x9a8cf18, 0x9a8cf20, 0x9a8cf20, 0x9a8cf28,
0x9a8cf28, 0x9a8cf30, 0x9a8cf30}, large_free_buckets = {
0x0 }, rest_buckets = {0x9a8cfb8, 0x9a8cfb8}}
(gdb) p heap->large_free_buckets
$3 = {0x0 }
I don't know this is the right way, but just add NULL check and nothing
happened.
$ git diff HEAD^
diff --git a/Zend/zend_alloc.c b/Zend/zend_alloc.c
index dac5454..707f75a 100644
--- a/Zend/zend_alloc.c
+++ b/Zend/zend_alloc.c
@@ -1789,6 +1789,7 @@ static zend_mm_free_block
*zend_mm_search_large_block(zend
/* Search for smallest "large" free block */
best_fit = p = heap->large_free_buckets[index +
zend_mm_low_bit(bitmap)]
+ if(!best_fit) return NULL;
while ((p = p->child[p->child[0] != NULL])) {
if (ZEND_MM_FREE_BLOCK_SIZE(p) <
ZEND_MM_FREE_BLOCK_SIZE(best_fi
best_fit = p;
--
Edit bug report at http://bugs.php.net/bug.php?id=51244&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51244&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51244&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51244&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51244&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51244&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51244&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51244&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51244&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51244&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51244&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=5124
[PHP-BUG] Bug #51243 [NEW]: syntax error in autoload causes segmentation fault
From: Operating system: CentOS5.* PHP version: 5.3.2 Package: Apache2 related Bug Type: Bug Bug description:syntax error in autoload causes segmentation fault Description: Segmentation fault was occured when the file was loaded by calling require() or inclede() inside of autoload function , and it contains some php syntax error. It is often happend. The most case is after make changes of script repeatedly. Test script: --- === C.php === pr(); Expected result: Report syntax error. Actual result: -- Program received signal SIGSEGV, Segmentation fault. 0xb79dcb28 in zend_mm_check_ptr (heap=0x81b8a10, ptr=0x841fc78, silent=0, __zend_filename=0xb7f3234b "Zend/zend_language_scanner.l", __zend_lineno=685, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /s/php-5.3.2/Zend/zend_alloc.c:1355 1355if (p->info._prev != ZEND_MM_GUARD_BLOCK && (gdb) bt #0 0xb79dcb28 in zend_mm_check_ptr (heap=0x81b8a10, ptr=0x841fc78, silent=0, __zend_filename=0xb7f3234b "Zend/zend_language_scanner.l", __zend_lineno=685, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /s/php-5.3.2/Zend/zend_alloc.c:1355 #1 0xb79dcaff in zend_mm_check_ptr (heap=0x81b8a10, ptr=0x841fc78, silent=1, __zend_filename=0xb7f3234b "Zend/zend_language_scanner.l", __zend_lineno=685, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /s/php-5.3.2/Zend/zend_alloc.c:1352 #2 0xb79de08c in _zend_mm_free_int (heap=0x81b8a10, p=0x841fc78, __zend_filename=0xb7f3234b "Zend/zend_language_scanner.l", __zend_lineno=685, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /s/php-5.3.2/Zend/zend_alloc.c:1983 #3 0xb79df163 in _efree (ptr=0x841fc78, __zend_filename=0xb7f3234b "Zend/zend_language_scanner.l", __zend_lineno=685, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /s/php-5.3.2/Zend/zend_alloc.c:2351 #4 0xb79c6105 in zend_multibyte_read_script (buf=0xb7157000 " to continue, or q to quit--- #28 0x08082797 in ap_invoke_handler (r=0x83a1538) at config.c:372 #29 0x080d64f8 in ap_process_request (r=0x83a1538) at http_request.c:282 #30 0x080d36db in ap_process_http_connection (c=0x83e1af0) at http_core.c:190 #31 0x08086769 in ap_run_process_connection (c=0x83e1af0) at connection.c:43 #32 0x08104f1d in child_main (child_num_arg=) at prefork.c:662 #33 0x08105163 in make_child (s=0x8152c98, slot=0) at prefork.c:702 #34 0x08105f3c in ap_mpm_run (_pconf=0x814a550, plog=0x81a47f8, s=0x8152c98) at prefork.c:978 #35 0x0806cf25 in main (argc=135562568, argv=0x83df910) at main.c:740 -- Edit bug report at http://bugs.php.net/bug.php?id=51243&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51243&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51243&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51243&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51243&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51243&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51243&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51243&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51243&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51243&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51243&r=support Expected behavior: http://bugs.php.net/fix.php?id=51243&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51243&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51243&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51243&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51243&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51243&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51243&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51243&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51243&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51243&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51243&r=mysqlcfg
Bug #49270 [Opn]: configure fails if PHP source folder path contains spaces
Edit report at http://bugs.php.net/bug.php?id=49270&edit=1 ID: 49270 Updated by: fel...@php.net Reported by: moisadoru at gmail dot com Summary: configure fails if PHP source folder path contains spaces Status: Open Type: Bug -Package: PDO related +Package: Compile Failure Operating System: Ubuntu linux 9.10alpha3 64bit -PHP Version: 6SVN-2009-08-16 (snap) +PHP Version: 5.2, 5.3, 6 New Comment: This patch isn't enough to get PHP building. It just fix the PDO part, but there are other issues yet. Previous Comments: [2009-08-16 01:53:46] moisadoru at gmail dot com Description: If you extract the sources snapshot inside a folder that has spaces in the path, the configure fails with a message similar to this: "checking for PDO includes... test: 1: /media/Disc: unexpected operator" I extracted the sources into the "/media/Disc 1/php6" folder. Inside the configure.log file there is a reference to configure:67842 and something about not finding "php_pdo_driver.h" Here is my patch --- /home/user/php6.0-200908152030/configure.original +++ /home/user/php6.0-200908152030/configure @@ -67839,11 +67839,11 @@ echo $ac_n "checking for PDO includes""... $ac_c" 1>&6 echo "configure:67842: checking for PDO includes" >&5 -if test -f $abs_srcdir/include/php/ext/pdo/php_pdo_driver.h; then +if test -f "$abs_srcdir/include/php/ext/pdo/php_pdo_driver.h"; then pdo_inc_path=$abs_srcdir/ext -elif test -f $abs_srcdir/ext/pdo/php_pdo_driver.h; then +elif test -f "$abs_srcdir/ext/pdo/php_pdo_driver.h"; then pdo_inc_path=$abs_srcdir/ext -elif test -f $prefix/include/php/ext/pdo/php_pdo_driver.h; then +elif test -f "$prefix/include/php/ext/pdo/php_pdo_driver.h"; then pdo_inc_path=$prefix/include/php/ext fi Reproduce code: --- This is my configure command: ./configure --with-apxs2=/usr/bin/apxs2 --with-mysql --prefix=/opt/php6 --with-regex --with-libxml-dir=/usr/lib --with-openssl=/usr/lib --with-pcre-regex --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-curl --with-enchant=/usr/lib --enable-exif --enable-ftp --with-gd --enable-gd-native-ttf --with-gettext --with-gmp --with-mhash --with-imap --with-imap-ssl --enable-intl --enable-mbstring --with-mcrypt --with-mssql --with-mysql --with-mysqli --enable-embedded-mysqli --enable-pcntl --with-pspell --with-libedit --with-readline --enable-shmop --enable-soap --enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-tidy --with-xmlrpc --with-xsl --enable-zip --with-openssl=/usr --with-enchant=/usr --with-kerberos --enable-embedded-mysqli=shared --with-pdo-mysql=shared Expected result: It should configure just fine Actual result: -- "checking for PDO includes... test: 1: /media/Disc: unexpected operator" -- Edit this bug report at http://bugs.php.net/bug.php?id=49270&edit=1
Req #9250 [Com]: Nested Functions are BAD, they make for inefficient debugging
Edit report at http://bugs.php.net/bug.php?id=9250&edit=1
ID: 9250
Comment by:
Reported by: dsifry at linuxcare dot com
Summary: Nested Functions are BAD, they make for inefficient
debugging
Status: Bogus
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Any
PHP Version: 4.0.4pl1
New Comment:
nested functions make for grate walkers in recursive functions
BUT ! ONLY
if the scope is limited with in the outer function (witch it isn't)
AND can use same variables as outer function
Previous Comments:
[2002-01-06 13:15:00] j...@php.net
brackets are used for other controll structures as well, so disabling
nested functions do not solve the problem. ->bogus
[2001-02-14 04:10:46] dsifry at linuxcare dot com
If you have a missing close-bracket "}" somewhere in your code, the PHP
parser tells you that the error is at the last line. If you have a
multi-hundred or thousand line file, this makes life a bitch.
Rasmus tells me that the reason for this behavior is because functions
can be nested, which means that:
function a
{
function b
{
}
}
is OK. This is a silly feature. Why do you have it, for scoping
reasons? It means that you can't effectively tell where syntax errors
occur.
Suggestion: Either make nested functions turned off by default but you
can turn them on with a PHP global variable, like
$PHP_BIZARRO_NESTED_FUNCTIONS = 1;
or
have the parser syntax set up so that it marks where a possible syntax
error occurred (IOW it sees a possible nested function, but it could
also be a syntax error), and if it reaches the end of the file with a
missing "}" or two, that it displays the location where it parsed the
nested function.
--
Edit this bug report at http://bugs.php.net/bug.php?id=9250&edit=1
Bug #51242 [Com]: Empty mysql.default_port does not default to 3306 anymore, but 0
Edit report at http://bugs.php.net/bug.php?id=51242&edit=1
ID: 51242
Comment by:
Reported by: php-bugs at thequod dot de
Summary: Empty mysql.default_port does not default to 3306 anymore,
but 0
Status: Open
Type:Bug
Package: MySQL related
PHP Version: 5.3.2
New Comment:
TML could not reproduce this on ##php:
php -d mysql.default_port="" -r '$db = mysql_connect("127.0.0.1") or
die(mysql_error()); var_dump($db);'
I can (although using another IP).
The difference is also that I'm using the Suhosin patch (via dotdeb.org)
and TML
is not.
Previous Comments:
[2010-03-09 00:33:35] php-bugs at thequod dot de
Description:
I've upgraded a server to PHP 5.3.2 (from dotdeb.org), and got
"Connection
refused" errors from mysql_connect.
The cause was that I've not specified a port with $host, and PHP used
"0"
apparently:
Connection refused (trying to connect via tcp://10.122.42.42:0)
I have âmysql.default_port = â in the ini file, which is the default
(I assume),
and it defaulted to 3306 then previously (5.3.1 from dotdeb), but not
anymore.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51242&edit=1
Bug #51238 [Opn->Bgs]: Segfault with preg_replace
Edit report at http://bugs.php.net/bug.php?id=51238&edit=1
ID: 51238
Updated by: fel...@php.net
Reported by: odou...@php.net
Summary: Segfault with preg_replace
-Status: Open
+Status: Bogus
Type: Bug
Package: PCRE related
Operating System: all
PHP Version: 5.3.2
New Comment:
This is due a known PCRE issue.
http://man.he.net/man3/pcrestack
Not a PHP bug. Thanks.
Previous Comments:
[2010-03-08 18:01:31] odou...@php.net
Description:
You can make a segfault with a particular regexp (that appears to be
used in Mysqli, or in Zend Framework at least).
This bug appears on :
PHP 5.3.2
PHP 5.2.10
PHP 4
with internal pcrelib of course.
NOTE:
I cannot reproduce this bug everytime. Once in a while, the segfault is
not triggered (weird ...).
NOTE 2:
Same bug (segfault) with preg_match or preg_match_all
Test script:
---
..., ecode=0x8dcd78e "_",
mstart=0xb7508c64 "'", 'a' ..., offset_top=4,
md=0xbfdced54, ims=0, eptrb=0x0, flags=0, rdepth=20133) at
/usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:454
454 {
#0 match (eptr=0xb750b3b7 'a' ..., ecode=0x8dcd78e
"_", mstart=0xb7508c64 "'", 'a' ..., offset_top=4,
md=0xbfdced54, ims=0, eptrb=0x0, flags=0, rdepth=20133) at
/usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:454
#1 0x080ebc9a in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1533
#2 0x080e78f4 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:734
#3 0x080ebc9a in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1533
#4 0x080e78f4 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:734
#5 0x080ebc9a in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1533
#6 0x080e78f4 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:734
[ ... snip because backtrace shows what appears to be a loop ... ]
#20131 0x080ebc9a in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1533
#20132 0x080e78f4 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:734
#20133 0x080e7df8 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1395
#20134 0x080f235a in php_pcre_exec (argument_re=0x8dcd760,
extra_data=0xbfdceef4, subject=0xb7508c64 "'", 'a' ...,
length=50001, start_offset=0, options=Variable "options" is not
available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:5641
#20135 0x080f62a9 in php_pcre_replace_impl (pce=0x8dcd8f8,
subject=0xb7508c64 "'", 'a' ..., subject_len=50001,
replace_val=0xb74fad54, is_callable_replace=0,
result_len=0xbfdcf088, limit=-1, replace_count=0xbfdcf074)
at /usr/src/php/php-5.3.2/ext/pcre/php_pcre.c:1040
#20136 0x080f6fc5 in php_pcre_replace (regex=0xb74fb284
"/'('|{2}|[^'])*'/", regex_len=21,
subject=0xb7508c64 "'", 'a' ...,
subject_len=50001, replace_val=0xb74fad54, is_callable_replace=0,
result_len=0xbfdcf088,
limit=-1, replace_count=0xbfdcf074) at
/usr/src/php/php-5.3.2/ext/pcre/php_pcre.c:950
#20137 0x080f7542 in php_replace_in_subject (regex=0xb74fad70,
replace=Variable "replace" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/php_pcre.c:1267
#20138 0x080f7bb6 in preg_replace_impl (ht=Variable "ht" is not
available.
) at /usr/src/php/php-5.3.2/ext/pcre/php_pcre.c:1365
#20139 0x084b3c81 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb7470028) at zend_vm_execute.h:313
#20140 0x084acf86 in execute (op_array=0xb74fb1ec) at
zend_vm_execute.h:104
#20141 0x08484fe6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php/php-5.3.2/Zend/zend.c:1194
#20142 0x0842c036 in php_execute_script (primary_file=0xbfdd16f4) at
/usr/src/php/php-5.3.2/main/main.c:2260
#20143 0x085157e8 in main (argc=2, argv=0xbfdd1854) at
/usr/src/php/php-5.3.2/sapi/cli/php_cli.c:1192
--
Edit this bug report at http://bugs.php.net/bug.php?id=51238&edit=1
[PHP-BUG] Bug #51242 [NEW]: Empty mysql.default_port does not default to 3306 anymore, but 0
From: Operating system: PHP version: 5.3.2 Package: MySQL related Bug Type: Bug Bug description:Empty mysql.default_port does not default to 3306 anymore, but 0 Description: I've upgraded a server to PHP 5.3.2 (from dotdeb.org), and got "Connection refused" errors from mysql_connect. The cause was that I've not specified a port with $host, and PHP used "0" apparently: Connection refused (trying to connect via tcp://10.122.42.42:0) I have âmysql.default_port = â in the ini file, which is the default (I assume), and it defaulted to 3306 then previously (5.3.1 from dotdeb), but not anymore. -- Edit bug report at http://bugs.php.net/bug.php?id=51242&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51242&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51242&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51242&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51242&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51242&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51242&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51242&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51242&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51242&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51242&r=support Expected behavior: http://bugs.php.net/fix.php?id=51242&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51242&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51242&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51242&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51242&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51242&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51242&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51242&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51242&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51242&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51242&r=mysqlcfg
Bug #51237 [Opn->Csd]: milter SAPI crash on startup
Edit report at http://bugs.php.net/bug.php?id=51237&edit=1
ID: 51237
Updated by: fel...@php.net
Reported by: igmar at palsenberg dot com
Summary: milter SAPI crash on startup
-Status: Open
+Status: Closed
Type: Bug
Package: Reproducible crash
Operating System: Linux
PHP Version: 5.3.2
Assigned To: felipe
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/.
Thank you for the report, and for helping us make PHP better.
Thanks for the patch. :)
Previous Comments:
[2010-03-09 00:29:47] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=295978
Log: - Fixed bug #51237 (milter SAPI crash on startup)
patch by: igmar at palsenberg dot com
[2010-03-08 16:51:29] igmar at palsenberg dot com
Description:
./configure --with-milter
./php-milter
Segmentation fault
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
virtual_fopen (path=0x0, mode=0x83e3227 "rb", tsrm_ls=0x8644018)
at /home/igmar/php-5.3.2/TSRM/tsrm_virtual_cwd.c:1299
1299if (path[0] == '\0') { /* Fail to open empty path */
(gdb) bt
#0 virtual_fopen (path=0x0, mode=0x83e3227 "rb", tsrm_ls=0x8644018)
at /home/igmar/php-5.3.2/TSRM/tsrm_virtual_cwd.c:1299
#1 0x0838ca92 in mlfi_init (argc=1, argv=0xbfffe9c4)
at /home/igmar/php-5.3.2/sapi/milter/php_milter.c:131
#2 main (argc=1, argv=0xbfffe9c4)
at /home/igmar/php-5.3.2/sapi/milter/php_milter.c:1160
--
Edit this bug report at http://bugs.php.net/bug.php?id=51237&edit=1
[PHP-BUG] Doc #51241 [NEW]: missing changelog for prepend parameter on spl_autoload_register
From: Operating system: PHP version: 5.2.13 Package: SPL related Bug Type: Documentation Problem Bug description:missing changelog for prepend parameter on spl_autoload_register Description: The documentation fails to mention that the $prepend parameter was added in php 5.3 Test script: --- = 5.1.2. However, the two assertions fail in 5.2.13. Expected output Array ( [0] => bar, [1] => foo ) Actual result: -- Warning: assert(): Assertion failed in blah.php on line 9 Warning: assert(): Assertion failed in blah.php on line 10 Array ( [0] => foo ) -- Edit bug report at http://bugs.php.net/bug.php?id=51241&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51241&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51241&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51241&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51241&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51241&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51241&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51241&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51241&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51241&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51241&r=support Expected behavior: http://bugs.php.net/fix.php?id=51241&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51241&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51241&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51241&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51241&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51241&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51241&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51241&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51241&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51241&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51241&r=mysqlcfg
Bug #48551 [Com]: Unable to compile
Edit report at http://bugs.php.net/bug.php?id=48551&edit=1 ID: 48551 Comment by: Reported by: hckurniawan at gmail dot com Summary: Unable to compile Status: Bogus Type: Bug Package: Compile Failure Operating System: Debian 5 PHP Version: 5.3.0RC3 New Comment: I've exactly the same problem with stable PHP 5.3.2. When i use snapshot, it takes lng time with just "Generating phar.php" and nothing else happened. Previous Comments: [2009-06-15 12:15:41] hckurniawan at gmail dot com Thank you Jani for confirming. I tried the snapshot, and it worked. [2009-06-15 11:55:41] j...@php.net Works for me. [2009-06-15 11:50:30] hckurniawan at gmail dot com I'm sorry, I was trying to test RC3 RELEASE (since you ARE calling for testers)! I didn't know I have to go test the snapshot too I took the time to test it. At least you can take the time to confirm (or not-confirm) the bug. [2009-06-15 08:38:55] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-06-14 23:56:50] hckurniawan at gmail dot com BTW it compile with the same configuration for PHP5.3RC2 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48551 -- Edit this bug report at http://bugs.php.net/bug.php?id=48551&edit=1
Bug #46885 [Csd]: pass by reference does not return object created in function
Edit report at http://bugs.php.net/bug.php?id=46885&edit=1
ID: 46885
User updated by: Chowarmaan at gmail dot com
Reported by: Chowarmaan at gmail dot com
Summary: pass by reference does not return object created in
function
Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: *
PHP Version: 5.2.8
New Comment:
Can not duplicate at this time with 5.2.13.
Previous Comments:
[2008-12-18 15:28:59] Chowarmaan at gmail dot com
I retried this as you showed, and then again in my code sample. I can
not reduplicate this problem.
I have been using the 5.2.8 since it came out as it is on my development
machine, and the only PHP on that machine. I confirmed this with the
first test and this test using the php -v and phpinfo();
Originally I noticed the problem using Zend 5.5.1, but I can not
reduplicate the problem there either.
[2008-12-18 14:26:00] j...@php.net
Are you really using PHP 5.2.8? Because this works just fine for me with
both styles. Here's my simplified script:
set('Testing Complete');
}
}
class tst2
{
public $var;
public function set($s)
{
$this->var = $s;
}
}
$t = new tst;
$t->get($resp, 100);
var_dump($resp->var);
$t->get(&$resp, 100);
var_dump($resp->var);
?>
And output:
# php -dallow_call_time_pass_reference=on t.php
string(16) "Testing Complete"
string(16) "Testing Complete"
# php -dallow_call_time_pass_reference=off t.php
Warning: Call-time pass-by-reference has been deprecated in t.php on
line 25
string(16) "Testing Complete"
string(16) "Testing Complete"
[2008-12-17 23:14:39] Chowarmaan at gmail dot com
Both lines were added to show what works and what does not. The first
call is the desired call by the program and what I can see in the PHP
manual. However, $Response does not become an object of TEST_CLASS2
when the GetResponse function ends.
The second call, &$Response does maintain the TEST_CLASS2 object type.
The second line should not be in the script, it is just there to
illustrate the problem. The first call to GetResponse() is the correct
call by the language syntax, but it has the bug.
[2008-12-17 02:44:50] j...@php.net
How about you comment out the latter call and let the script work
like it does?
[2008-12-16 21:26:23] Chowarmaan at gmail dot com
Description:
Calling a function in a class that accepts a variable by reference, then
checks the variable and creates an object for it will not allow the
object to be returned outside of the function.
Reproduce code:
---
SetText_('Testing Complete');
return TRUE;
}
}
class TEST_CLASS2
{
public $Variable;
public function SetText_($s)
{
$this->Variable = $s;
}
}
$Test = new TEST_CLASS();
$Test->GetResponse($Response, 100); // Fails
$Test->GetResponse(&$Response, 100); // Works
echo $Response->Variable . "\n";
?>
Expected result:
$Response should be of type TEST_CLASS2 and the echo should return the
text:
Testing Complete
Actual result:
--
$Response is a NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=46885&edit=1
Bug #51086 [Csd]: will not work with libdb4.8
Edit report at http://bugs.php.net/bug.php?id=51086&edit=1 ID: 51086 Updated by: s...@php.net Reported by: seanius at debian dot org Summary: will not work with libdb4.8 Status: Closed Type: Bug Package: DBM/DBA related Operating System: * PHP Version: 5.3, 6 (2010-02-19) Assigned To: sixd New Comment: That seems restrictive, given that normal functionality should be fine with BDB <= 4.8.26. Previous Comments: [2010-03-06 11:46:36] seanius at debian dot org Just a thought: what about leaving this open until oracle releases a new libdb, and then committing a second patch that refuses to accept db4.8 < the fixed version via config.m4? either way, thanks for looking at this. [2010-03-05 07:54:17] s...@php.net The next patchset of Berkeley DB 4.8 will possibly have the root cause fixed and the undefined behavior that DBA was depending on reverted. In the meantime I've merged a fix and a workaround to PHP 5.2.14-dev, PHP 5.2.3-dev and PHP 6.0. Note: now when using Berkely DB 4.8 prior or equal to 4.8.26, the workaround causes a message regarding meta data to be suppressed when opening the database. This causes a diff in a few cases where that message was previously displayed in DB 4.7, but prevents the message incorrectly displaying in all other tests. [2010-03-05 07:45:30] s...@php.net Automatic comment from SVN on behalf of sixd Revision: http://svn.php.net/viewvc/?view=revision&revision=295847 Log: Fixed bug #51086 (DBA DB4 doesn't work with Berkeley DB 4.8) [2010-03-02 17:12:03] s...@php.net The Berkeley DB developers are reviewing this. [2010-02-19 09:05:25] seanius at debian dot org -Summary: will not build/work with libdb4.8 +Summary: will not work with libdb4.8 -Operating System: Debian (and others) +Operating System: * -PHP Version: 5.3.1 +PHP Version: 5.3, 6 (2010-02-19 heh, seems we're stepping on each other's toes now. i'll set the stuff back that i just clobbered, and promise to be quiet for a few hours :) actually it won't build correctly against db4.8. i had to modify the snapshot to link against db4.8, as otherwise you see http://bugs.php.net/bug.php?id=51062 , though apparently that's a bogus issue, hrm... :) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51086 -- Edit this bug report at http://bugs.php.net/bug.php?id=51086&edit=1
Bug #51240 [Bgs]: date / mktime gives different dates for same parameters
Edit report at http://bugs.php.net/bug.php?id=51240&edit=1
ID: 51240
User updated by: w-pfeiffer-tue at gmx dot de
Reported by: w-pfeiffer-tue at gmx dot de
Summary: date / mktime gives different dates for same
parameters
Status: Bogus
Type: Bug
Package: Date/time related
Operating System: windows xp sp3
PHP Version: 5.2.13
New Comment:
thanks. :-)
Previous Comments:
[2010-03-08 19:46:30] der...@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
09 starts with 0, which is the start of an octal number. Octal number 09
is invalid so turned into 0.
[2010-03-08 19:25:39] w-pfeiffer-tue at gmx dot de
Description:
the date / mktime gives different dates although the parameters have the
same value
Test script:
---
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
Expected result:
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
Actual result:
--
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
--
Edit this bug report at http://bugs.php.net/bug.php?id=51240&edit=1
Bug #51183 [Com]: ext/date/php_date.c fails to compile with Sun Studio and PHP 5.2.13
Edit report at http://bugs.php.net/bug.php?id=51183&edit=1
ID: 51183
Comment by:
Reported by: markus dot schiegl at lbbw dot de
Summary: ext/date/php_date.c fails to compile with Sun Studio
and PHP 5.2.13
Status: Assigned
Type: Bug
Package: Compile Failure
Operating System: Solaris 10 (Sparc)
PHP Version: 5.2.13
Assigned To: derick
New Comment:
This also affects Solaris 10 x86 with Sun Studio compiler.
Previous Comments:
[2010-03-05 11:42:12] markus dot schiegl at lbbw dot de
Jose Marcio, thanks for the patch. Compiles and works fine now!
[2010-03-02 13:25:22] markus dot schiegl at lbbw dot de
Description:
PHP 5.2.13 doesn't compile with Sun Studio compiler on Solaris 10 Sparc.
Configure works fine (as in 5.2.12), Make fails on ext/date/php_date.c
file with:
/bin/sh /opt/build/php/php-5.2.13/libtool --silent --preserve-dup-deps
--mode=compile cc -Iext/date/lib -Iext/date/
-I/opt/build/php/php-5.2.13/ext/d
ate/ -DPHP_ATOM_INC -I/opt/build/php/php-5.2.13/include
-I/opt/build/php/php-5.2.13/main -I/opt/build/php/php-5.2.13
-I/opt/build/php/php-5.2.13/ext/
date/lib -I/opt/build/php/ext/libxml2/include/libxml2 -I/usr/sfw/include
-I/opt/build/php/ext/curl/include -I/opt/build/php/ext/jpeg/include
-I/opt/b
uild/php/ext/freetype2/include
-I/opt/build/php/ext/freetype2/include/freetype2
-I/opt/build/php/ext/gettext/include -I/opt/build/php/ext/libiconv/in
clude -I/opt/build/php/php-5.2.13/ext/mbstring/oniguruma
-I/opt/build/php/php-5.2.13/ext/mbstring/libmbfl
-I/opt/build/php/php-5.2.13/ext/mbstring/li
bmbfl/mbfl -I/opt/build/php/ext/libmcrypt/include
-I/opt/build/php/ext/freetds/include -I/opt/build/php/ext/mysql/include
-I/opt/build/php/ext/instan
tclient/sdk/include -I/opt/build/php/ext/tidy/include
-I/opt/build/php/ext/xmlrpc-epi/include
-I/opt/build/php/ext/libxslt/include -I/opt/build/php/p
hp-5.2.13/TSRM -I/opt/build/php/php-5.2.13/Zend
-I/opt/build/php/php/ext/libiconv/include
-I/opt/build/php/php/ext/gettext/include -D_POSIX_PTHREAD_
SEMANTICS -I/opt/build/php/ext/libiconv/include -O -xs -xstrconst
-zlazyload -xmemalign=8s -c
/opt/build/php/php-5.2.13/ext/date/php_date.c -o ext/
date/php_date.lo
"/opt/build/php/php-5.2.13/ext/date/php_date.c", line 38: warning: no
explicit type given
"/opt/build/php/php-5.2.13/ext/date/php_date.c", line 38: syntax error
before or at: long
cc: acomp failed for /opt/build/php/php-5.2.13/ext/date/php_date.c
*** Error code 1
make: Fatal error: Command failed for target `ext/date/php_date.lo'
A diff between 5.2.12 and 5.2.13 shows the culprit (php_date_llabs vs.
llabs and/or ifndef HAVE_LLABS, because of bug 50266 and bug 50930)
@@ -30,14 +30,12 @@
#include "lib/timelib.h"
#include
-#ifndef HAVE_LLABS
-# ifdef PHP_WIN32
-static __inline __int64 llabs( __int64 i ) { return i >= 0? i: -i; }
-# elif defined(__GNUC__) && __GNUC__ < 3
-static __inline __int64_t llabs( __int64_t i ) { return i >= 0 ? i :
-i; }
-# elif defined(NETWARE) && defined(__MWERKS__)
-static __inline long long llabs( long long i ) { return i >= 0 ? i :
-i; }
-# endif
+#ifdef PHP_WIN32
+static __inline __int64 php_date_llabs( __int64 i ) { return i >= 0? i:
-i; }
+#elif defined(__GNUC__) && __GNUC__ < 3
+static __inline __int64_t php_date_llabs( __int64_t i ) { return i >= 0
? i : -i; }
+#else
+static __inline long long php_date_llabs( long long i ) { return i >= 0
? i : -i; }
#endif
/* {{{ arginfo */
Expected result:
successful compile
Actual result:
--
compile aborts with error
--
Edit this bug report at http://bugs.php.net/bug.php?id=51183&edit=1
Bug #51240 [Opn->Bgs]: date / mktime gives different dates for same parameters
Edit report at http://bugs.php.net/bug.php?id=51240&edit=1
ID: 51240
Updated by: der...@php.net
Reported by: w-pfeiffer-tue at gmx dot de
Summary: date / mktime gives different dates for same
parameters
-Status: Open
+Status: Bogus
Type: Bug
Package: Date/time related
Operating System: windows xp sp3
PHP Version: 5.2.13
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
09 starts with 0, which is the start of an octal number. Octal number 09
is invalid so turned into 0.
Previous Comments:
[2010-03-08 19:25:39] w-pfeiffer-tue at gmx dot de
Description:
the date / mktime gives different dates although the parameters have the
same value
Test script:
---
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
Expected result:
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
Actual result:
--
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
--
Edit this bug report at http://bugs.php.net/bug.php?id=51240&edit=1
[PHP-BUG] Bug #51240 [NEW]: date / mktime gives different dates for same parameters
From:
Operating system: windows xp sp3
PHP version: 5.2.13
Package: Date/time related
Bug Type: Bug
Bug description:date / mktime gives different dates for same parameters
Description:
the date / mktime gives different dates although the parameters have the
same value
Test script:
---
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
Expected result:
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
Actual result:
--
php -r "echo date('d.m.Y', mktime(0,0,0, 3,9,2010));"
> 09.03.2010
php -r "echo date('d.m.Y', mktime(0,0,0, 3, 09,2010));"
> 28.02.2010
--
Edit bug report at http://bugs.php.net/bug.php?id=51240&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51240&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51240&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51240&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51240&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51240&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51240&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51240&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51240&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51240&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51240&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51240&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51240&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51240&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51240&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51240&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51240&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51240&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51240&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51240&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51240&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51240&r=mysqlcfg
[PHP-BUG] Bug #51239 [NEW]: ldap_modify fails to delete attribute and change other attribute
From:
Operating system: Solaris
PHP version: 5.2.13
Package: LDAP related
Bug Type: Bug
Bug description:ldap_modify fails to delete attribute and change other attribute
Description:
ldap_modify fails when deleting attribute AND changing another attribute at
the same time. The error returned is "Success", and the modification is not
done.
appropriate LDAP values:
dn: uid=something,o=jes.com
mailForwardingAddress: f...@bar.com
mailDeliveryOption: autoreply
mailDeliveryOption: forward
...
ldap_modify is called with:
$modifs = array('mailforwardingaddress' => array(), 'maildeliveryoption' =>
array('autoreply', 'mailbox'));
IMPORTANT NOTE:
doing these 2 separately works, but doing them at the same time does not
work.
when it fails, ldap_modify returns FALSE, ldap_error() will return
"Success". Modifications are not done.
Server is a SUN Solaris, LDAP server is a JES. trying this with ldapmodify
command works.
--
Edit bug report at http://bugs.php.net/bug.php?id=51239&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51239&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51239&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51239&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51239&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51239&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51239&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51239&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51239&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51239&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51239&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51239&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51239&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51239&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51239&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51239&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51239&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51239&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51239&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51239&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51239&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51239&r=mysqlcfg
[PHP-BUG] Bug #51238 [NEW]: Segfault with preg_replace
From:
Operating system: all
PHP version: 5.3.2
Package: PCRE related
Bug Type: Bug
Bug description:Segfault with preg_replace
Description:
You can make a segfault with a particular regexp (that appears to be used
in Mysqli, or in Zend Framework at least).
This bug appears on :
PHP 5.3.2
PHP 5.2.10
PHP 4
with internal pcrelib of course.
NOTE:
I cannot reproduce this bug everytime. Once in a while, the segfault is not
triggered (weird ...).
NOTE 2:
Same bug (segfault) with preg_match or preg_match_all
Test script:
---
..., ecode=0x8dcd78e "_",
mstart=0xb7508c64 "'", 'a' ..., offset_top=4,
md=0xbfdced54, ims=0, eptrb=0x0, flags=0, rdepth=20133) at
/usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:454
454 {
#0 match (eptr=0xb750b3b7 'a' ..., ecode=0x8dcd78e "_",
mstart=0xb7508c64 "'", 'a' ..., offset_top=4,
md=0xbfdced54, ims=0, eptrb=0x0, flags=0, rdepth=20133) at
/usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:454
#1 0x080ebc9a in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1533
#2 0x080e78f4 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:734
#3 0x080ebc9a in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1533
#4 0x080e78f4 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:734
#5 0x080ebc9a in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1533
#6 0x080e78f4 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:734
[ ... snip because backtrace shows what appears to be a loop ... ]
#20131 0x080ebc9a in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1533
#20132 0x080e78f4 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:734
#20133 0x080e7df8 in match (eptr=Variable "eptr" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:1395
#20134 0x080f235a in php_pcre_exec (argument_re=0x8dcd760,
extra_data=0xbfdceef4, subject=0xb7508c64 "'", 'a' ...,
length=50001, start_offset=0, options=Variable "options" is not
available.
) at /usr/src/php/php-5.3.2/ext/pcre/pcrelib/pcre_exec.c:5641
#20135 0x080f62a9 in php_pcre_replace_impl (pce=0x8dcd8f8,
subject=0xb7508c64 "'", 'a' ..., subject_len=50001,
replace_val=0xb74fad54, is_callable_replace=0, result_len=0xbfdcf088,
limit=-1, replace_count=0xbfdcf074)
at /usr/src/php/php-5.3.2/ext/pcre/php_pcre.c:1040
#20136 0x080f6fc5 in php_pcre_replace (regex=0xb74fb284
"/'('|{2}|[^'])*'/", regex_len=21,
subject=0xb7508c64 "'", 'a' ..., subject_len=50001,
replace_val=0xb74fad54, is_callable_replace=0, result_len=0xbfdcf088,
limit=-1, replace_count=0xbfdcf074) at
/usr/src/php/php-5.3.2/ext/pcre/php_pcre.c:950
#20137 0x080f7542 in php_replace_in_subject (regex=0xb74fad70,
replace=Variable "replace" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/php_pcre.c:1267
#20138 0x080f7bb6 in preg_replace_impl (ht=Variable "ht" is not available.
) at /usr/src/php/php-5.3.2/ext/pcre/php_pcre.c:1365
#20139 0x084b3c81 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb7470028) at zend_vm_execute.h:313
#20140 0x084acf86 in execute (op_array=0xb74fb1ec) at
zend_vm_execute.h:104
#20141 0x08484fe6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php/php-5.3.2/Zend/zend.c:1194
#20142 0x0842c036 in php_execute_script (primary_file=0xbfdd16f4) at
/usr/src/php/php-5.3.2/main/main.c:2260
#20143 0x085157e8 in main (argc=2, argv=0xbfdd1854) at
/usr/src/php/php-5.3.2/sapi/cli/php_cli.c:1192
--
Edit bug report at http://bugs.php.net/bug.php?id=51238&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51238&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51238&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51238&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51238&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51238&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51238&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51238&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51238&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51238&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51238&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51238&r=notwrong
Not enough in
[PHP-BUG] Bug #51237 [NEW]: milter SAPI crash on startup
From:
Operating system: Linux
PHP version: 5.3.2
Package: Reproducible crash
Bug Type: Bug
Bug description:milter SAPI crash on startup
Description:
./configure --with-milter
./php-milter
Segmentation fault
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
virtual_fopen (path=0x0, mode=0x83e3227 "rb", tsrm_ls=0x8644018)
at /home/igmar/php-5.3.2/TSRM/tsrm_virtual_cwd.c:1299
1299if (path[0] == '\0') { /* Fail to open empty path */
(gdb) bt
#0 virtual_fopen (path=0x0, mode=0x83e3227 "rb", tsrm_ls=0x8644018)
at /home/igmar/php-5.3.2/TSRM/tsrm_virtual_cwd.c:1299
#1 0x0838ca92 in mlfi_init (argc=1, argv=0xbfffe9c4)
at /home/igmar/php-5.3.2/sapi/milter/php_milter.c:131
#2 main (argc=1, argv=0xbfffe9c4)
at /home/igmar/php-5.3.2/sapi/milter/php_milter.c:1160
--
Edit bug report at http://bugs.php.net/bug.php?id=51237&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51237&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51237&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51237&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51237&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51237&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51237&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51237&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51237&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51237&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51237&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51237&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51237&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51237&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51237&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51237&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51237&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51237&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51237&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51237&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51237&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51237&r=mysqlcfg
Bug #50613 [Com]: Expected warnings/notices not outputed by PHP on simple array access.
Edit report at http://bugs.php.net/bug.php?id=50613&edit=1 ID: 50613 Comment by: Reported by: felix at amerimerchant dot com Summary: Expected warnings/notices not outputed by PHP on simple array access. Status: Open Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.1 New Comment: My apologies; I meant "5.4.0 or 6.0.0" obviously, and my email address is at the .com TLD (not .net). Insufficient morning caffeination, clearly. Previous Comments: [2010-03-08 15:21:59] rbetta at amerimerchant dot net I suppose the resource type might be affected as well; it did not occur to me to test it at the time. I am not certain that a new notice would constitute a BC break; production servers should never have display_errors on, and any code that would actually generate the new notices or warnings would already be broken by the very fact that it is attempting to read scalar values as arrays (therefore, subtle but as-yet undiscovered logical bugs in userland code may be made known by these new notices or warnings). I suppose custom error handler routines could react strongly to notices, though. Webpages suddenly disappearing with "Sorry, there has been an internal error" messages generated by their core frameworks might be a somewhat unpleasant experience. If this does qualify as a BC break under the Zend engine maintainers' policies, would 3.4 or 6.0 be the first candidate for a fix? [2010-03-06 17:23:56] ar...@php.net The following patch has been added/updated: Patch Name: scalar-array-read.50613.HEAD.patch Revision: 1267892636 URL: http://bugs.php.net/patch-display.php?bug=50613&patch=scalar-array-read.50613.HEAD.patch&revision=1267892636&display=1 [2010-03-06 17:23:01] ar...@php.net I think there is a bug here as an error is raised when writing to ints and floats as arrays but not when reading from them. The fix is trivial however it's a BC break. This exists in at least 5.2, 5.3 and HEAD. [2010-03-04 16:31:21] ahar...@php.net There was an option in the old bug tracker to flick it back to Open. I'm not sure if the new and improved bug tracker does the same. Anyway, reopening. [2010-03-04 16:13:58] rbetta at amerimerchant dot com Is there any further step we need to perform to get this out of the "No Feedback" status? Felix's 2010-01-02 00:08 UTC comment answered Jani's question, but we did not see any option for updating the bug status out of the feedback stage ourselves. Is there a manual status change required by Jani, or did we miss an option on the bug reporting form? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50613 -- Edit this bug report at http://bugs.php.net/bug.php?id=50613&edit=1
Bug #50613 [Com]: Expected warnings/notices not outputed by PHP on simple array access.
Edit report at http://bugs.php.net/bug.php?id=50613&edit=1 ID: 50613 Comment by: Reported by: felix at amerimerchant dot com Summary: Expected warnings/notices not outputed by PHP on simple array access. Status: Open Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.1 New Comment: I suppose the resource type might be affected as well; it did not occur to me to test it at the time. I am not certain that a new notice would constitute a BC break; production servers should never have display_errors on, and any code that would actually generate the new notices or warnings would already be broken by the very fact that it is attempting to read scalar values as arrays (therefore, subtle but as-yet undiscovered logical bugs in userland code may be made known by these new notices or warnings). I suppose custom error handler routines could react strongly to notices, though. Webpages suddenly disappearing with "Sorry, there has been an internal error" messages generated by their core frameworks might be a somewhat unpleasant experience. If this does qualify as a BC break under the Zend engine maintainers' policies, would 3.4 or 6.0 be the first candidate for a fix? Previous Comments: [2010-03-06 17:23:56] ar...@php.net The following patch has been added/updated: Patch Name: scalar-array-read.50613.HEAD.patch Revision: 1267892636 URL: http://bugs.php.net/patch-display.php?bug=50613&patch=scalar-array-read.50613.HEAD.patch&revision=1267892636&display=1 [2010-03-06 17:23:01] ar...@php.net I think there is a bug here as an error is raised when writing to ints and floats as arrays but not when reading from them. The fix is trivial however it's a BC break. This exists in at least 5.2, 5.3 and HEAD. [2010-03-04 16:31:21] ahar...@php.net There was an option in the old bug tracker to flick it back to Open. I'm not sure if the new and improved bug tracker does the same. Anyway, reopening. [2010-03-04 16:13:58] rbetta at amerimerchant dot com Is there any further step we need to perform to get this out of the "No Feedback" status? Felix's 2010-01-02 00:08 UTC comment answered Jani's question, but we did not see any option for updating the bug status out of the feedback stage ourselves. Is there a manual status change required by Jani, or did we miss an option on the bug reporting form? [2010-01-07 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". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50613 -- Edit this bug report at http://bugs.php.net/bug.php?id=50613&edit=1
Bug #51233 [Bgs]: Wrong results with float arithmetics
Edit report at http://bugs.php.net/bug.php?id=51233&edit=1 ID: 51233 Updated by: paj...@php.net Reported by: daniel dot seif at castex dot de Summary: Wrong results with float arithmetics Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Multiple PHP Version: 5.3.2 New Comment: Please carefully read the link posted by Johannes. 138.95 can end to be represented as 138.4. The rest becomes obvious then. Previous Comments: [2010-03-08 13:33:35] ahar...@php.net Due to their limited precision, you shouldn't use floating-point values for currency calculations. Ever. This is well established best practice across a variety of programming languages. You should use either integers to represent the value in cents (or whatever your smallest currency unit is) or an arbitrary precision library such as BCMath. Please note that this bug tracker isn't a support forum, and further questions on this would be better directed to a Web forum like Stack Overflow, the PHP general mailing list, a newsgroup, or IRC. [2010-03-08 13:20:45] daniel dot seif at castex dot de Thank you for the quick reply. The string representation is not the problem here, though. We are calculating with monetary data and converting from one currency to another. Imagine a two products, worth 138.00 and 0.95 with the need to keep only 2 decimal digits: $totalPrice = floor((138.00 + 0.95) * 100) / 100; The result should be 138.95, but PHP returns 138.94 ... I consider this to be a problem on a worse level than just 'bogus' Best Regards [2010-03-08 12:12:03] johan...@php.net Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. [2010-03-08 11:57:15] daniel dot seif at castex dot de Description: When calculating with and rounding float values, the result of the calculation is wrong. This bug seems to affect multiple versions of php. I have tested it with PHP 5.3.2 (Fedora 12), PHP 5.2.6 (Red Hat), PHP 5.3.0 (Windows XP). Test script: --- echo floor(138.95 * 100), "\n"; echo floor(141.95 * 100), "\n"; echo floor(142.95 * 100), "\n"; echo intval(142.95 * 100), "\n"; echo (int)(138.95 * 100); Expected result: 13895 14195 14295 14295 13895 Actual result: -- 13894 14194 14294 14294 13894 -- Edit this bug report at http://bugs.php.net/bug.php?id=51233&edit=1
Bug #51235 [Opn->Fbk]: getElementsByTagName always return an empty list
Edit report at http://bugs.php.net/bug.php?id=51235&edit=1
ID: 51235
Updated by: rricha...@php.net
Reported by: marsala dot marco at fastwebnet dot it
Summary: getElementsByTagName always return an empty list
-Status: Open
+Status: Feedback
Type:Bug
Package: DOM XML related
PHP Version: 5.3.2
New Comment:
You sure no errors or warnings being thrown that aren't being shown? The
example
works fine for me using 5.3.2 and latests libxml2.
Previous Comments:
[2010-03-08 13:27:47] marsala dot marco at fastwebnet dot it
Description:
$document = new DOMDocument()->load(...);
$document->getElementsByTagName() works (returns list
with one element).
getElementsByTagName() always return an empty
list. Examples on notes and on the web (some examples claimed to be
working are prior the 5.3.2) are all not working.
Tested on LAMP server PHP 5.2.8 AND on XAMPPLite WAMP PHP 5.3.1, both
not working.
Test script:
---
$doc = new DOMDocument();
$doc->load('__xml/faq.xml');
$faqs = $doc->getElementsByTagName("faq");
echo $faqs->length; // always 0
__xml/faq.xml is:
domanda1
risposta1
domanda2
risposta2
domanda3
risposta3
--
Edit this bug report at http://bugs.php.net/bug.php?id=51235&edit=1
Bug #51213 [Opn->Csd]: pdo_mssql is trimming value of the money column
Edit report at http://bugs.php.net/bug.php?id=51213&edit=1
ID: 51213
Updated by: il...@php.net
Reported by: alexr at oplot dot com
Summary: pdo_mssql is trimming value of the money column
-Status: Open
+Status: Closed
Type: Bug
Package: PDO related
Operating System: Windows
PHP Version: 5.2.13
Assigned To: iliaa
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-03-08 13:39:46] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=295958
Log: Fixed bug #51213 (pdo_mssql is trimming value of the money column).
[2010-03-05 10:36:45] alexr at oplot dot com
Description:
Money column is wrongly converting to the char column and this cause
that value is rounding to the 2 digits after delimiter (dot).
Test script:
---
$dsn = 'mssql:dbname=DBNAME;host=HOSTNAME';
$user = 'USERNAME';
$password='PASSWORD';
$dbh = new PDO($dsn, $user, $password);
$sth = $dbh->query ('create table #tmp(col money)');
$sth = $dbh->query ('insert into #tmp(col) values(-0.1234)');
$sth = $dbh->query ('insert into #tmp(col) values(0.1234)');
$sth = $dbh->prepare('select * from #tmp');
$sth->execute();
$r = $sth->fetchAll(2);
print_r($r);
Expected result:
Array
(
[0] => Array
(
[col] => -0.1234
)
[1] => Array
(
[col] => 0.1234
)
)
Actual result:
--
Array
(
[0] => Array
(
[col] => -0.12
)
[1] => Array
(
[col] => 0.12
)
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51213&edit=1
Bug #51233 [Bgs]: Wrong results with float arithmetics
Edit report at http://bugs.php.net/bug.php?id=51233&edit=1 ID: 51233 Updated by: ahar...@php.net Reported by: daniel dot seif at castex dot de Summary: Wrong results with float arithmetics Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Multiple PHP Version: 5.3.2 New Comment: Due to their limited precision, you shouldn't use floating-point values for currency calculations. Ever. This is well established best practice across a variety of programming languages. You should use either integers to represent the value in cents (or whatever your smallest currency unit is) or an arbitrary precision library such as BCMath. Please note that this bug tracker isn't a support forum, and further questions on this would be better directed to a Web forum like Stack Overflow, the PHP general mailing list, a newsgroup, or IRC. Previous Comments: [2010-03-08 13:20:45] daniel dot seif at castex dot de Thank you for the quick reply. The string representation is not the problem here, though. We are calculating with monetary data and converting from one currency to another. Imagine a two products, worth 138.00 and 0.95 with the need to keep only 2 decimal digits: $totalPrice = floor((138.00 + 0.95) * 100) / 100; The result should be 138.95, but PHP returns 138.94 ... I consider this to be a problem on a worse level than just 'bogus' Best Regards [2010-03-08 12:12:03] johan...@php.net Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. [2010-03-08 11:57:15] daniel dot seif at castex dot de Description: When calculating with and rounding float values, the result of the calculation is wrong. This bug seems to affect multiple versions of php. I have tested it with PHP 5.3.2 (Fedora 12), PHP 5.2.6 (Red Hat), PHP 5.3.0 (Windows XP). Test script: --- echo floor(138.95 * 100), "\n"; echo floor(141.95 * 100), "\n"; echo floor(142.95 * 100), "\n"; echo intval(142.95 * 100), "\n"; echo (int)(138.95 * 100); Expected result: 13895 14195 14295 14295 13895 Actual result: -- 13894 14194 14294 14294 13894 -- Edit this bug report at http://bugs.php.net/bug.php?id=51233&edit=1
[PHP-BUG] Bug #51235 [NEW]: getElementsByTagName always return an empty list
From:
Operating system:
PHP version: 5.3.2
Package: DOM XML related
Bug Type: Bug
Bug description:getElementsByTagName always return an empty list
Description:
$document = new DOMDocument()->load(...);
$document->getElementsByTagName() works (returns list
with one element).
getElementsByTagName() always return an empty list.
Examples on notes and on the web (some examples claimed to be working are
prior the 5.3.2) are all not working.
Tested on LAMP server PHP 5.2.8 AND on XAMPPLite WAMP PHP 5.3.1, both not
working.
Test script:
---
$doc = new DOMDocument();
$doc->load('__xml/faq.xml');
$faqs = $doc->getElementsByTagName("faq");
echo $faqs->length; // always 0
__xml/faq.xml is:
domanda1
risposta1
domanda2
risposta2
domanda3
risposta3
--
Edit bug report at http://bugs.php.net/bug.php?id=51235&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51235&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51235&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51235&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51235&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51235&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51235&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51235&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51235&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51235&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51235&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51235&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51235&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51235&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51235&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51235&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51235&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51235&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51235&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51235&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51235&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51235&r=mysqlcfg
Bug #51233 [Bgs]: Wrong results with float arithmetics
Edit report at http://bugs.php.net/bug.php?id=51233&edit=1 ID: 51233 User updated by: daniel dot seif at castex dot de Reported by: daniel dot seif at castex dot de Summary: Wrong results with float arithmetics Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Multiple PHP Version: 5.3.2 New Comment: Thank you for the quick reply. The string representation is not the problem here, though. We are calculating with monetary data and converting from one currency to another. Imagine a two products, worth 138.00 and 0.95 with the need to keep only 2 decimal digits: $totalPrice = floor((138.00 + 0.95) * 100) / 100; The result should be 138.95, but PHP returns 138.94 ... I consider this to be a problem on a worse level than just 'bogus' Best Regards Previous Comments: [2010-03-08 12:12:03] johan...@php.net Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. [2010-03-08 11:57:15] daniel dot seif at castex dot de Description: When calculating with and rounding float values, the result of the calculation is wrong. This bug seems to affect multiple versions of php. I have tested it with PHP 5.3.2 (Fedora 12), PHP 5.2.6 (Red Hat), PHP 5.3.0 (Windows XP). Test script: --- echo floor(138.95 * 100), "\n"; echo floor(141.95 * 100), "\n"; echo floor(142.95 * 100), "\n"; echo intval(142.95 * 100), "\n"; echo (int)(138.95 * 100); Expected result: 13895 14195 14295 14295 13895 Actual result: -- 13894 14194 14294 14294 13894 -- Edit this bug report at http://bugs.php.net/bug.php?id=51233&edit=1
Bug #51234 [Opn->Bgs]: echo $dt->date doesn't work unless preceeded by print_r($dt)
Edit report at http://bugs.php.net/bug.php?id=51234&edit=1 ID: 51234 Updated by: der...@php.net Reported by: php at mpodr dot com Summary: echo $dt->date doesn't work unless preceeded by print_r($dt) -Status: Open +Status: Bogus Type: Bug Package: Date/time related Operating System: CentOS 5.4 PHP Version: 5.3SVN-2010-03-08 (SVN) New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Duplicate of #49382. Previous Comments: [2010-03-08 12:28:17] php at mpodr dot com Description: This example was taken straight from the DateTime::createFromFormat page at: http://www.php.net/manual/en/datetime.createfromformat.php After performing a DateTime::createFromFormat, the variable assigned doesn't seem to work. HOWEVER, the variable assigned DOES seem to work after being used in a print_r function. Please look at the test script and output. What am I doing wrong? Condensed Code Snippet: === $format = 'Y-m-d'; $dt = DateTime::createFromFormat($format, '2009-02-03'); echo "Format: $format; " . $dt->date . " (Should print \"2009-02-03 [time]\")"; print_r($dt); echo "Format: $format; " . $dt->date . " (Should print \"2009-02-03 [time]\")"; Output: === Format: Y-m-d; (Should print "2009-02-03 [time]") DateTime Object ( [date] => 2009-02-03 06:23:24 [timezone_type] => 3 [timezone] => America/New_York ) Format: Y-m-d; 2009-02-03 06:23:24 (Should print "2009-02-03 [time]") Test script: --- Code Snippet: = $format = 'Y-m-d'; $dt = DateTime::createFromFormat($format, '2009-02-03'); echo "Format: $format; " . $dt->date . " (Should print \"2009-02-03 [time]\")"; Output: === Format: Y-m-d; (Should print "2009-02-03 [time]") DateTime Object ( [date] => 2009-02-03 06:23:24 [timezone_type] => 3 [timezone] => America/New_York ) Format: Y-m-d; 2009-02-03 06:23:24 (Should print "2009-02-03 [time]") Expected result: Format: Y-m-d; 2009-02-03 06:23:24 (Should print "2009-02-03 [time]") Actual result: -- Format: Y-m-d; (Should print "2009-02-03 [time]") -- Edit this bug report at http://bugs.php.net/bug.php?id=51234&edit=1
[PHP-BUG] Bug #51234 [NEW]: echo $dt->date doesn't work unless preceeded by print_r($dt)
From: Operating system: CentOS 5.4 PHP version: 5.3SVN-2010-03-08 (SVN) Package: Date/time related Bug Type: Bug Bug description:echo $dt->date doesn't work unless preceeded by print_r($dt) Description: This example was taken straight from the DateTime::createFromFormat page at: http://www.php.net/manual/en/datetime.createfromformat.php After performing a DateTime::createFromFormat, the variable assigned doesn't seem to work. HOWEVER, the variable assigned DOES seem to work after being used in a print_r function. Please look at the test script and output. What am I doing wrong? Condensed Code Snippet: === $format = 'Y-m-d'; $dt = DateTime::createFromFormat($format, '2009-02-03'); echo "Format: $format; " . $dt->date . " (Should print \"2009-02-03 [time]\")"; print_r($dt); echo "Format: $format; " . $dt->date . " (Should print \"2009-02-03 [time]\")"; Output: === Format: Y-m-d; (Should print "2009-02-03 [time]") DateTime Object ( [date] => 2009-02-03 06:23:24 [timezone_type] => 3 [timezone] => America/New_York ) Format: Y-m-d; 2009-02-03 06:23:24 (Should print "2009-02-03 [time]") Test script: --- Code Snippet: = $format = 'Y-m-d'; $dt = DateTime::createFromFormat($format, '2009-02-03'); echo "Format: $format; " . $dt->date . " (Should print \"2009-02-03 [time]\")"; Output: === Format: Y-m-d; (Should print "2009-02-03 [time]") DateTime Object ( [date] => 2009-02-03 06:23:24 [timezone_type] => 3 [timezone] => America/New_York ) Format: Y-m-d; 2009-02-03 06:23:24 (Should print "2009-02-03 [time]") Expected result: Format: Y-m-d; 2009-02-03 06:23:24 (Should print "2009-02-03 [time]") Actual result: -- Format: Y-m-d; (Should print "2009-02-03 [time]") -- Edit bug report at http://bugs.php.net/bug.php?id=51234&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51234&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51234&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51234&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51234&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51234&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51234&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51234&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51234&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51234&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51234&r=support Expected behavior: http://bugs.php.net/fix.php?id=51234&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51234&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51234&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51234&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51234&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51234&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51234&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51234&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51234&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51234&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51234&r=mysqlcfg
Bug #51233 [Opn->Bgs]: Wrong results with float arithmetics
Edit report at http://bugs.php.net/bug.php?id=51233&edit=1 ID: 51233 Updated by: johan...@php.net Reported by: daniel dot seif at castex dot de Summary: Wrong results with float arithmetics -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Multiple PHP Version: 5.3.2 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2010-03-08 11:57:15] daniel dot seif at castex dot de Description: When calculating with and rounding float values, the result of the calculation is wrong. This bug seems to affect multiple versions of php. I have tested it with PHP 5.3.2 (Fedora 12), PHP 5.2.6 (Red Hat), PHP 5.3.0 (Windows XP). Test script: --- echo floor(138.95 * 100), "\n"; echo floor(141.95 * 100), "\n"; echo floor(142.95 * 100), "\n"; echo intval(142.95 * 100), "\n"; echo (int)(138.95 * 100); Expected result: 13895 14195 14295 14295 13895 Actual result: -- 13894 14194 14294 14294 13894 -- Edit this bug report at http://bugs.php.net/bug.php?id=51233&edit=1
[PHP-BUG] Bug #51233 [NEW]: Wrong results with float arithmetics
From: Operating system: Multiple PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Bug Bug description:Wrong results with float arithmetics Description: When calculating with and rounding float values, the result of the calculation is wrong. This bug seems to affect multiple versions of php. I have tested it with PHP 5.3.2 (Fedora 12), PHP 5.2.6 (Red Hat), PHP 5.3.0 (Windows XP). Test script: --- echo floor(138.95 * 100), "\n"; echo floor(141.95 * 100), "\n"; echo floor(142.95 * 100), "\n"; echo intval(142.95 * 100), "\n"; echo (int)(138.95 * 100); Expected result: 13895 14195 14295 14295 13895 Actual result: -- 13894 14194 14294 14294 13894 -- Edit bug report at http://bugs.php.net/bug.php?id=51233&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51233&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51233&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51233&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51233&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51233&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51233&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51233&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51233&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51233&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51233&r=support Expected behavior: http://bugs.php.net/fix.php?id=51233&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51233&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51233&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51233&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51233&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51233&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51233&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51233&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51233&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51233&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51233&r=mysqlcfg
Bug #50383 [Com]: Exceptions thrown in __call / __callStatic do not include file and line in trace
Edit report at http://bugs.php.net/bug.php?id=50383&edit=1
ID: 50383
Comment by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: Exceptions thrown in __call / __callStatic do not
include file and line in trace
Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: *
PHP Version: 5.*, 6
Assigned To: felipe
New Comment:
Any chance of the win32 snapshots being turned on again?
Previous Comments:
[2010-03-07 03:17:14] fel...@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.
[2010-03-07 03:17:13] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=295913
Log: - Fixed bug #50383 (Exceptions thrown in __call / __callStatic do
not include file and line in trace)
[2009-12-04 12:47:57] j...@php.net
Simple test that works in all branches:
ThrowException();
}
try {
thrower();
} catch(Exception $e) {
var_dump($e->getTrace());
}
?>
[2009-12-04 12:15:47] rquadl...@php.net
It seems that __call exhibits the same issue.
Further, for sub-classes which allow cascading of __call/__callStatic,
the stack doesn't show the file/line for those.
Outputs ...
Exception Object
(
[message:protected] => Missing static method
'StaticThrowException'.
[string:Exception:private] =>
[code:protected] => 0
[file:protected] => Z:\myClass.php
[line:protected] => 4
[trace:Exception:private] => Array
(
[0] => Array
(
[file] => Z:\mySubClass.php
[line] => 6
[function] => __callStatic
[class] => myClass
[type] => ::
[args] => Array
(
[0] => StaticThrowException
[1] => Array
(
)
)
)
[1] => Array
(
[function] => __callStatic
[class] => mySubClass
[type] => ::
[args] => Array
(
[0] => StaticThrowException
[1] => Array
(
)
)
)
[2] => Array
(
[file] => Z:\missingstatictrace3.php
[line] => 5
[function] => StaticThrowException
[class] => mySubClass
[type] => ::
[args] => Array
(
)
)
[3] => Array
(
[file] => Z:\missingstatictrace3.php
[line] => 9
[function] => staticThrower
[args] => Array
(
)
)
)
[previous:Exception:private] =>
)
[2009-12-04 11:32:44] RQuadling at GMail dot com
Description:
An exception thrown in a __callStatic() method does not store the file
name or the line number in the trace.
Reproduce code:
---
getTrace());
}
Expected result:
Array
(
[0] => Array
(
[file] => Z:\missingstatictrace.php
[line] => 4
[function] => __callStatic
[class] => myClass
[type] => ::
[args] => Array
(
[0] => ThrowException
[1] => Array
(
)
)
)
[1] => Array
(
[file] => Z:\missingstatictrace.php
[line] => 9
[function] => ThrowException
[class] => myClass
[type] => ::
[args] => Array
(
)
)
[2] => Array
(
[file] => Z:\missingstatictrace.php
[line] => 13
[functi
Bug #51232 [Opn->Fbk]: php does not function
Edit report at http://bugs.php.net/bug.php?id=51232&edit=1 ID: 51232 Updated by: paj...@php.net Reported by: jamone_95134 at yahoo dot com Summary: php does not function -Status: Open +Status: Feedback Type: Bug Package: Windows Installer Operating System: Windows XP PHP Version: 5.3.2 New Comment: do: php -n -v if it works, that means you are loading extensions with missing dependencies. Open your php.ini and verify which extension it loads. Previous Comments: [2010-03-08 11:03:13] jamone_95134 at yahoo dot com Description: After installation when I type: C:>php -version I get the error: "CLI has encountered a problem and needs to close. We are sorry for the inconvenience." I get this message 6 times before my cursor returns. More information on the error reveals: AppName: php.exe AppVer: 5.3.2.0 ModName: php5ts.dll ModVer: 5.3.2.0 Offset: 000e6d2c -- Edit this bug report at http://bugs.php.net/bug.php?id=51232&edit=1
[PHP-BUG] Bug #51232 [NEW]: php does not function
From: Operating system: Windows XP PHP version: 5.3.2 Package: Windows Installer Bug Type: Bug Bug description:php does not function Description: After installation when I type: C:>php -version I get the error: "CLI has encountered a problem and needs to close. We are sorry for the inconvenience." I get this message 6 times before my cursor returns. More information on the error reveals: AppName: php.exe AppVer: 5.3.2.0 ModName: php5ts.dll ModVer: 5.3.2.0 Offset: 000e6d2c -- Edit bug report at http://bugs.php.net/bug.php?id=51232&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51232&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51232&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51232&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51232&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51232&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51232&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51232&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51232&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51232&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51232&r=support Expected behavior: http://bugs.php.net/fix.php?id=51232&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51232&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51232&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51232&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51232&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51232&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51232&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51232&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51232&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51232&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51232&r=mysqlcfg
Bug #50559 [Com]: Clone is not implemented for DateInterval and DatePeriod
Edit report at http://bugs.php.net/bug.php?id=50559&edit=1
ID: 50559
Comment by:
Reported by: sr at emini dot dk
Summary: Clone is not implemented for DateInterval and
DatePeriod
Status: Assigned
Type: Bug
Package: Date/time related
Operating System: Fedora 10
PHP Version: 5.3.1
Assigned To: derick
New Comment:
Did you forget to attach the script?
Previous Comments:
[2010-03-07 20:24:53] der...@php.net
This patch causes issues. If I try the attached script I end up in an
infinite loop.
[2010-01-27 13:47:00] yoarvi at gmail dot com
The following patch implements the logic to clone DatePeriod and
DateInterval objects and also includes a test case:
Index: ext/date/php_date.c
===
--- ext/date/php_date.c (revision 293574)
+++ ext/date/php_date.c (working copy)
@@ -2213,7 +2213,9 @@
zend_objects_clone_members(&new_obj->std, new_ov, &old_obj->std,
Z_OBJ_HANDLE_P(this_ptr) TSRMLS_CC);
- /** FIX ME ADD CLONE STUFF **/
+ new_obj->diff = timelib_rel_time_clone(old_obj->diff);
+ new_obj->initialized = 1;
+
return new_ov;
}
@@ -2283,7 +2285,27 @@
zend_objects_clone_members(&new_obj->std, new_ov, &old_obj->std,
Z_OBJ_HANDLE_P(this_ptr) TSRMLS_CC);
- /** FIX ME ADD CLONE STUFF **/
+ new_obj->start = timelib_time_ctor();
+ *new_obj->start = *old_obj->start;
+ if (old_obj->start->tz_abbr) {
+ new_obj->start->tz_abbr = strdup(old_obj->start->tz_abbr);
+ }
+ if (old_obj->start->tz_info) {
+ new_obj->start->tz_info = old_obj->start->tz_info;
+ }
+ new_obj->end = timelib_time_ctor();
+ *new_obj->end = *old_obj->end;
+ if (old_obj->end->tz_abbr) {
+ new_obj->end->tz_abbr = strdup(old_obj->end->tz_abbr);
+ }
+ if (old_obj->end->tz_info) {
+ new_obj->end->tz_info = old_obj->end->tz_info;
+ }
+ new_obj->interval = timelib_rel_time_clone(old_obj->interval);
+ new_obj->recurrences = old_obj->recurrences;
+ new_obj->include_start_date = old_obj->include_start_date;
+ new_obj->initialized = 1;
+
return new_ov;
}
Index: ext/date/tests/bug50559.phpt
===
--- ext/date/tests/bug50559.phpt(revision 0)
+++ ext/date/tests/bug50559.phpt(revision 0)
@@ -0,0 +1,131 @@
+--TEST--
+Bug #50559 (Clone is not implemented for DateInterval and DatePeriod)
+--FILE--
+format("l Y-m-d H:i:s\n");
+}
+
+echo "\n";
+echo "DatePeriod (clone)\n";
+foreach ($datePeriod2 as $p) {
+ echo $p->format("l Y-m-d H:i:s\n");
+}
+echo "\n";
+?>
+--EXPECT--
+
+DateInterval (original)
+object(DateInterval)#1 (8) {
+ ["y"]=>
+ int(0)
+ ["m"]=>
+ int(0)
+ ["d"]=>
+ int(1)
+ ["h"]=>
+ int(0)
+ ["i"]=>
+ int(0)
+ ["s"]=>
+ int(0)
+ ["invert"]=>
+ int(0)
+ ["days"]=>
+ int(0)
+}
+
+DateInterval (clone)
+object(DateInterval)#2 (8) {
+ ["y"]=>
+ int(0)
+ ["m"]=>
+ int(0)
+ ["d"]=>
+ int(1)
+ ["h"]=>
+ int(0)
+ ["i"]=>
+ int(0)
+ ["s"]=>
+ int(0)
+ ["invert"]=>
+ int(0)
+ ["days"]=>
+ int(0)
+}
+
+DatePeriod (original)
+Thursday 2008-01-31 00:00:00
+Thursday 2008-02-28 00:00:00
+Thursday 2008-03-27 00:00:00
+Thursday 2008-04-24 00:00:00
+Thursday 2008-05-29 00:00:00
+Thursday 2008-06-26 00:00:00
+Thursday 2008-07-31 00:00:00
+Thursday 2008-08-28 00:00:00
+Thursday 2008-09-25 00:00:00
+Thursday 2008-10-30 00:00:00
+Thursday 2008-11-27 00:00:00
+Thursday 2008-12-25 00:00:00
+Thursday 2009-01-29 00:00:00
+Thursday 2009-02-26 00:00:00
+Thursday 2009-03-26 00:00:00
+Thursday 2009-04-30 00:00:00
+Thursday 2009-05-28 00:00:00
+Thursday 2009-06-25 00:00:00
+Thursday 2009-07-30 00:00:00
+Thursday 2009-08-27 00:00:00
+Thursday 2009-09-24 00:00:00
+Thursday 2009-10-29 00:00:00
+Thursday 2009-11-26 00:00:00
+Thursday 2009-12-31 00:00:00
+
+DatePeriod (clone)
+Thursday 2008-01-31 00:00:00
+Thursday 2008-02-28 00:00:00
+Thursday 2008-03-27 00:00:00
+Thursday 2008-04-24 00:00:00
+Thursday 2008-05-29 00:00:00
+Thursday 2008-06-26 00:00:00
+Thursday 2008-07-31 00:00:00
+Thursday 2008-08-28 00:00:00
+Thursday 2008-09-25 00:00:00
+Thursday 2008-10-30 00:00:00
+Thursday 2008-11-27 00:00:00
+Thursday 2008-12-25 00:00:00
+Thursday 2009-01-29 00:00:00
+Thursday 2009-02-26 00:00:00
+Thursday 2009-03-26 00:00:00
+Thursday 2009-04-3
Bug #51225 [ReO]: cannot define a class with the same name as an interface
Edit report at http://bugs.php.net/bug.php?id=51225&edit=1
ID: 51225
User updated by: tony at marston-home dot demon dot co dot uk
Reported by: tony at marston-home dot demon dot co dot uk
Summary: cannot define a class with the same name as an
interface
Status: Re-Opened
Type: Bug
Package: Class/Object related
Operating System: Windows XP
PHP Version: 5.2.13
New Comment:
I disagree. class_exists() SHOULD check if that name has already been
declared as an interface otherwise you get the following situation:
if (!class_exists('foobar') { // returns false
class foobar{} // fails because interface exists
}
On the one hand it is saying "a class with the name 'foobar' does not
exist" which is immediately followed by "you cannot create a class with
the name 'foobar' as it already exists". That is not logical to me.
Previous Comments:
[2010-03-08 00:55:52] johan...@php.net
I think the error message ("Cannot redeclare class") should be clearer
about classes and interfaces sharing the same namespace, which is needed
as type hints would be conflicting otherwise, but class_exists (by
default) should only check classes in my opinion. Any change should
consider that there's also interface_exists() and they should be
consistent.
[2010-03-08 00:28:39] der...@php.net
Yes, I agree.
[2010-03-08 00:23:50] tony at marston-home dot demon dot co dot uk
If an interface is a class, then it should show up in class_exists() and
get_declared_classes().
[2010-03-08 00:02:25] ka...@php.net
Thats how the OO is designed, internally is interfaces just a class with
an additional flag.
So no bug here
[2010-03-06 18:50:41] tony at marston-home dot demon dot co dot uk
Description:
When I try to define a particular class it fails with "cannot redeclare
class ...". When I check with class_exists('...') it returns false, but
I still cannot create it. I eventually found some previous code which
uses the same name to define an interface.
Test script:
---
Interface Singleton{public static function instance();}
if (class_exists('Singleton')) {
$reason = 'class already exists';
} else {
class Singleton{
static function getInstance(){
return true;
}
}
}
Expected result:
If it is not possible to define a class and an interface with the same
name, then the class_exists() function should also include interface
names.
If it IS possible to have a class and an interface with the same name,
then the compiler should NOT reject the second reference.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51225&edit=1
