Bug #51779 [Opn]: FTP socket failed
Edit report at http://bugs.php.net/bug.php?id=51779&edit=1
ID: 51779
Updated by: m...@php.net
Reported by: michael dot clark at ncver dot edu dot au
Summary: FTP socket failed
Status: Open
Type: Bug
Package: FTP related
Operating System: HP-UX 11.23 ia64
PHP Version: 5.2.13
New Comment:
Well, obviously socket(AF_INET, SOCK_STREAM, 0) fails for you, no idea
why yet -- might be an HP-UX only issue.
Previous Comments:
[2010-05-10 06:31:15] michael dot clark at ncver dot edu dot au
Sorry, forgot to mention.
ftp_pasv is no help in this case, especially when client and server are
the same machine.
PS thanks for any help resolving this issue.
[2010-05-10 04:57:18] michael dot clark at ncver dot edu dot au
Description:
Have built new installations of apache 2.2.14 with PHP 5.2.13 to replace
previous installation of Apache 2.0 with PHP 4.3.4.
Other functionality has all worked.
We are recieving warning on all file related ftp functions:
Warning: ftp_rawlist() [function.ftp-rawlist]: socket() failed: Protocol
not supported (221)
Connection to server and login complete successfully.
When trying to list, put, get any data it fails.
My guess is connection successful on first port but second (data) port
not successful?
Test script:
---
";
$remote_list = ftp_rawlist($conn_id, "/home/devdba");
foreach ($remote_list as $list_item) {
echo $list_item."";
}
}
?>
Expected result:
FTP pwd: /home
item1
item2
item3
Actual result:
--
FTP pwd: /home
Warning: ftp_rawlist() [function.ftp-rawlist]: socket() failed: Protocol
not supported (221)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51779&edit=1
Bug #51778 [Opn->Fbk]: crash on libphp5.so, when running ampache's initial scripts
Edit report at http://bugs.php.net/bug.php?id=51778&edit=1 ID: 51778 Updated by: m...@php.net Reported by: nkostis at gmail dot com Summary: crash on libphp5.so, when running ampache's initial scripts -Status: Open +Status: Feedback Type: Bug Package: Apache2 related Operating System: plugapps (arch linux) PHP Version: 5.2.13 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2010-05-09 23:06:53] nkostis at gmail dot com Description: I get this core dump when running anything from ampache (test.php, index.php, install.php, any ampache version): #0 0x406300a8 in _zval_ptr_dtor () from /etc/httpd/modules/libphp5.so #1 0x40660624 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #2 0x4065dec8 in execute () from /etc/httpd/modules/libphp5.so the rest of the stack trace is unknown as LAMP runs on limited hardware (the pogoplug) and i have not install debug symbols. Pogoplug currently runs plugapps, an arm optimized version of Arch linux. I am not sure whether this crash is a vanilla php bug or a plugapps php issue. A basic "phpinfo()" script runs fine so at least basic php operation is properly configured. Sorry if the bug is not vanilla php and i'm wasting your time. Test script: --- any ampache script, i.e. test.php (http://pastebin.com/FXAtKNyJ), run on plugbox linux (arch 2.6.33 based) -- Edit this bug report at http://bugs.php.net/bug.php?id=51778&edit=1
Bug #51777 [Opn->Fbk]: RegEx matching fails
Edit report at http://bugs.php.net/bug.php?id=51777&edit=1
ID: 51777
Updated by: m...@php.net
Reported by: trevor at ridgebizdev dot com
Summary: RegEx matching fails
-Status: Open
+Status: Feedback
Type: Bug
Package: PCRE related
Operating System: Windows XP and Linux Server
PHP Version: 5.3.2
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works here. Do you have a pcre.backtrack_limit set?
Previous Comments:
[2010-05-09 18:36:54] trevor at ridgebizdev dot com
Description:
When a RegEx "looks" over ~32768 times during a successful match, every
RegEx function fails and returns the empty string.
Test script:
---
http://www.travelocity.com";);
// no problem with these first 2 RegExs
$response2 = preg_replace('/\s+/'," ",$response);
$mytitle =
preg_replace('/.*?<\s*title\s*>([^<]*)<.*/i','${1}',$response2);
echo "\nTitle Match Forward: ".$mytitle."\n\n";
// now, here's a problem
$mytitle2 =
preg_replace('/.*<\s*title\s*>([^<]*)<.*/i','${1}',$response2);
echo "\nTitle Match Backward: ".$mytitle2."\n\n";
?>
Expected result:
$mytitle gets extracted properly and echoed because the RegEx never
looks more than 32768 times starting at the beginning of the
travelocity.com page source. $mytitle2 never gets extracted because the
RegEx looks more than 32768 times successfully and preg_replace()
crashes into the empty string. Matching forward for the title is
working; matching backward for the title is failing for large buffers.
Actual result:
--
Title Match Forward: Travelocity Travel: Airline Tickets, Hotels,
Flights, Vacations, Cruises & Car Rentals
Title Match Backward:
--
Edit this bug report at http://bugs.php.net/bug.php?id=51777&edit=1
Bug #51772 [Opn->Asn]: php-fpm do not support PowerPC processors
Edit report at http://bugs.php.net/bug.php?id=51772&edit=1 ID: 51772 Updated by: m...@php.net Reported by: vaskes at mail dot ru Summary: php-fpm do not support PowerPC processors -Status: Open +Status: Assigned Type: Bug Package: Compile Failure Operating System: RedHat Ent. server 5.4-ppc64 PHP Version: 5.3.2 -Assigned To: +Assigned To: fat Previous Comments: [2010-05-08 15:44:04] vaskes at mail dot ru Description: PHP-FPM sapi do not support PowerPC processor. Build server IBM JS20 bladeserver [r...@headnode ~]# uname -a Linux headnode.tst.local 2.6.18-194.el5 #1 SMP Tue Mar 16 22:03:12 EDT 2010 ppc64 ppc64 ppc64 GNU/Linux Test script: --- svn co http://svn.php.net/repository/php/php-src/trunk/sapi/fpm sapi/fpm ./buildconf --force ./configure --prefix=/opt/php --enable-fpm --build=powerpc-redhat-linux-gnu --host=powerpc-redhat-linux-gnu --target=ppc-redhat-linux-gnu make make install Expected result: Successfull compilation and php-fpm working Actual result: -- /bin/sh /home/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/home/php-5.3.2/sapi/fpm -Isapi/fpm/ -I/home/php-5.3.2/sapi/fpm/ -DPHP_ATOM_INC -I/home/php-5.3.2/include -I/home/php-5.3.2/main -I/home/php-5.3.2 -I/home/php-5.3.2/ext/date/lib -I/home/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/home/php-5.3.2/ext/sqlite3/libsqlite -I/home/php-5.3.2/TSRM -I/home/php-5.3.2/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /home/php-5.3.2/sapi/fpm/fpm/fastcgi.c -o sapi/fpm/fpm/fastcgi.lo /bin/sh /home/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/home/php-5.3.2/sapi/fpm -Isapi/fpm/ -I/home/php-5.3.2/sapi/fpm/ -DPHP_ATOM_INC -I/home/php-5.3.2/include -I/home/php-5.3.2/main -I/home/php-5.3.2 -I/home/php-5.3.2/ext/date/lib -I/home/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/home/php-5.3.2/ext/sqlite3/libsqlite -I/home/php-5.3.2/TSRM -I/home/php-5.3.2/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /home/php-5.3.2/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo /bin/sh /home/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/home/php-5.3.2/sapi/fpm -Isapi/fpm/ -I/home/php-5.3.2/sapi/fpm/ -DPHP_ATOM_INC -I/home/php-5.3.2/include -I/home/php-5.3.2/main -I/home/php-5.3.2 -I/home/php-5.3.2/ext/date/lib -I/home/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/home/php-5.3.2/ext/sqlite3/libsqlite -I/home/php-5.3.2/TSRM -I/home/php-5.3.2/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c -o sapi/fpm/fpm/fpm_children.lo In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:8, from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_atomic.h:124:2: error: #error unsupported processor. please write a patch and send it to me In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:8, from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_atomic.h:128: error: expected Ðââ¤)Ðâ⥠before Ðââ¤*Ðâ⥠token In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:16: error: expected specifier-qualifier-list before Ðââ¤atomic_tÐâ⥠make: *** [sapi/fpm/fpm/fpm_children.lo] Error 1 /bin/sh /home/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/home/php-5.3.2/sapi/fpm -Isapi/fpm/ -I/home/php-5.3.2/sapi/fpm/ -DPHP_ATOM_INC -I/home/php-5.3.2/include -I/home/php-5.3.2/main -I/home/php-5.3.2 -I/home/php-5.3.2/ext/date/lib -I/home/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/home/php-5.3.2/ext/sqlite3/libsqlite -I/home/php-5.3.2/TSRM -I/home/php-5.3.2/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c -o sapi/fpm/fpm/fpm_children.lo In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:8, from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_atomic.h:124:2: error: #error unsupported processor. please write a patch and send it to me In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:8, from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_atomic.h:128: error: expected Ðââ¤)Ðâ⥠before Ðââ¤*Ðâ⥠token In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:16: error: expected specifier-qualifier-list before Ðââ¤atomic_tÐâ⥠make: *** [sapi/fpm/fpm/fpm_children.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=51772&edit=1
Bug #51775 [Opn->Asn]: Chunked response parsing error
Edit report at http://bugs.php.net/bug.php?id=51775&edit=1
ID: 51775
Updated by: m...@php.net
Reported by: vic at zymsys dot com
Summary: Chunked response parsing error
-Status: Open
+Status: Assigned
Type: Bug
Package: SOAP related
Operating System: CentOS 4.8
PHP Version: 5.3SVN-2010-05-09 (snap)
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2010-05-09 06:07:09] vic at zymsys dot com
Description:
I was getting an error from a SoapClient call: "Error Fetching http
body, No Content-Length, connection closed or chunked data". Thing was
I couldn't see any problem with the HTTP response.
I tracked the problem down to the get_http_body function in
ext/soap/php_http.c, where it reads the chunk size using
php_stream_gets(). That's returning the chunk size plus the CR (0d) but
leaving the LF (0a) unread. Then the unread LF gets read with HTTP
chunk, and the attempt to read the next chunk size starts with the last
character of the HTTP chunk, since it's behind one thanks to the unread
LF.
Here's a chunk of the response that throws it off, with the chunk size
(01bc) in the middle, surrounded by CR/LF pairs.
0850 3b 20 63 68 61 72 73 65 74 3d 22 75 74 66 2d 38 |;
charset="utf-8|
0860 22 0d 0a 0d 0a 30 30 30 30 30 31 62 63 0d 0a 3c
|"01bc..<|
0870 65 6e 76 3a 45 6e 76 65 6c 6f 70 65 20 78 6d 6c
|env:Envelope xml|
I added a little code under the line that adjusts the http buffer
allocation, and above the loop that reads the chunk, and this solved the
problem for me:
ch = php_stream_getc(stream); /* php_stream_gets may stop after CR and
leave LF in the buffer. If so, we need to eat it. */
if (ch != '\n') {
// Nope, it wasn't a LF. Put it at the start of the current buffer,
and advance one character.
http_buf[http_buf_size] = ch;
len_size++;
http_buf_size++;
}
This reads the next character, and if it is an LF it eats it, and if it
isn't it adds it to the http buffer.
I wanted to run this by someone more experienced hacking on the php
source before going any further to make sure the bug is legit, and the
fix looks at all sane.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51775&edit=1
Bug #51762 [Opn->Fbk]: Segfault when registering an error.
Edit report at http://bugs.php.net/bug.php?id=51762&edit=1 ID: 51762 Updated by: m...@php.net Reported by: RajivK at Sparklit dot com Summary: Segfault when registering an error. -Status: Open +Status: Feedback Type: Bug Package: Reproducible crash Operating System: Debian PHP Version: 5.3.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2010-05-07 01:51:50] RajivK at Sparklit dot com Description: We are running a program that has some 100,000 lines and we experienced some segfaults (1 in 10 times or so) on one of 2 servers. Both servers are nearly identical. Here is a back trace (Sorry I didn't have time to debug it further) hopefully it means something to somebody more familiar with the code. (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd8a3087710 (LWP 20068)] 0x7fd8a0605588 in ?? () from /lib/libc.so.6 (gdb) bt #0 0x7fd8a0605588 in ?? () from /lib/libc.so.6 #1 0x7fd8a0605a36 in free () from /lib/libc.so.6 #2 0x006e9ecb in php_error_cb (type=2048, error_filename=0x7fd89b4b7430 "/home/webroot/blog/inc/class/blogPostInterface.class", error_lineno=17, format=, args=) at /usr/src/mar17/php-5.3.2/main/main.c:908 #3 0x005e37e5 in soap_error_handler (error_num=2048, error_filename=0x7fd89b4b7430 "/home/webroot/blog/inc/class/blogPostInterface.class", error_lineno=17, format=0xc4fc08 "Non-static method %s::%s() should not be called statically", args=0x7fffc35aa320) at /usr/src/mar17/php-5.3.2/ext/soap/soap.c:2284 #4 0x0073af54 in zend_error (type=2048, format=0xc4fc08 "Non-static method %s::%s() should not be called statically") at /usr/src/mar17/php-5.3.2/Zend/zend.c:1029 #5 0x00789128 in zend_do_fcall_common_helper_SPEC (execute_data=0x136a500) at /usr/src/mar17/php-5.3.2/Zend/zend_vm_execute.h:274 #6 0x00765fd1 in execute (op_array=0x10ffb38) at /usr/src/mar17/php-5.3.2/Zend/zend_vm_execute.h:104 #7 0x0073a845 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/mar17/php-5.3.2/Zend/zend.c:1194 #8 0x006e749f in php_execute_script (primary_file=0x7fffc35aecd0) at /usr/src/mar17/php-5.3.2/main/main.c:2260 #9 0x007c3ac7 in main (argc=1, argv=0x7fffc35aef48) at /usr/src/mar17/php-5.3.2/sapi/cgi/cgi_main.c:2102 (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=51762&edit=1
Bug #51761 [Opn->Fbk]: Memory Error: IPR in language scanner
Edit report at http://bugs.php.net/bug.php?id=51761&edit=1 ID: 51761 Updated by: m...@php.net Reported by: russell dot tempero at rightnow dot com Summary: Memory Error: IPR in language scanner -Status: Open +Status: Feedback Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.2 New Comment: This should have been set to feedback, shouldn't it? Previous Comments: [2010-05-08 11:58:17] ka...@php.net Hi You should change the grammar in zend_language_scanner.l instead of the .c file which is generated based on the contains from the .l file. Else the patch looks good [2010-05-07 00:21:08] russell dot tempero at rightnow dot com Here is some useful debug information if you wish to trace exactly where the IPRs are happening: . . . state: 476 char: ? addr: 0xf1c7885e state: 140 char: ? addr: 0xf1c7885e state: 121 char: ? addr: 0xf1c7885e state: -1 char: ? addr: 0xffce705b state: 166 char: ? addr: 0xf1c7885e state: 201 char: > addr: 0xf1c7885f state: 203 char: addr: 0xf1c78860 RUSSELL: YYCURSOR: 0xf1c78860 YYLIMIT: 0xf1c78861 state: 202 char: state: 0 char: state: 4 char: state: 3 char: RUSSELL: returning 0 in yy3 [2010-05-07 00:13:10] russell dot tempero at rightnow dot com Description: When running PHP through Purify, I am seeing Invalid Pointer Read (IPR) errors such as the following: IPR: Invalid pointer read: * This is occurring while in thread 8075: lex_scan [zend_language_scanner.c:3174] zendlex[zend_compile.c:4950] zendparse [zend_language_parser.c:3280] compile_file [zend_language_scanner.l:343] rnt_compile_file [rnt_opcode_cache.c:1008] compile_filename [zend_language_scanner.l:386] * Reading 1 byte from 0xf735f332 between the heap and the stack. It appears that script files are memory mapped and then a cursor pointer is used to iterate over the mapped memory. The problem is that the cursor pointer is not properly checked when reaching the end of the file and memory values are read that are not part of the mapped memory. I manually fixed one case of this (see attached diff). However, there are others. It looks like this file is generated (using flex?) so this is probably not actually a PHP issue. However, I thought I would start here. Let me know if this needs to be submitted to somebody else. -- Edit this bug report at http://bugs.php.net/bug.php?id=51761&edit=1
Bug #51758 [Opn->Fbk]: zend_object_handlers.h prescribes incorrect behavior of write property handler
Edit report at http://bugs.php.net/bug.php?id=51758&edit=1 ID: 51758 Updated by: m...@php.net Reported by: cataphr...@php.net Summary: zend_object_handlers.h prescribes incorrect behavior of write property handler -Status: Open +Status: Feedback Type: Bug Package: Class/Object related Operating System: Not applicable PHP Version: 5.3.2 New Comment: Where's the value modified in zend_std_weite_property()? Previous Comments: [2010-05-06 20:47:08] cataphr...@php.net I also have some doubts about the accuracy of the first part (you may only modify it if its reference count is 1). Why 1? Since zend_std_write_property increments the refcount before storing the zval in the hash table, it would make more sense if it read "...its reference count is 0". Together with issue raised in body of the bug report, it makes me think perhaps this comment was written thinking the refcount would be incremented before the call to write_property. [2010-05-06 20:40:04] cataphr...@php.net Description: zend_object_handler.h reads (line 39): /* The following rule applies to write_property() and write_dimension() implementations: If you receive a value zval in write_property/write_dimension, you may only modify it if its reference count is 1. Otherwise, you must create a copy of that zval before making any changes. You should NOT modify the reference count of the value passed to you. */ Perhaps I'm reading the last phrase out of context, but zend_std_write_property() changes the reference count of the passed value in multiple places. Test script: --- Not applicable. Expected result: Expected either no prescription for the refcount of the passed value not to be changed or the refcount of the passed value actually not be changed. Actual result: -- The implementation and the header prescription are inconsistent. -- Edit this bug report at http://bugs.php.net/bug.php?id=51758&edit=1
Bug #51749 [Opn->Fbk]: header("Location:") changing HTTP status
Edit report at http://bugs.php.net/bug.php?id=51749&edit=1
ID: 51749
Updated by: m...@php.net
Reported by: theimp at iinet dot net dot au
Summary: header("Location:") changing HTTP status
-Status: Open
+Status: Feedback
Type: Bug
Package: HTTP related
Operating System: Debian Lenny
PHP Version: 5.3.2
New Comment:
header("Location: http://www.example.com/";, true, 503) works fine here.
Previous Comments:
[2010-05-07 02:14:50] theimp at iinet dot net dot au
Just to ensure that any solution is properly considered, I have noticed
a counterpoint to my original argument, and likely the reason for the
specific current behavior.
RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) says that "[If
the script returns a Location header field for a Client Redirect
Response] The Status header field MUST be supplied and MUST contain a
status value of 302 'Found', or it MAY contain an extension-code, that
is, another valid status code that means client redirection."
Critical in deciding the scope of this requirement is understanding what
is a "valid status code that means client redirection". Though it could
be assumed that it would be any HTTP 3xx code (the wording
"extension-code" would normally mean exactly that), the spec is not
unambiguous and the 201 response already proves to be an exception. It's
not just web browsers with interactive interfaces that use HTTP; knowing
what to do next can be useful for any failure code, and as 201 proves,
even some success codes.
(Although RFC 3875 is "Informational" by comparison to HTTP, etc., and
attempts at standardizing CGI any further have been stagnant, I would
nevertheless agree that compliance with RFC 3875 is very important where
possible, even above what I consider to be correct handling of the bug
that was supplied).
On the other hand, RFC 3875 also mentions related behaviors that are not
followed as specified. For example, PHP does not unset script-set
headers (whether set before or after the Location header) if the script
finishes without outputting a message body, as required. Nor does it
implement a mechanism for a Local Redirect Response at all (because it
doesn't make a lot of sense, given the misconception of the roles
"server" and "script" that RFC 3875 has).
Actually, much of considering the behavior of PHP with respect to RFC
3875 also requires deciding if php is the "script" or the "server".
Though it seems obvious that PHP is the script per the definitions of
RFC 3875, large chunks of functionality that are the direct
responsibility of the "server" according to RFC 3875 are performed, and
can only realistically be performed, by PHP. Now that I look, I can find
practically no documentation on PHP regarding which of the two (if not
both) PHP considers itself to be; or in fact much of anything related to
RFC 3875, including how PHP interprets it or indeed even if it agrees to
follow it.
To be honest, I would favor a standards-compliant response, if at all
sensible, even if it was onerous. On the other hand, as someone who has
tried very hard to comply with this and other standards, I find RFC 3875
to be maddeningly deficient, primarily by its confusion between what is
the responsibility (and thus functionality) of the script, and what is
the responsibility of the server. Ultimately, I would conclude that the
original bug as I reported it should be fixed in the way that I
suggested, on the grounds that the *intent* of RFC 3875 is being
followed. I arrive at this assertion by virtue of the fact that the
intent of the Location header according to Section 6.2 is clearly to
ensure that the script author is obeyed and thus the client actually
gets redirected when they should; to prevent a scenario where the script
author intends to redirect the client and sends no message body to this
effect, but interaction with the server or other software results in a
non-redirect response being generated and the user being unable to
understand the result. It is far more important to obey the intent of
the script author when they have taken the care to consider and provide
the correct response code for their script, as by all accounts the
response code is the single most important piece of information returned
and, when explicitly set, the intent of the script author cannot be
realized if this cannot be reliably communicated. Also, I think that
permitting the Location header other than for 3xx codes reflects that,
as per the HTML and related specifications, it is not necessarily
required or even desired for the client (web browser or otherwise) to
obey a Location header and follow it without user confirmation (despite
common practice today); that the client will always follow a Location
directive seems to be a key assumption of Section of 6.2/6.3.
Sorry for the essay; I'll summarize:
I t
Bug #51749 [Fbk->Opn]: header("Location:") changing HTTP status
Edit report at http://bugs.php.net/bug.php?id=51749&edit=1
ID: 51749
Updated by: ahar...@php.net
Reported by: theimp at iinet dot net dot au
Summary: header("Location:") changing HTTP status
-Status: Feedback
+Status: Open
Type: Bug
Package: HTTP related
Operating System: Debian Lenny
PHP Version: 5.3.2
New Comment:
That's not actually the point of the bug: the point is that if you've
already changed the HTTP status code, you probably don't want a Location
header silently changing it later to a 302.
I do think the bug's a valid one, FWIW.
Previous Comments:
[2010-05-12 09:46:56] m...@php.net
header("Location: http://www.example.com/";, true, 503) works fine here.
[2010-05-07 02:14:50] theimp at iinet dot net dot au
Just to ensure that any solution is properly considered, I have noticed
a counterpoint to my original argument, and likely the reason for the
specific current behavior.
RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) says that "[If
the script returns a Location header field for a Client Redirect
Response] The Status header field MUST be supplied and MUST contain a
status value of 302 'Found', or it MAY contain an extension-code, that
is, another valid status code that means client redirection."
Critical in deciding the scope of this requirement is understanding what
is a "valid status code that means client redirection". Though it could
be assumed that it would be any HTTP 3xx code (the wording
"extension-code" would normally mean exactly that), the spec is not
unambiguous and the 201 response already proves to be an exception. It's
not just web browsers with interactive interfaces that use HTTP; knowing
what to do next can be useful for any failure code, and as 201 proves,
even some success codes.
(Although RFC 3875 is "Informational" by comparison to HTTP, etc., and
attempts at standardizing CGI any further have been stagnant, I would
nevertheless agree that compliance with RFC 3875 is very important where
possible, even above what I consider to be correct handling of the bug
that was supplied).
On the other hand, RFC 3875 also mentions related behaviors that are not
followed as specified. For example, PHP does not unset script-set
headers (whether set before or after the Location header) if the script
finishes without outputting a message body, as required. Nor does it
implement a mechanism for a Local Redirect Response at all (because it
doesn't make a lot of sense, given the misconception of the roles
"server" and "script" that RFC 3875 has).
Actually, much of considering the behavior of PHP with respect to RFC
3875 also requires deciding if php is the "script" or the "server".
Though it seems obvious that PHP is the script per the definitions of
RFC 3875, large chunks of functionality that are the direct
responsibility of the "server" according to RFC 3875 are performed, and
can only realistically be performed, by PHP. Now that I look, I can find
practically no documentation on PHP regarding which of the two (if not
both) PHP considers itself to be; or in fact much of anything related to
RFC 3875, including how PHP interprets it or indeed even if it agrees to
follow it.
To be honest, I would favor a standards-compliant response, if at all
sensible, even if it was onerous. On the other hand, as someone who has
tried very hard to comply with this and other standards, I find RFC 3875
to be maddeningly deficient, primarily by its confusion between what is
the responsibility (and thus functionality) of the script, and what is
the responsibility of the server. Ultimately, I would conclude that the
original bug as I reported it should be fixed in the way that I
suggested, on the grounds that the *intent* of RFC 3875 is being
followed. I arrive at this assertion by virtue of the fact that the
intent of the Location header according to Section 6.2 is clearly to
ensure that the script author is obeyed and thus the client actually
gets redirected when they should; to prevent a scenario where the script
author intends to redirect the client and sends no message body to this
effect, but interaction with the server or other software results in a
non-redirect response being generated and the user being unable to
understand the result. It is far more important to obey the intent of
the script author when they have taken the care to consider and provide
the correct response code for their script, as by all accounts the
response code is the single most important piece of information returned
and, when explicitly set, the intent of the script author cannot be
realized if this cannot be reliably communicated. Also, I think that
permitting the Location header other than for 3xx codes reflects that,
as per the HTML and related specifications,
Bug #48487 [Com]: fetch_object calls __set before constructor
Edit report at http://bugs.php.net/bug.php?id=48487&edit=1
ID: 48487
Comment by: vadimx at gmail dot com
Reported by: joel at purerave dot com
Summary: fetch_object calls __set before constructor
Status: Closed
Type: Bug
Package: MySQLi related
Operating System: win2k sp4
PHP Version: 5.2.9
New Comment:
In mysql_fetch_object the same bug.
Previous Comments:
[2010-01-04 10:31:36] u...@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.
Fixed with http://news.php.net/php.cvs/61460
[2009-11-06 16:29:19] caferrari at gmail dot com
Help!.. i am having this issue with php 5.2.10 on Ubuntu 9.10 and Debian
5... and its evil!... my solution:
class Exemplo {
public function __construct($id=0, $nome='', $sigla=''){
if (isset($this->id)) return; //Ugly solution!!! help!
$this->id = $id;
$this->nome = $nome;
$this->sigla= $sigla;
}
}
[2009-08-25 17:14:42] joel at purerave dot com
No response yet?
[2009-06-06 20:33:40] joel at purerave dot com
Description:
mysqli_fetch_object with custom class calls __set() before constructor.
Reproduce code:
---
{$name} = $value;
echo 'setting'.PHP_EOL;
}
}
$sql = "SELECT id FROM test LIMIT 1";
$result = $mysqli->query($sql);
while ($obj = $result->fetch_object('myData', array('data'))) {
}
Expected result:
creating
setting
Actual result:
--
setting
creating
--
Edit this bug report at http://bugs.php.net/bug.php?id=48487&edit=1
Bug #51741 [Opn->Bgs]: preg_match returns zero if it hits backtracking limit
Edit report at http://bugs.php.net/bug.php?id=51741&edit=1 ID: 51741 Updated by: m...@php.net Reported by: jordi dot salvat dot i dot alabart at gmail dot com Summary: preg_match returns zero if it hits backtracking limit -Status: Open +Status: Bogus Type: Bug Package: PCRE related Operating System: Ubuntu PHP Version: 5.3SVN-2010-05-04 (SVN) New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. > Note that pcretest does report an error in this same case As can be queried with preg_last_error(). Previous Comments: [2010-05-04 20:32:41] jordi dot salvat dot i dot alabart at gmail dot com Description: According to the documentation, pcre_match should return FALSE on error: >From http://docs.php.net/manual/en/function.preg-match.php : << Return Values preg_match() returns the number of times pattern matches. That will be either 0 times (no match) or 1 time because preg_match() will stop searching after the first match. preg_match_all() on the contrary will continue until it reaches the end of subject. preg_match() returns FALSE if an error occurred. >> Instead, it returns 0 (integer zero) -- see Felipe's comment on http://bugs.php.net/bug.php?id=51663&edit=2 for a check. Note that pcretest does report an error in this same case: $ pcretest PCRE version 7.8 2008-09-05 re> /(.+)+:/ data> \q10a:bbb Error -8 data> Test script: --- http://bugs.php.net/bug.php?id=51741&edit=1
Req #43233 [Com]: SASL options do not load - Missing SASL support in windows builds
Edit report at http://bugs.php.net/bug.php?id=43233&edit=1
ID: 43233
Comment by: bruno dot chalopin at laposte dot net
Reported by: scott dot thomas at inin dot com
Summary: SASL options do not load - Missing SASL support in
windows builds
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Windows 2003 Server
PHP Version: 5.2.5
New Comment:
There is still no sasl support in ldap on Windows binaries (5.2.x or
5.3.x)
Why isn't it activate by default on Windows ? A lot of Active Directory
Ldap server require a strong authentication like 'DIGEST-MD5' which is
only provided by ldap_sasl_bind.
Previous Comments:
[2007-11-11 01:22:25] scott dot thomas at inin dot com
Can it be added in or perhaps a special build made so I can use this
feature? Do I have any other options besides moving to a non-Windows
platform?
[2007-11-10 22:18:46] j...@php.net
This is not a bug, just missing feature or rather: missing sasl support
in the ldap libraries used to build win32 binaries.
[2007-11-10 08:40:57] scott dot thomas at inin dot com
Description:
Using Windows 2003 I seem to have no way to use LDAP_SASL_BIND(). All
LDAP functions work otherwise. Error is as follows:
Fatal error: Call to undefined function ldap_sasl_bind()
Manual says to compile with --with-ldap-sasl but that is not an option
for Windows deployments.
Reproduce code:
---
if ($connect=ldap_connect($ldap_server)) {
ldap_set_option($connect, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($connect, LDAP_OPT_REFERRALS, 0);
if ($bind=ldap_sasl_bind($connect, $auth_user, $password)) {
ldap_close($connect);
return true;
}
else {
print ldap_error($connect) . '';
}
}//if connected to ldap
ldap_close($connect);
return false;
Expected result:
return true or return false
Actual result:
--
Fatal error: Call to undefined function ldap_sasl_bind()
--
Edit this bug report at http://bugs.php.net/bug.php?id=43233&edit=1
Bug #51725 [PATCH]: xmlrpc_get_type() returns true on invalid dates
Edit report at http://bugs.php.net/bug.php?id=51725&edit=1 ID: 51725 Patch added by: m...@php.net Reported by: geiss...@php.net Summary: xmlrpc_get_type() returns true on invalid dates Status: Verified Type: Bug Package: XMLRPC-EPI related Operating System: linux/kfreebsd ia64/x86_64 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: php_parse_date-return-on-parse-error Revision: 1273655513 URL: http://bugs.php.net/patch-display.php?bug=51725&patch=php_parse_date-return-on-parse-error&revision=1273655513 Previous Comments: [2010-05-03 15:32:16] il...@php.net IT happens on 64bit systems only. The reason has to do with date extension, which is used to validate the date string (on 64 bit machines this results in a very small negative #), not -1 and thus passed validation. [2010-05-03 14:23:18] fel...@php.net (I tested on 32bit though) [2010-05-03 14:20:36] fel...@php.net I cannot reproduce it on Linux using: libexpat1-dev --- 2.0.1-4+lenny3 libxml2-dev--- 2.7.3.dfsg-2.1 [2010-05-03 05:40:35] geiss...@php.net Description: ext/xmlrpc/tests/bug42189.phpt fails consistently on 64 bits architectures such as ia64 and x86_64. I modified the test a bit to show what's going on. From a quick look at the code it appears to be a bug in the XMLRPC-EPI lib and not in the module itself. Test script: --- Expected result: bool(false) Done Actual result: -- bool(true) ~~ Done -- Edit this bug report at http://bugs.php.net/bug.php?id=51725&edit=1
Bug #51741 [Bgs]: preg_match returns zero if it hits backtracking limit
Edit report at http://bugs.php.net/bug.php?id=51741&edit=1 ID: 51741 User updated by: jordi dot salvat dot i dot alabart at gmail dot com Reported by: jordi dot salvat dot i dot alabart at gmail dot com Summary: preg_match returns zero if it hits backtracking limit Status: Bogus Type: Bug Package: PCRE related Operating System: Ubuntu PHP Version: 5.3SVN-2010-05-04 (SVN) New Comment: So this is a documentation error. I've tried to add a comment to http://docs.php.net/manual/en/function.preg-match.php, but I got this: << Warning: include(/home/local/Web/sites/docs.php.net/manual/include/spam-func.php) [function.include]: failed to open stream: No such file or directory in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 9 Warning: include() [function.include]: Failed opening '/home/local/Web/sites/docs.php.net/manual/include/spam-func.php' for inclusion (include_path='.:/local/php/lib/php') in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 9 Fatal error: Call to undefined function kill_spammer() in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 10 >> I should have stuck to Java. Previous Comments: [2010-05-12 09:52:45] m...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. > Note that pcretest does report an error in this same case As can be queried with preg_last_error(). [2010-05-04 20:32:41] jordi dot salvat dot i dot alabart at gmail dot com Description: According to the documentation, pcre_match should return FALSE on error: >From http://docs.php.net/manual/en/function.preg-match.php : << Return Values preg_match() returns the number of times pattern matches. That will be either 0 times (no match) or 1 time because preg_match() will stop searching after the first match. preg_match_all() on the contrary will continue until it reaches the end of subject. preg_match() returns FALSE if an error occurred. >> Instead, it returns 0 (integer zero) -- see Felipe's comment on http://bugs.php.net/bug.php?id=51663&edit=2 for a check. Note that pcretest does report an error in this same case: $ pcretest PCRE version 7.8 2008-09-05 re> /(.+)+:/ data> \q10a:bbb Error -8 data> Test script: --- http://bugs.php.net/bug.php?id=51741&edit=1
Bug #51741 [Bgs]: preg_match returns zero if it hits backtracking limit
Edit report at http://bugs.php.net/bug.php?id=51741&edit=1 ID: 51741 Updated by: bj...@php.net Reported by: jordi dot salvat dot i dot alabart at gmail dot com Summary: preg_match returns zero if it hits backtracking limit Status: Bogus Type: Bug Package: PCRE related Operating System: Ubuntu PHP Version: 5.3SVN-2010-05-04 (SVN) New Comment: docs.php.net is a development mirror, not an official mirror. See http://php.net/mirrors That bug has however been fixed, thanks for the report. Previous Comments: [2010-05-12 11:15:43] jordi dot salvat dot i dot alabart at gmail dot com So this is a documentation error. I've tried to add a comment to http://docs.php.net/manual/en/function.preg-match.php, but I got this: << Warning: include(/home/local/Web/sites/docs.php.net/manual/include/spam-func.php) [function.include]: failed to open stream: No such file or directory in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 9 Warning: include() [function.include]: Failed opening '/home/local/Web/sites/docs.php.net/manual/include/spam-func.php' for inclusion (include_path='.:/local/php/lib/php') in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 9 Fatal error: Call to undefined function kill_spammer() in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 10 >> I should have stuck to Java. [2010-05-12 09:52:45] m...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. > Note that pcretest does report an error in this same case As can be queried with preg_last_error(). [2010-05-04 20:32:41] jordi dot salvat dot i dot alabart at gmail dot com Description: According to the documentation, pcre_match should return FALSE on error: >From http://docs.php.net/manual/en/function.preg-match.php : << Return Values preg_match() returns the number of times pattern matches. That will be either 0 times (no match) or 1 time because preg_match() will stop searching after the first match. preg_match_all() on the contrary will continue until it reaches the end of subject. preg_match() returns FALSE if an error occurred. >> Instead, it returns 0 (integer zero) -- see Felipe's comment on http://bugs.php.net/bug.php?id=51663&edit=2 for a check. Note that pcretest does report an error in this same case: $ pcretest PCRE version 7.8 2008-09-05 re> /(.+)+:/ data> \q10a:bbb Error -8 data> Test script: --- http://bugs.php.net/bug.php?id=51741&edit=1
Bug #51725 [PATCH]: xmlrpc_get_type() returns true on invalid dates
Edit report at http://bugs.php.net/bug.php?id=51725&edit=1 ID: 51725 Patch added by: m...@php.net Reported by: geiss...@php.net Summary: xmlrpc_get_type() returns true on invalid dates Status: Verified Type: Bug Package: XMLRPC-EPI related Operating System: linux/kfreebsd ia64/x86_64 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: php_parse_date-return-on-parse-error Revision: 1273656982 URL: http://bugs.php.net/patch-display.php?bug=51725&patch=php_parse_date-return-on-parse-error&revision=1273656982 Previous Comments: [2010-05-12 11:11:53] m...@php.net The following patch has been added/updated: Patch Name: php_parse_date-return-on-parse-error Revision: 1273655513 URL: http://bugs.php.net/patch-display.php?bug=51725&patch=php_parse_date-return-on-parse-error&revision=1273655513 [2010-05-03 15:32:16] il...@php.net IT happens on 64bit systems only. The reason has to do with date extension, which is used to validate the date string (on 64 bit machines this results in a very small negative #), not -1 and thus passed validation. [2010-05-03 14:23:18] fel...@php.net (I tested on 32bit though) [2010-05-03 14:20:36] fel...@php.net I cannot reproduce it on Linux using: libexpat1-dev --- 2.0.1-4+lenny3 libxml2-dev--- 2.7.3.dfsg-2.1 [2010-05-03 05:40:35] geiss...@php.net Description: ext/xmlrpc/tests/bug42189.phpt fails consistently on 64 bits architectures such as ia64 and x86_64. I modified the test a bit to show what's going on. From a quick look at the code it appears to be a bug in the XMLRPC-EPI lib and not in the module itself. Test script: --- Expected result: bool(false) Done Actual result: -- bool(true) ~~ Done -- Edit this bug report at http://bugs.php.net/bug.php?id=51725&edit=1
Bug #51725 [Ver->Csd]: xmlrpc_get_type() returns true on invalid dates
Edit report at http://bugs.php.net/bug.php?id=51725&edit=1 ID: 51725 Updated by: m...@php.net Reported by: geiss...@php.net Summary: xmlrpc_get_type() returns true on invalid dates -Status: Verified +Status: Closed Type: Bug Package: XMLRPC-EPI related Operating System: linux/kfreebsd ia64/x86_64 PHP Version: 5.3.2 -Assigned To: +Assigned To: mike 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-05-12 11:37:28] m...@php.net Automatic comment from SVN on behalf of mike Revision: http://svn.php.net/viewvc/?view=revision&revision=299277 Log: Fixed bug #51725 (xmlrpc_get_type() returns true on invalid dates). (Mike) [2010-05-12 11:36:22] m...@php.net The following patch has been added/updated: Patch Name: php_parse_date-return-on-parse-error Revision: 1273656982 URL: http://bugs.php.net/patch-display.php?bug=51725&patch=php_parse_date-return-on-parse-error&revision=1273656982 [2010-05-12 11:11:53] m...@php.net The following patch has been added/updated: Patch Name: php_parse_date-return-on-parse-error Revision: 1273655513 URL: http://bugs.php.net/patch-display.php?bug=51725&patch=php_parse_date-return-on-parse-error&revision=1273655513 [2010-05-03 15:32:16] il...@php.net IT happens on 64bit systems only. The reason has to do with date extension, which is used to validate the date string (on 64 bit machines this results in a very small negative #), not -1 and thus passed validation. [2010-05-03 14:23:18] fel...@php.net (I tested on 32bit though) 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=51725 -- Edit this bug report at http://bugs.php.net/bug.php?id=51725&edit=1
Bug #51643 [Opn->Bgs]: ICONV transliteration bug
Edit report at http://bugs.php.net/bug.php?id=51643&edit=1
ID: 51643
Updated by: m...@php.net
Reported by: olegs at brandos dot com
Summary: ICONV transliteration bug
-Status: Open
+Status: Bogus
Type: Bug
Package: ICONV related
Operating System: Linux
PHP Version: 5.2.13
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
$ iconv -f utf8 -t ascii//translit <<<'Støvler & Støvletter' | hexdump
-C
53 74 3f 76 6c 65 72 20 26 20 53 74 3f 76 6c 65 |St?vler &
St?vle|
0010 74 74 65 72 0a|tter.|
0015
Previous Comments:
[2010-04-23 11:17:49] olegs at brandos dot com
Description:
Transliteration of ø char (at least)
Test script:
---
iconv('UTF-8', 'ASCII//TRANSLIT', 'Støvler & Støvletter');
Expected result:
'Stovler & Stovletter'
Actual result:
--
'Stvler & Stvletter'
--
Edit this bug report at http://bugs.php.net/bug.php?id=51643&edit=1
Bug #51658 [ReO->Fbk]: Segfault when using stream_filter_append()
Edit report at http://bugs.php.net/bug.php?id=51658&edit=1
ID: 51658
Updated by: m...@php.net
Reported by: slusarz at curecanti dot org
Summary: Segfault when using stream_filter_append()
-Status: Re-Opened
+Status: Feedback
Type: Bug
Package: Streams related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2010-04-30 20:59:33] slusarz at curecanti dot org
I don't have the time to try to track this down further. The bug still
exists, but it obviously requires something more (in terms of program
state) than a simple test script can recreate.
[2010-04-30 00:09:35] fel...@php.net
I cannot reproduce this. We need a proper test case.
[2010-04-26 21:57:21] slusarz at curecanti dot org
I can't provide a simple test case - it appears that it takes something
more than just appending a write filter to a stream (the error is
occurring after tens of thousands lines of code were run).
But I did manage to determine that this only happens if the script exits
soon after the filter_append with an explicit 'exit' call. e.g.:
-
[...code...]
$fp = fopen('php://temp', 'w+');
stream_filter_register('user_filter', 'User_Filter_Class_Name');
stream_filter_append($fp, 'user_filter', STREAM_FILTER_WRITE);
print "TEST";
exit;
[...code...]
-
will segfault and will not output "TEST" to the browser. If 'exit;' is
removed, no segfault occurs.
[2010-04-25 12:08:08] paj...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2010-04-25 10:23:00] slusarz at curecanti dot org
Description:
PHP segfaulting when appending a user-defined filter in WRITE mode. I
can confirm that if I switch to READ mode, or I use a PHP built-in
filter, the segfault goes away.
Test script:
---
The code that causes this to happen looks like this:
$fp = fopen('php://temp', 'w+');
stream_filter_register('user_filter', 'User_Filter_Class_Name');
stream_filter_append($fp, 'user_filter', STREAM_FILTER_WRITE);
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x00743918 in zend_hash_find (ht=0x2682b28, arKey=0xc32354
"stream",
nKeyLength=7, pData=0x7fffc9b123f8)
at /disk2/src/php-5.3.2/Zend/zend_hash.c:880
880 p = ht->arBuckets[nIndex];
-
#0 0x00743918 in zend_hash_find (ht=0x2682b28,
arKey=0xc32354 "stream", nKeyLength=7, pData=0x7fffc9b123f8)
at /disk2/src/php-5.3.2/Zend/zend_hash.c:880
#1 0x006c2a79 in userfilter_filter (stream=0x269c908,
thisfilter=, buckets_in=0x7fffc9b12480,
buckets_out=0x7fffc9b12470, bytes_consumed=0x7fffc9b12498, flags=2)
at /disk2/src/php-5.3.2/ext/standard/user_filters.c:183
#2 0x006fc727 in _php_stream_write_filtered (stream=0x269c908,
buf=, count=, flags=2)
at /disk2/src/php-5.3.2/main/streams/streams.c:997
#3 0x006fc93c in _php_stream_flush (stream=0x269c908,
closing=)
at /disk2/src/php-5.3.2/main/streams/streams.c:1046
#4 0x006fcb43 in _php_stream_free (stream=0x269c908,
close_options=11)
at /disk2/src/php-5.3.2/main/streams/streams.c:331
#5 0x006fce11 in stream_resource_regular_dtor (
rsrc=)
at /disk2/src/php-5.3.2/main/streams/streams.c:1426
#6 0x00745bbe in list_entry_destructor (ptr=0x269d1c0)
at /disk2/src/php-5.3.2/Zend/zend_list.c:184
#7 0x00744da5 in zend_hash_del_key_or_index (ht=0xfbdef0,
arKey=0xc32354 "stream", nKeyLength=3383829656, h=229483039115121,
flag=) at
/disk2/src/php-5.3.2/Zend/zend_hash.c:497
#8 0x00745e67 in _ze
Req #43233 [Opn->Asn]: SASL options do not load - Missing SASL support in windows builds
Edit report at http://bugs.php.net/bug.php?id=43233&edit=1
ID: 43233
Updated by: paj...@php.net
Reported by: scott dot thomas at inin dot com
Summary: SASL options do not load - Missing SASL support in
windows builds
-Status: Open
+Status: Assigned
Type: Feature/Change Request
-Package: Feature/Change Request
+Package: *General Issues
Operating System: Windows 2003 Server
PHP Version: 5.2.5
-Assigned To:
+Assigned To: pajoye
New Comment:
I don't think it can be done easily and it seems that even if it was
supported, there are some issues with this auth method and AD (wrong
enconding).
I will try to take a look at that for trunk, but don't hold your breath,
that won't happen in 5.3.x for now.
Previous Comments:
[2010-05-12 11:11:38] bruno dot chalopin at laposte dot net
There is still no sasl support in ldap on Windows binaries (5.2.x or
5.3.x)
Why isn't it activate by default on Windows ? A lot of Active Directory
Ldap server require a strong authentication like 'DIGEST-MD5' which is
only provided by ldap_sasl_bind.
[2007-11-11 01:22:25] scott dot thomas at inin dot com
Can it be added in or perhaps a special build made so I can use this
feature? Do I have any other options besides moving to a non-Windows
platform?
[2007-11-10 22:18:46] j...@php.net
This is not a bug, just missing feature or rather: missing sasl support
in the ldap libraries used to build win32 binaries.
[2007-11-10 08:40:57] scott dot thomas at inin dot com
Description:
Using Windows 2003 I seem to have no way to use LDAP_SASL_BIND(). All
LDAP functions work otherwise. Error is as follows:
Fatal error: Call to undefined function ldap_sasl_bind()
Manual says to compile with --with-ldap-sasl but that is not an option
for Windows deployments.
Reproduce code:
---
if ($connect=ldap_connect($ldap_server)) {
ldap_set_option($connect, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($connect, LDAP_OPT_REFERRALS, 0);
if ($bind=ldap_sasl_bind($connect, $auth_user, $password)) {
ldap_close($connect);
return true;
}
else {
print ldap_error($connect) . '';
}
}//if connected to ldap
ldap_close($connect);
return false;
Expected result:
return true or return false
Actual result:
--
Fatal error: Call to undefined function ldap_sasl_bind()
--
Edit this bug report at http://bugs.php.net/bug.php?id=43233&edit=1
Bug #51591 [Opn->Bgs]: No warnings reported when invalidly adding automatically indexed array element
Edit report at http://bugs.php.net/bug.php?id=51591&edit=1
ID: 51591
Updated by: m...@php.net
Reported by: amcsi at mailbox dot hu
Summary: No warnings reported when invalidly adding
automatically indexed array element
-Status: Open
+Status: Bogus
Type: Bug
Package: Unknown/Other Function
Operating System: Ubuntu 10.04 beta 2
PHP Version: 5.3.2
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
This is not a set operation on the object, but rather setting an array
entry on the property "bar".
Previous Comments:
[2010-04-18 21:04:31] amcsi at mailbox dot hu
Description:
When an object with a __set() method has its non-existent array
containing variable set by empty bracket syntax, it just creates a new
object variable for the array, as if __set() weren't even there.
Test script:
---
_vars[$var] = $value;
}
}
$foo = new Foo;
$foo->bar[] = 'value';
var_dump($foo);
?>
Expected result:
__set() method called
object(Foo)#1 (1) {
["_vars"]=>
array(1) {
["bar"]=>
array(1) {
[0]=>
string(5) "value"
}
}
}
OR
Fatal error: Cannot use [] for reading in
/home/amcsi/htdocs/lol.php on line 11
Actual result:
--
object(Foo)#1 (2) {
["_vars"]=>
array(0) {
}
["bar"]=>
array(1) {
[0]=>
string(5) "value"
}
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=51591&edit=1
Req #39863 [Com]: file_exists() silently truncates after a null byte
Edit report at http://bugs.php.net/bug.php?id=39863&edit=1 ID: 39863 Comment by: vanderaj at owasp dot org Reported by: djcapelis at gmail dot com Summary: file_exists() silently truncates after a null byte Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: Linux, MacOSX PHP Version: 4.4.4, 5.1.5 New Comment: I've tested this on CentOS 5.0 with a hand built 5.2.11 and Apple's build of PHP 5.3.1 on MacOS X 10.6.3, and both have this issue. If you don't want to run a phpt, here's some a more readable version of the previous test: I've included a PHP test script. It's my first phpt, so please be gentle. Previous Comments: [2006-12-20 09:47:27] djcapelis at gmail dot com Sorry, testing was originally done using the hardened php patch here: http://www.hardened-php.net/downloads.13.html Without the patch, include_once() is just as vulnerable and silently readily embeds /etc/passwd right into the file. Perhaps it would be a good idea to include that part of the patch into the main PHP distribution and fix the rest of the functions where this is a problem. I just tested and PHP 5.1.5 is also vulnerable to both these issues. (As was a Mac OSX system.) [2006-12-18 08:46:13] djcapelis at gmail dot com Description: file_exists() silently truncates anything after a null byte in a string. This produces unexpected results in some circumstances and possibly would result in security problems for limited amounts of poorly written code. include_once() for instance, provides the following: "ALERT - Include filename truncated by a \0 after '/etc/passwd' (attacker 'REMOTE_ADDR not set', file '/home/djc/test.php', line 13)" This seems like a sane way to handle it if truncating has to be done... though frankly since truncation will *always* produce the wrong result it might be nice to throw an error and stop processing. Reproduce code: --- Expected result: Expected: $ php -n test.php The file /etc/passwd.\0someextension does not exist Actual result: -- Actual: $ php -n test.php The file /etc/passwd.someextension exists -- Edit this bug report at http://bugs.php.net/bug.php?id=39863&edit=1
[PHP-BUG] Req #51798 [NEW]: Implement mpz_mul_2exp
From: Operating system: Any PHP version: 5.3.2 Package: GNU MP related Bug Type: Feature/Change Request Bug description:Implement mpz_mul_2exp Description: A number of GMP functions are not yet exposed through PHP, for example mpz_mul_2exp; "Set rop to op1 times 2 raised to op2. This operation can also be defined as a left shift by op2 bits." See also http://svn.php.net/viewvc/php/php-src/trunk/ext/gmp/TODO?view=markup If I implement it I will attach the patch. -- Edit bug report at http://bugs.php.net/bug.php?id=51798&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51798&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51798&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51798&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51798&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51798&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51798&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51798&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51798&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51798&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51798&r=support Expected behavior: http://bugs.php.net/fix.php?id=51798&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51798&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51798&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51798&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51798&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51798&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51798&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51798&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51798&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51798&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51798&r=mysqlcfg
Bug #51749 [Com]: header("Location:") changing HTTP status
Edit report at http://bugs.php.net/bug.php?id=51749&edit=1
ID: 51749
Comment by: theimp at iinet dot net dot au
Reported by: theimp at iinet dot net dot au
Summary: header("Location:") changing HTTP status
Status: Open
Type: Bug
Package: HTTP related
Operating System: Debian Lenny
PHP Version: 5.3.2
New Comment:
@ mike at php dot net
I did more testing, and yes, if you use the additional parameters on the
occasion that you send the location header, the special handling of the
Location header does not override the explicit behavior.
So:
header("HTTP/1.1 503 Service Unavailable", true, 503);
header("Location: http://www.php.net/";);
Does not work; but:
header("HTTP/1.1 503 Service Unavailable");
header("Location: http://www.php.net/";, true, 503);
Does work.
Obvious, in hindsight. But very confusing at first. The documentation
for http_response_code simply says: "Forces the HTTP response code to
the specified value"; I read that as forcing the response code
irrespective of any other later action other than another
http_response_code. It's not quite a documentation bug, since it's not
strictly wrong, but it should probably be changed, because it is easy to
read other than as intended. I would accept changing this bug to a
documentation bug.
@ aharvey at php dot net
The functionality I expected exists; I simply did not understand it. But
I do agree with what you say also; it is questionable whether it should
behave the way that it does even aside from other functionality.
To really know how this should be treated requires, I think,
consideration of the points I have previously mentioned. Presumably,
this specific behavior was put into PHP for a reason, and it was not
changed much when the opportunity last arose. I do not know the specific
goals of the PHP project in this respect.
I would not have written this bug report if I had realized the correct
way to use the http_response_code parameter.
Also, the workaround mentioned in bug #25044 is still possible.
Finally, I had not properly considered RFC 3875 when I first created
this bug report. If I had, I would probably have decided that the
behavior is deliberate and was not expected to be fixed.
The http_response_code is confusing, since it can be set on unrelated
headers, making it difficult to track down the code that sets it since
it could be a place other than where you set the Response Line itself
(in principle, any header; practically, any Location header in addition
to the Response Line header).
Also, the HTTP Response Code that you want to set must be known at the
time you want to set the Location header, which might not be known at
that time. It might have already been set in another function; there is
no way to retrieve the response code that you have set, so you have to
remember it yourself by assigning it to a variable and re-using that
variable at the time you set the Location header.
For example:
...
if ($_SERVER["HTTPS"] != "on") {
setstatus(426);
setlocation("https");
}
...
function setstatus($status)
{
switch ($status)
{
...
case 426:
header("HTTP/1.1 426 Upgrade Required");
break;
...
}
}
...
function setlocation($scheme)
{
switch ($scheme)
{
...
case "https":
header('Location: $scheme://$url');
break;
...
}
}
A better solution may have been, rather than to add the
http_response_code parameter, to have added a force_response() function
to optionally set the HTTP Response Code, which would not be
overwritten. But we are long past the point that it makes sense to add
such a function; it would add no new functionality and would deprecate
existing uses of unrelated code.
While I do think that PHP should not set the Response Code after a
Location header, there are still reasons to consider this behavior
appropriate (standards compliance and backwards-compatibility), which I
have already discussed at length.
On the other hand; fixing this "bug" in a way similar to the one I
suggested would make PHP more robust and make it much more likely that
people get the behavior that they expect after they read all of the
relevant documentation. It may also help with bug-finding in the case of
incorrect header output, and simplify some functions, depending on how
they have been designed.
Thank you all for taking the time to consider this bug.
Previous Comments:
[2010-05-12 09:49:04] ahar...@php.net
That's not actually the point of the bug: the point is that if you've
already changed the HTTP status code, you probably don't want a Location
header silently changing it later to a 302.
I do think the bug's a valid one, FWIW.
Bug #51581 [PATCH]: getDefaultProperties incorrect for static properties
Edit report at http://bugs.php.net/bug.php?id=51581&edit=1 ID: 51581 Patch added by: m...@php.net Reported by: ChadFulton at gmail dot com Summary: getDefaultProperties incorrect for static properties Status: Open Type: Bug Package: Reflection related Operating System: Mac OSx 10.6 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: fix-refs-to-default-static-members Revision: 1273671720 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-refs-to-default-static-members&revision=1273671720 Previous Comments: [2010-04-17 02:24:07] ChadFulton at gmail dot com Description: The array ReflectionClass's getDefaultProperties() method changes for static properties, depending upon what value the static property currently holds. I suppose there is an argument to be made that this is expected/desired, since static properties are meant to hold across all instances of the class. However, it doesn't seem like it necessarily fits as part of a function to get the *default* property. Test script: --- getDefaultProperties()); foo::$bar = 'new static value, no longer default though'; print_r($r->getDefaultProperties()); ?> Expected result: Array ( [bar] => true default value ) Array ( [bar] => true default value ) Actual result: -- Array ( [bar] => true default value ) Array ( [bar] => new static value, no longer default though ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51581&edit=1
Bug #51581 [PATCH]: getDefaultProperties incorrect for static properties
Edit report at http://bugs.php.net/bug.php?id=51581&edit=1 ID: 51581 Patch added by: m...@php.net Reported by: ChadFulton at gmail dot com Summary: getDefaultProperties incorrect for static properties Status: Open Type: Bug Package: Reflection related Operating System: Mac OSx 10.6 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: fix-reflection-of-default-static-members Revision: 1273671935 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-reflection-of-default-static-members&revision=1273671935 Previous Comments: [2010-05-12 15:42:00] m...@php.net The following patch has been added/updated: Patch Name: fix-refs-to-default-static-members Revision: 1273671720 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-refs-to-default-static-members&revision=1273671720 [2010-04-17 02:24:07] ChadFulton at gmail dot com Description: The array ReflectionClass's getDefaultProperties() method changes for static properties, depending upon what value the static property currently holds. I suppose there is an argument to be made that this is expected/desired, since static properties are meant to hold across all instances of the class. However, it doesn't seem like it necessarily fits as part of a function to get the *default* property. Test script: --- getDefaultProperties()); foo::$bar = 'new static value, no longer default though'; print_r($r->getDefaultProperties()); ?> Expected result: Array ( [bar] => true default value ) Array ( [bar] => true default value ) Actual result: -- Array ( [bar] => true default value ) Array ( [bar] => new static value, no longer default though ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51581&edit=1
Bug #51581 [Opn->Asn]: getDefaultProperties incorrect for static properties
Edit report at http://bugs.php.net/bug.php?id=51581&edit=1 ID: 51581 Updated by: m...@php.net Reported by: ChadFulton at gmail dot com Summary: getDefaultProperties incorrect for static properties -Status: Open +Status: Assigned Type: Bug Package: Reflection related Operating System: Mac OSx 10.6 PHP Version: 5.3.2 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, could you please review the fix-refs-to-default-static-members patch? Thank you. Previous Comments: [2010-05-12 15:45:35] m...@php.net The following patch has been added/updated: Patch Name: fix-reflection-of-default-static-members Revision: 1273671935 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-reflection-of-default-static-members&revision=1273671935 [2010-05-12 15:42:00] m...@php.net The following patch has been added/updated: Patch Name: fix-refs-to-default-static-members Revision: 1273671720 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-refs-to-default-static-members&revision=1273671720 [2010-04-17 02:24:07] ChadFulton at gmail dot com Description: The array ReflectionClass's getDefaultProperties() method changes for static properties, depending upon what value the static property currently holds. I suppose there is an argument to be made that this is expected/desired, since static properties are meant to hold across all instances of the class. However, it doesn't seem like it necessarily fits as part of a function to get the *default* property. Test script: --- getDefaultProperties()); foo::$bar = 'new static value, no longer default though'; print_r($r->getDefaultProperties()); ?> Expected result: Array ( [bar] => true default value ) Array ( [bar] => true default value ) Actual result: -- Array ( [bar] => true default value ) Array ( [bar] => new static value, no longer default though ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51581&edit=1
Bug #51580 [Opn->Bgs]: socket_select randomly fails when used together with fork and Unix signals
Edit report at http://bugs.php.net/bug.php?id=51580&edit=1 ID: 51580 Updated by: m...@php.net Reported by: marco at vmsoft-gbr dot de Summary: socket_select randomly fails when used together with fork and Unix signals -Status: Open +Status: Bogus Type: Bug Package: PCNTL related Operating System: Debian Linux PHP Version: 5.3.2 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 See the restart_syscalls parameter. Previous Comments: [2010-04-17 14:50:51] marco at vmsoft-gbr dot de It doesn't crash in the literal sense, as I said before this was a mistake in word choosing. So it's technically something other than a crash, but I dunno how to properly call it. It's a bug, that's the only thing thats sure. [2010-04-17 13:46:57] paj...@php.net If it crashes then linux should be able to generate a core dump file (without gdb). You can then use it to generate a back trace. [2010-04-17 13:39:33] marco at vmsoft-gbr dot de Uh, the PHP *process* doesn't crash, so no corefile. Sorry, was bad choice of words by me. Anyway, whatever happens with socket_select there should not happen... but how to backtrace that one without an actual crash? [2010-04-17 13:23:08] paj...@php.net Can you try to generate a coredump and use it later to get a bt: http://stackoverflow.com/questions/17965/generate-a-core-dump-in-linux [2010-04-17 11:13:18] marco at vmsoft-gbr dot de just ran it under gdb, it fails as expected, but as it's not segfaulting, no backtrace can be made. 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=51580 -- Edit this bug report at http://bugs.php.net/bug.php?id=51580&edit=1
Bug #51573 [Opn->Bgs]: ctype_alpha function
Edit report at http://bugs.php.net/bug.php?id=51573&edit=1
ID: 51573
Updated by: m...@php.net
Reported by: mluster79 at yahoo dot com
Summary: ctype_alpha function
-Status: Open
+Status: Bogus
Type: Bug
Package: Strings related
Operating System: Windows XP
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
If the argument is a integer, it is treated as an ascii code.
Previous Comments:
[2010-04-16 17:45:33] mluster79 at yahoo dot com
Description:
I ran a test of numbers from -1000 to 1000. I passed the values into
'ctype_alpha', which I expected ALL output to be "Failure::xx".
However, I
receive "Success::xx" output on a variety of numbers from -125 to 255.
Test script:
---
for ($x = -1000;$x < 1000;$x++) {
echo ((ctype_alpha ($x)) ? "Success::{$x}" : "Failure::{$x}") .
PHP_EOL;
}
Expected result:
I expect to see nothing but "Failure::{xx}" all the way down.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51573&edit=1
[PHP-BUG] Bug #51799 [NEW]: FPM crashes if the include is enabled, but there are no files
From: Operating system: Linux PHP version: 5.3.2 Package: FPM related Bug Type: Bug Bug description:FPM crashes if the include is enabled, but there are no files Description: If the include configuration option is enabled, but the pool directory is empty, php-fpm crashes pretty ugly. I could manage to enable the service by creating an empty default.conf file within the fpm.d directory, but obviously this isn't the solution. The used FPM is the latest trunk indicated by php-fpm.org http://svn.php.net/repository/php/php-src/trunk/sapi/fpm. Test script: --- The include line is: include=/usr/local/zend/etc/fpm.d/*.conf r...@test-lucid:/usr/local/zend/etc/fpm.d# ls -la total 8 drwxr-sr-x 2 root zend 4096 May 12 11:59 . drwxrwsr-x 7 root zend 4096 May 12 11:59 .. r...@test-lucid:/usr/local/zend/etc/fpm.d# Expected result: To be able to start the php-fpm service just with the default pool from php-fpm.conf if fpm.d is empty. In my humble opinion the application shouldn't crash if no pattern is matched. Actual result: -- May 12 12:10:52.239695 [ERROR] Nothing match the include pattern '/usr/local/zend/etc/fpm.d/*.conf' from /usr/local/zend/etc/php-fpm.conf at line 10. The backtrace is quite useless since the error is generated by sapi/fpm/fpm/fpm_conf.c, after the glob() call. -- Edit bug report at http://bugs.php.net/bug.php?id=51799&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51799&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51799&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51799&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51799&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51799&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51799&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51799&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51799&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51799&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51799&r=support Expected behavior: http://bugs.php.net/fix.php?id=51799&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51799&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51799&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51799&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51799&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51799&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51799&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51799&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51799&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51799&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51799&r=mysqlcfg
Bug #51594 [Opn->Fbk]: open_basedir reports fatal error within allowed path
Edit report at http://bugs.php.net/bug.php?id=51594&edit=1 ID: 51594 Updated by: m...@php.net Reported by: daniel at produktion203 dot se Summary: open_basedir reports fatal error within allowed path -Status: Open +Status: Feedback Type: Bug Package: Safe Mode/open_basedir Operating System: FreeBSD 8.0-RELEASE-p2 PHP Version: 5.3.2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2010-04-22 09:32:13] daniel at produktion203 dot se Sorry but i only have live servers to work with so im not able to test this out anywhere :\ So my bugtracking help kind of ends when coming to installing new versions. But im guessing if it works for you it probably will for me too when the new version is released. [2010-04-22 02:15:07] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-04-19 00:01:37] daniel at produktion203 dot se Description: There seems to be some problem with open_basedir in php 5.3.2 for freebsd, i used the 5.2 branch before and the exact same config worked fine then. open_basedir reports failure eventhough im within the allowed paths Include paths in php.ini: include_path = ".:/usr/local/share/pear:/usr/local/lib/php/include" Testhost in apache: DocumentRoot "/home/customers/produktion203/testin.se" ServerName testin.se php_admin_value open_basedir /home/customers/produktion203/testin.se:/usr/local/share/pear:/usr/local/lib/php/include:/var/tmp Test script: --- http://bugs.php.net/bug.php?id=51594&edit=1
Bug #51506 [Opn->Fbk]: Realpath failed on linux Server for version 5.2.10 ?
Edit report at http://bugs.php.net/bug.php?id=51506&edit=1 ID: 51506 Updated by: m...@php.net Reported by: mastershepper at gmail dot com Summary: Realpath failed on linux Server for version 5.2.10 ? -Status: Open +Status: Feedback Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.2.13 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2010-04-22 22:23:06] whatrevolution at yahoo dot com Code: Result: string '/var/www/php_bugs' (length=17) string '/var/www' (length=8) string '/var' (length=4) PHP Version 5.2.10-2ubuntu6.4 System Linux 2.6.31-20-generic x86_64 Build Date Jan 6 2010 22:36:47 Server API Apache 2.0 Handler PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety disabled Zend Memory Manager enabled Apache/2.2.12 (Ubuntu) [2010-04-09 09:51:02] mastershepper at gmail dot com Hi, the php version is now up to date (5.2.13) and still have the problem. I tried many realpath(), the absloute path of the web directory ios the following one : /home/.sites/38/site52/web I thought that realpath( '/home/.sites/38/site52/web' ) should works fine, but it return me false, like any other realpath I'm asking (like realpath( '/' ) which is working well on my IIS environment). I also tried to set the include path with this line : set_include_path(get_include_path() . PATH_SEPARATOR . '/home/.sites/38/site52/web'); But it still not working fine. Is there anything I missed ? I'm probably wrong but I don't see where. Thanks for your help. [2010-04-08 11:15:41] paj...@php.net You can test locally as well, or in a VM using the same linux version that you have on your prod server. [2010-04-08 11:12:25] mastershepper at gmail dot com __FILE__ is just a test, the actuel drupal core use realpath on dynamic paths and it always return false. The actual production environment is an external one so I'm not able to change the php version. I will ask for it and update this report when it will be done (only if it could be done, unfortunately) Thanks for your help. [2010-04-08 11:02:07] paj...@php.net __FILE__ is already an absolute path, I don't see why you would do that in the 1st place. However, if you can reproduce the realpath problem with other paths as well, then I suspect a bug on your linux version. Can you try with 5.2.13 pls? 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=51506 -- Edit this bug report at http://bugs.php.net/bug.php?id=51506&edit=1
Bug #51495 [Opn->Fbk]: errors using variable variables as function arguments
Edit report at http://bugs.php.net/bug.php?id=51495&edit=1
ID: 51495
Updated by: m...@php.net
Reported by: marco at digitaldruid dot net
Summary: errors using variable variables as function arguments
-Status: Open
+Status: Feedback
Type: Bug
Package: Variables related
Operating System: linux/windows
PHP Version: 5.3.2
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2010-04-08 09:46:47] marco at digitaldruid dot net
Please note that the arguments of function mostra_menu_date are NOT
passed by reference, so I think there should be the same behaviour when
using ${"inizioperiodo".$num1} or $inizioperiodo as an argument, if they
contain the same value.
[2010-04-07 13:29:27] marco at digitaldruid dot net
Description:
This problem happens with php 5.3, on 5.2 doesn't show up. Tried on
linux (default php 5.3.2 packages from ubuntu 10.04 beta1) and windows
(php 5.3.2 from easyphp).
Sometimes when I use a variable variable (name of the variable in curly
brackets) as a function argument the script doesn't work as expected
(execution time or memory limits are reached). This happens only in a
few places in my script (most times the same function with same
arguments works fine) and in those places if I replace the variable
variables with normal variables it works normally.
Test script:
---
You can download my script from:
http://www.digitaldruid.net/download/php-residence_1.2.2.zip
Install it (mysql, postgresql or sqlite needed), once you get to "main
menu" click on "configure and customize" --> "internet templates" -->
"availability template", this page will stop loading when the affected
function is reached.
This function is called (twice) in file php-residence/crea_modelli.php
from line 215:
mostra_menu_date("./dati/selectperiodi$anno_modello.1.php","inizioperiodo$num1",${"inizioperiodo".$num1},"","",$id_utente,$tema);
echo " ".mex("al",$pag)." ";
mostra_menu_date("./dati/selectperiodi$anno_modello.1.php","fineperiodo$num1",${"fineperiodo".$num1},"","",$id_utente,$tema);
if I replace the above code with:
$inizioperiodo = ${"inizioperiodo".$num1};
$fineperiodo = ${"fineperiodo".$num1};
mostra_menu_date("./dati/selectperiodi$anno_modello.1.php","inizioperiodo$num1",$inizioperiodo,"","",$id_utente,$tema);
echo " ".mex("al",$pag)." ";
mostra_menu_date("./dati/selectperiodi$anno_modello.1.php","fineperiodo$num1",$fineperiodo,"","",$id_utente,$tema);
then the page loads fine. The function mostra_menu_date is located in
file php-residence/includes/funzioni.php
--
Edit this bug report at http://bugs.php.net/bug.php?id=51495&edit=1
Req #51127 [Opn->Ver]: $_SESSION illogical behaviour
Edit report at http://bugs.php.net/bug.php?id=51127&edit=1
ID: 51127
Updated by: m...@php.net
Reported by: asanoki at gmail dot com
Summary: $_SESSION illogical behaviour
-Status: Open
+Status: Verified
Type: Feature/Change Request
Package: Session related
Operating System: Linux
PHP Version: 5.2.12
Previous Comments:
[2010-02-23 18:56:23] asanoki at gmail dot com
Description:
No warning about using not allowed characters as a key in array
$_SESSION. It is illogical, and should raise a warning or notice.
In manual it is written that $_SESSION is a superglobal *associative
array* (http://pl.php.net/manual/pl/reserved.variables.session.php).
Additional restrictions to key names are illogical and unintuitive. Why
do a session serialization function uses diffrent algorithm than default
serialize() php function which works fine in such situations?
Example. Using | character as a key in $_SESSION array causes damaging a
session file (it gets 0 bytes length) without any notice, warning or
error.
I understand that it is mentioned in manual, but it is illogical,
unintuitive and should raise at least a warning.
Reproduce code:
---
/* Here is php code which reproduces this error. Fire it *twice*, and
look at output of a *second* execution. */
session_start();
echo "This was loaded from session:\n";
var_dump($_SESSION);
$_SESSION["a|b"] = "asdasd";
echo "\nThis is written to session:\n";
var_dump($_SESSION);
Expected result:
This was loaded from session:
array(1) { ["a|b"]=> string(6) "asdasd" }
This is written to session:
array(1) { ["a|b"]=> string(6) "asdasd" }
Actual result:
--
This was loaded from session:
array(0) { }
This is written to session:
array(1) { ["a|b"]=> string(6) "asdasd" }
--
Edit this bug report at http://bugs.php.net/bug.php?id=51127&edit=1
Bug #51448 [Opn->Fbk]: class and define problem
Edit report at http://bugs.php.net/bug.php?id=51448&edit=1
ID: 51448
Updated by: m...@php.net
Reported by: antonello dot mangone at gmail dot com
Summary: class and define problem
-Status: Open
+Status: Feedback
Type: Bug
Package: *General Issues
Operating System: Sidux
PHP Version: 5.3.2
New Comment:
This should have been marked Feedback, shouldn't it?
Previous Comments:
[2010-04-16 03:55:55] crrodriguez at opensuse dot org
Do you have any zend extension loaded ?
Provide the output of php -m
[2010-03-31 18:16:02] antonello dot mangone at gmail dot com
Description:
Using php 5.3.2-1 I tried the following code and I found probably a bug
that I don't know if it is a problem of the define function or if it's a
problem of php.
When I write the example 1, the first time the page print the echo
message in the __construct. If I refresh the page the browser try to
download or to open the php file.
If I modify something in the file or if I stop and then start the apache
web server (apache2) the previous behaviour is repeated.
The problem is related to de definition of the constant EXAMPLE and the
assignment of this constant to the attribute $variabile of the class
Test.
If as in the example 2 i define the constant EXAMPLE and then I set the
property from the __construct method the problem is bypassed, but I
think it should be solved.
Test script:
---
example 1
--
define('EXAMPLE', 0);
class Test
{
public $variabile = EXAMPLE;
public function __construct()
{
echo "instance of Test class created";
}
}
$newtest = new Test();
example 2
define('EXAMPLE', 0);
class Test
{
public $variabile = "";
public function __construct()
{
$this->variabile = EXAMPLE;
echo "instance of Test class created";
}
}
$newtest = new Test();
Expected result:
example 2
define('EXAMPLE', 0);
class Test
{
public $variabile = "";
public function __construct()
{
$this->variabile = EXAMPLE;
echo "instance of Test class created";
}
}
$newtest = new Test();
--
Edit this bug report at http://bugs.php.net/bug.php?id=51448&edit=1
Bug #51431 [Opn->Asn]: Problem with method_exists and autoloader
Edit report at http://bugs.php.net/bug.php?id=51431&edit=1
ID: 51431
Updated by: m...@php.net
Reported by: mboland at internl dot net
Summary: Problem with method_exists and autoloader
-Status: Open
+Status: Assigned
Type: Bug
Package: Reproducible crash
Operating System: Linux
PHP Version: 5.2SVN-2010-03-29 (snap)
-Assigned To:
+Assigned To: ilia
New Comment:
So I suppose this becomes a "Won't fix" unless Ilia thinks otherwise for
5.2
Previous Comments:
[2010-03-31 12:56:50] mboland at internl dot net
PHP 5.3 uses ZEND_VM_STACK_GROW_IF_NEEDED instead of
ZEND_PTR_STACK_RESIZE_IF_NEEDED to grow the argument stack, so no.
[2010-03-31 10:46:25] ka...@php.net
Does this also happens on 5.3SVN?
[2010-03-29 21:12:53] mboland at internl dot net
Bugs that are caused by a problem similar to this:-
#50360
#46753
[2010-03-29 21:11:00] mboland at internl dot net
Forgot to mention: the test script crashes with a segmentation fault.
The PHP used was built with
./configure --enable-debug
[2010-03-29 21:07:16] mboland at internl dot net
Description:
A call to method_exists may invoke a class loader. If the class loader
is complicated enough, PHP will reallocate the stack to make more room.
Once the class loader returns, PHP will then dereference a variable that
is no longer valid.
Test script:
---
0) {
recurse($i - 1);
} else {
class C { }
}
}
function autoload_function($unused) {
recurse(17);
}
spl_autoload_register('autoload_function');
method_exists('C', 'foo');
Actual result:
--
$ gdb --args ./sapi/cli/php crash.php
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
Bug #51426 [Opn->Fbk]: Glibc errors corrupted double-linked list in apache error_log
Edit report at http://bugs.php.net/bug.php?id=51426&edit=1 ID: 51426 Updated by: m...@php.net Reported by: no dot spa at o2 dot pl Summary: Glibc errors corrupted double-linked list in apache error_log -Status: Open +Status: Feedback Type: Bug Package: Apache related Operating System: Centos 5.4 PHP Version: 5.2.13 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2010-03-29 15:01:22] no dot spa at o2 dot pl Description: I see many errors in error_log. They are connected with glibc: *** glibc detected *** /usr/local/apache/bin/httpd: corrupted double-linked list: 0x093f1170 *** === Backtrace: = /lib/libc.so.6[0x989ab6] /lib/libc.so.6[0x98b4d2] /lib/libc.so.6(cfree+0x59)[0x98b9d9] /usr/local/apache/libexec/libphp5.so[0x10ab436] /usr/local/apache/libexec/libphp5.so(zend_hash_destroy+0x36)[0x12c1c26] /usr/local/apache/libexec/libphp5.so(module_destructor+0x46)[0x12bb726] /usr/local/apache/libexec/libphp5.so[0x12c1928] /usr/local/apache/libexec/libphp5.so(zend_hash_graceful_reverse_destroy+0x18)[0x12c1b68] /usr/local/apache/libexec/libphp5.so(zend_shutdown+0x1e)[0x12b81ee] /usr/local/apache/libexec/libphp5.so(php_module_shutdown+0x2f)[0x1276dcf] /usr/local/apache/libexec/libphp5.so(php_module_shutdown_wrapper+0xb)[0x1276e7b] /usr/local/apache/bin/httpd(ap_child_exit_modules+0x57)[0x809e1ad] /usr/local/apache/bin/httpd[0x80a582e] /usr/local/apache/bin/httpd[0x80a78c4] [0xa90420] /usr/local/apache/libexec/libphp5.so(zend_unregister_functions+0x5e)[0x12ba5de] /usr/local/apache/libexec/libphp5.so(module_destructor+0x6c)[0x12bb74c] /usr/local/apache/libexec/libphp5.so[0x12c1928] /usr/local/apache/libexec/libphp5.so(zend_hash_graceful_reverse_destroy+0x18)[0x12c1b68] /usr/local/apache/libexec/libphp5.so(zend_shutdown+0x1e)[0x12b81ee] /usr/local/apache/libexec/libphp5.so(php_module_shutdown+0x2f)[0x1276dcf] /usr/local/apache/libexec/libphp5.so(php_module_shutdown_wrapper+0xb)[0x1276e7b] /usr/local/apache/bin/httpd(ap_child_exit_modules+0x57)[0x809e1ad] /usr/local/apache/bin/httpd[0x80a582e] /usr/local/apache/bin/httpd[0x80a8f21] /usr/local/apache/bin/httpd[0x80a96f4] /usr/local/apache/bin/httpd[0x80a9ae2] /usr/local/apache/bin/httpd[0x80aa1b7] /usr/local/apache/bin/httpd(main+0x414)[0x80aa8a4] /lib/libc.so.6(__libc_start_main+0xdc)[0x937e9c] /usr/local/apache/bin/httpd[0x8054fd1] === Memory map: 0011-00135000 r-xp 08:07 70452064 /lib/libm-2.5.so 00135000-00136000 r--p 00024000 08:07 70452064 /lib/libm-2.5.so 00136000-00137000 rw-p 00025000 08:07 70452064 /lib/libm-2.5.so 00137000-00172000 r-xp 08:07 70452105 /lib/libsepol.so.1 00172000-00173000 rw-p 0003b000 08:07 70452105 /lib/libsepol.so.1 00173000-0017d000 rw-p 00173000 00:00 0 0017d000-001a2000 r-xp 08:07 10920055 /usr/lib/libpng12.so.0.10.0 001a2000-001a3000 rw-p 00024000 08:07 10920055 /usr/lib/libpng12.so.0.10.0 001a3000-001c4000 r-xp 08:07 10921584 /usr/lib/libjpeg.so.62.0.0 001c4000-001c5000 rw-p 0002 08:07 10921584 /usr/lib/libjpeg.so.62.0.0 001c5000-001de000 r-xp 08:07 70452107 /lib/libaudit.so.0.0.0 001de000-001e rw-p 00018000 08:07 70452107 /lib/libaudit.so.0.0.0 001e3000-001e7000 r-xp 08:07 12781080 /usr/local/apache/libexec/mod_bandwidth.so 001e7000-001ea000 rw-p 3000 08:07 12781080 /usr/local/apache/libexec/mod_bandwidth.so 00207000-0020b000 r-xp 08:07 70451290 /lib/libnss_dns-2.5.so 0020b000-0020c000 r--p 3000 08:07 70451290 /lib/libnss_dns-2.5.so 0020c000-0020d000 rw-p 4000 08:07 70451290 /lib/libnss_dns-2.5.so 0020d000-00216000 r-xp 08:07 70451292 /lib/libnss_files-2.5.so 00216000-00217000 r--p 8000 08:07 70451292 /lib/libnss_files-2.5.so 00217000-00218000 rw-p 9000 08:07 70451292 /lib/libnss_files-2.5.so 00218000-00258000 r-xp 08:07 54264728 /opt/curlssl/lib/libcurl.so.4.1.1 00258000-0025a000 rw-p 0003f000 08:07 54264728 /opt/curlssl/lib/libcurl.so.4.1.1 0025a000-0025c000 r-xp 08:07 11012369 /usr/lib/gconv/ISO8859-2.so 0025c000-0025e000 rw-p 1000 08:07 11012369 /usr/lib/gconv/ISO8859-2.so 00268000-00392000 r-xp 08:07 70451470 /lib/libcrypto.so.0.9.8e 00392000-003a5000 rw-p 00129000 08:07 70451470 /lib/libcrypto.so.0.9.8e 003a5000-003a90
[PHP-BUG] Bug #51800 [NEW]: proc_open on Windows hangs forever
From:
Operating system: Windows
PHP version: 5.2.13
Package: Streams related
Bug Type: Bug
Bug description:proc_open on Windows hangs forever
Description:
On Windows, if you use proc_open to open another process and if you use a
pipe for STDERR, the script will hang when trying to read from STDOUT or
STDERR if the opened process outputs a lot of data.
See the example below. The called script process.php is a simple script
which writes some data to STDOUT and STDERR:
$data = str_repeat("a", 1);
fwrite(STDOUT, $data);
fwrite(STDERR, $data);
exit(0);
If called as shown below, the script will hang in the loop that reads the
STDOUT pipe. The same would happen if you would read the STDERR pipe
before. If you lower the amount of data in process.php the script will run
to the end. In my tests everything below ~2000 bytes was ok, above this
value the script hang.
If you change the script below to not include the STDERR descriptor or if
you change the STDERR descriptor to a file output everything will work
fine. Also if you close the STDERR pipe before reading from STDOUT it will
work. There seems to be some deadlock.
The same script works fine on Linux.
This was tested with Windows Server 2008, IIS, PHP 5.2.13. But I have seen
this on other Windows configurations as well.
Test script:
---
array("pipe", "r"),// stdin
1 => array("pipe", "w"),// stdout
2 => array("pipe", "w") // stderr
);
$process = proc_open($cmd, $descriptors, $pipes);
if (is_resource($process))
{
fclose($pipes[0]);
while (!feof($pipes[1]))
$stdout .= fread($pipes[1], 1024);
fclose($pipes[1]);
while (!feof($pipes[2]))
$stderr .= fread($pipes[2], 1024);
fclose($pipes[2]);
$status = proc_close($process);
}
print_r(array(
"status" => $status,
"stdout" => $stdout,
"stderr" => $stderr,
));
?>
--
Edit bug report at http://bugs.php.net/bug.php?id=51800&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51800&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51800&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51800&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51800&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51800&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51800&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51800&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51800&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51800&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51800&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51800&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51800&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51800&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51800&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51800&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51800&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51800&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51800&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51800&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51800&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51800&r=mysqlcfg
Bug #51799 [Opn->Asn]: FPM crashes if the include is enabled, but there are no files
Edit report at http://bugs.php.net/bug.php?id=51799&edit=1 ID: 51799 Updated by: f...@php.net Reported by: admin at saltwaterc dot net Summary: FPM crashes if the include is enabled, but there are no files -Status: Open +Status: Assigned Type: Bug Package: FPM related Operating System: Linux PHP Version: 5.3.2 -Assigned To: +Assigned To: fat Previous Comments: [2010-05-12 15:57:31] admin at saltwaterc dot net Description: If the include configuration option is enabled, but the pool directory is empty, php-fpm crashes pretty ugly. I could manage to enable the service by creating an empty default.conf file within the fpm.d directory, but obviously this isn't the solution. The used FPM is the latest trunk indicated by php-fpm.org http://svn.php.net/repository/php/php-src/trunk/sapi/fpm. Test script: --- The include line is: include=/usr/local/zend/etc/fpm.d/*.conf r...@test-lucid:/usr/local/zend/etc/fpm.d# ls -la total 8 drwxr-sr-x 2 root zend 4096 May 12 11:59 . drwxrwsr-x 7 root zend 4096 May 12 11:59 .. r...@test-lucid:/usr/local/zend/etc/fpm.d# Expected result: To be able to start the php-fpm service just with the default pool from php-fpm.conf if fpm.d is empty. In my humble opinion the application shouldn't crash if no pattern is matched. Actual result: -- May 12 12:10:52.239695 [ERROR] Nothing match the include pattern '/usr/local/zend/etc/fpm.d/*.conf' from /usr/local/zend/etc/php-fpm.conf at line 10. The backtrace is quite useless since the error is generated by sapi/fpm/fpm/fpm_conf.c, after the glob() call. -- Edit this bug report at http://bugs.php.net/bug.php?id=51799&edit=1
Bug #51709 [Opn->Bgs]: Naming a class method using a reserved keyword causes a parser error
Edit report at http://bugs.php.net/bug.php?id=51709&edit=1 ID: 51709 Updated by: s...@php.net Reported by: razvan dot gavril at gmail dot com Summary: Naming a class method using a reserved keyword causes a parser error -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Ubuntu 10.04 LTS PHP Version: 5.3.2 New Comment: I don't know what your "previous" version was, but the same error occurs with PHP 5.1.6 so this has been a language feature for a very long time. Also see http://bugs.php.net/51782 about the introduction of new keywords in recent versions. Previous Comments: [2010-04-30 22:33:12] razvan dot gavril at gmail dot com Description: Is no longer possible to name a class methods using names that are reserved keywords like : 'break', 'for', 'goto'. It used to work with previous php versions. If this is a 'feature', what's the point ? Test script: --- http://bugs.php.net/bug.php?id=51709&edit=1
Bug #51796 [Opn]: Memory leak when executing SQL "EXEC" statements
Edit report at http://bugs.php.net/bug.php?id=51796&edit=1
ID: 51796
Updated by: s...@php.net
Reported by: J dot Antonio at jaruz dot com
Summary: Memory leak when executing SQL "EXEC" statements
Status: Open
Type: Bug
Package: PDO related
Operating System: Ubuntu 10.04 LTS
PHP Version: 5.3.2
New Comment:
For reference, there are some pdo_dblib patches mentioned in
http://bugs.php.net/50755
Previous Comments:
[2010-05-11 17:50:44] J dot Antonio at jaruz dot com
I forgot to mention this is using PDO_DBLIB.
[2010-05-11 17:48:35] J dot Antonio at jaruz dot com
Description:
On Linux, using PHP 5.3.2-1ubuntu4 with Suhosin-Patch (cli) and FreeTDS
0.82-6build1 (it's a vanilla lucid install, fully up to date):
When executing stored procedures using the "EXEC" SQL statement, both
PDOStatement->execute as well as PDO::query seem to have a memory leak.
We found this while executing a stored procedure within a loop: memory
usage just kept increasing till the memory limit was reached.
Unsetting/nullyfing variables does not help.
The leak is not present (memory usage stays perfectly constant) when
using a "SELECT" SQL statement (which returns the exact same results as
the stored procedure).
I have a feeling PDO is maybe only clearing the memory when it deals
with a "SELECT" statement, and it misses the fact that data can also
come back through "EXEC" statements?
This bug might be slightly related to bug 50755.
Test script:
---
// $polyItemArray is populated with a list of 300 IDs (integers).
// We loop through the array, and execute a stored procedure during each
iteration:
foreach( $polyItemArray as $polyItemKey => $polyItem) {
echo date('H:i:s') . ' | Processing: ' . $polyItem['sgp_id'];
$dbh->query('EXEC proc_map_get_sgp_polygons ' . $polyItem['sgp_id'],
PDO::FETCH_ASSOC);
/*
// Alternate way of calling the procedure using PDOStatement;
same leak is present:
$stmt = $dbh->prepare($sql);
$stmt->setFetchMode(PDO::FETCH_ASSOC);
$stmt->execute( array($polyItem['sgp_id']) );
$stmt->closeCursor();
unset($stmt);
*/
unset($polyItemKey);
unset($polyItem);
echo ' memory usage: ' . memory_get_usage(). ' bytes'. PHP_EOL;
}
// When running the script, memory usage just keeps increasing.
Expected result:
I would expect the memory usage of the script to stay constant.
Actual result:
--
Memory usage just keeps increasing.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51796&edit=1
Bug #51796 [Opn->Fbk]: Memory leak when executing SQL "EXEC" statements
Edit report at http://bugs.php.net/bug.php?id=51796&edit=1
ID: 51796
Updated by: s...@php.net
Reported by: J dot Antonio at jaruz dot com
Summary: Memory leak when executing SQL "EXEC" statements
-Status: Open
+Status: Feedback
Type: Bug
Package: PDO related
Operating System: Ubuntu 10.04 LTS
PHP Version: 5.3.2
New Comment:
Try the patches and see if your bug is a duplicate.
Previous Comments:
[2010-05-12 18:41:32] s...@php.net
For reference, there are some pdo_dblib patches mentioned in
http://bugs.php.net/50755
[2010-05-11 17:50:44] J dot Antonio at jaruz dot com
I forgot to mention this is using PDO_DBLIB.
[2010-05-11 17:48:35] J dot Antonio at jaruz dot com
Description:
On Linux, using PHP 5.3.2-1ubuntu4 with Suhosin-Patch (cli) and FreeTDS
0.82-6build1 (it's a vanilla lucid install, fully up to date):
When executing stored procedures using the "EXEC" SQL statement, both
PDOStatement->execute as well as PDO::query seem to have a memory leak.
We found this while executing a stored procedure within a loop: memory
usage just kept increasing till the memory limit was reached.
Unsetting/nullyfing variables does not help.
The leak is not present (memory usage stays perfectly constant) when
using a "SELECT" SQL statement (which returns the exact same results as
the stored procedure).
I have a feeling PDO is maybe only clearing the memory when it deals
with a "SELECT" statement, and it misses the fact that data can also
come back through "EXEC" statements?
This bug might be slightly related to bug 50755.
Test script:
---
// $polyItemArray is populated with a list of 300 IDs (integers).
// We loop through the array, and execute a stored procedure during each
iteration:
foreach( $polyItemArray as $polyItemKey => $polyItem) {
echo date('H:i:s') . ' | Processing: ' . $polyItem['sgp_id'];
$dbh->query('EXEC proc_map_get_sgp_polygons ' . $polyItem['sgp_id'],
PDO::FETCH_ASSOC);
/*
// Alternate way of calling the procedure using PDOStatement;
same leak is present:
$stmt = $dbh->prepare($sql);
$stmt->setFetchMode(PDO::FETCH_ASSOC);
$stmt->execute( array($polyItem['sgp_id']) );
$stmt->closeCursor();
unset($stmt);
*/
unset($polyItemKey);
unset($polyItem);
echo ' memory usage: ' . memory_get_usage(). ' bytes'. PHP_EOL;
}
// When running the script, memory usage just keeps increasing.
Expected result:
I would expect the memory usage of the script to stay constant.
Actual result:
--
Memory usage just keeps increasing.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51796&edit=1
Bug #51709 [Bgs]: Naming a class method using a reserved keyword causes a parser error
Edit report at http://bugs.php.net/bug.php?id=51709&edit=1 ID: 51709 User updated by: razvan dot gavril at gmail dot com Reported by: razvan dot gavril at gmail dot com Summary: Naming a class method using a reserved keyword causes a parser error Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Ubuntu 10.04 LTS PHP Version: 5.3.2 New Comment: Strange, I've notice the bug after updating from Ubuntu karmic. Looking now at the package.ubuntu.com I see that karmic came with php 5.2.10 I'm 100% sure that I didn't had this bug before the update Previous Comments: [2010-05-12 18:37:27] s...@php.net I don't know what your "previous" version was, but the same error occurs with PHP 5.1.6 so this has been a language feature for a very long time. Also see http://bugs.php.net/51782 about the introduction of new keywords in recent versions. [2010-04-30 22:33:12] razvan dot gavril at gmail dot com Description: Is no longer possible to name a class methods using names that are reserved keywords like : 'break', 'for', 'goto'. It used to work with previous php versions. If this is a 'feature', what's the point ? Test script: --- http://bugs.php.net/bug.php?id=51709&edit=1
Bug #51778 [Fbk->Opn]: crash on libphp5.so, when running ampache's initial scripts
Edit report at http://bugs.php.net/bug.php?id=51778&edit=1
ID: 51778
User updated by: nkostis at gmail dot com
Reported by: nkostis at gmail dot com
Summary: crash on libphp5.so, when running ampache's initial
scripts
-Status: Feedback
+Status: Open
Type: Bug
Package: Apache2 related
Operating System: plugapps (arch linux)
PHP Version: 5.2.13
New Comment:
Ok, this script works:
while this one crashes apache (with the same stack trace as initially
posted):
Finally if i run the same script without an argument passed for
dirname:
php issues an error, but there's no crash.
This implies stack corruption and compiler problems, but calling:
$row_classes = array('even', 'odd');
doesn't crash apache.
any ideas? is this helpful at all?
Previous Comments:
[2010-05-12 09:09:38] m...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2010-05-09 23:06:53] nkostis at gmail dot com
Description:
I get this core dump when running anything from ampache (test.php,
index.php,
install.php, any ampache version):
#0 0x406300a8 in _zval_ptr_dtor () from /etc/httpd/modules/libphp5.so
#1 0x40660624 in zend_do_fcall_common_helper_SPEC () from
/etc/httpd/modules/libphp5.so
#2 0x4065dec8 in execute () from /etc/httpd/modules/libphp5.so
the rest of the stack trace is unknown as LAMP runs on limited hardware
(the
pogoplug) and i have not install debug symbols.
Pogoplug currently runs plugapps, an arm optimized version of Arch
linux. I am
not sure whether this crash is a vanilla php bug or a plugapps php
issue.
A basic "phpinfo()" script runs fine so at least basic php operation is
properly
configured.
Sorry if the bug is not vanilla php and i'm wasting your time.
Test script:
---
any ampache script, i.e. test.php (http://pastebin.com/FXAtKNyJ), run on
plugbox linux (arch 2.6.33 based)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51778&edit=1
Bug #51709 [Com]: Naming a class method using a reserved keyword causes a parser error
Edit report at http://bugs.php.net/bug.php?id=51709&edit=1 ID: 51709 Comment by: razvan dot gavril at gmail dot com Reported by: razvan dot gavril at gmail dot com Summary: Naming a class method using a reserved keyword causes a parser error Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Ubuntu 10.04 LTS PHP Version: 5.3.2 New Comment: I notice that the other bug you've pointed me to, states that the problem happens starting with version 5.3.2 also. Previous Comments: [2010-05-12 19:05:24] razvan dot gavril at gmail dot com Strange, I've notice the bug after updating from Ubuntu karmic. Looking now at the package.ubuntu.com I see that karmic came with php 5.2.10 I'm 100% sure that I didn't had this bug before the update [2010-05-12 18:37:27] s...@php.net I don't know what your "previous" version was, but the same error occurs with PHP 5.1.6 so this has been a language feature for a very long time. Also see http://bugs.php.net/51782 about the introduction of new keywords in recent versions. [2010-04-30 22:33:12] razvan dot gavril at gmail dot com Description: Is no longer possible to name a class methods using names that are reserved keywords like : 'break', 'for', 'goto'. It used to work with previous php versions. If this is a 'feature', what's the point ? Test script: --- http://bugs.php.net/bug.php?id=51709&edit=1
Bug #49349 [Com]: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)
Edit report at http://bugs.php.net/bug.php?id=49349&edit=1 ID: 49349 Comment by: jasonsmith at yahoo dot com Reported by: raulsalitrero at gmail dot com Summary: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors) Status: Assigned Type: Bug Package: Gettext related Operating System: win32 only - windows xp sp3 PHP Version: 5.3.0 Assigned To: pajoye New Comment: Is there a release date for 5.3.3? Previous Comments: [2010-05-12 06:46:16] viii at iinet dot net dot au Windows Server 2008 R2 x64 with IIS 7.5 PHP 5.3.0, 5.3.2 Locale is English (Australian). Trying to get English (United States) to work. have ./locale/en_AU/LC_MESSAGES/messages.mo ./locale/en_US/LC_MESSAGES/messages.mo Always get the default (Australian) You stated: "The work around is explained in this report." So, but this escapes me. Where is the workaround? I have read this thread several times. Question: why does _SERVER["HTTP_ACCEPT_LANGUAGE"] have en-AU and not en_AU??? Or is this just a silly Winblows thing. [2010-05-06 09:20:47] paj...@php.net The work around is explained in this report. And yes, there will be a 5.3.3 which will have the fix in the library used by gettext. [2010-05-06 06:00:32] scott at etw dot ca Is there a release date for 5.3.3? Spent the last few months building a project in 5.3 and my final steps was to add language support which i cant do with gettext due to this bug, and to revert to 5.2x would require other major code changes [2010-05-05 12:12:39] sjake_it at hotmail dot com Same problem here with Windows Server 2003 SP2. This bug prevents me from upgrading to php 5.3.x It's been 8 months now so I hope this bug will be fixed quickly now. [2010-04-19 02:00:08] egorinsk at gmail dot com Hi, the same problem here with Windows XP SP2 and PHP 5.3.1 . In PHP 5.2, setlocale() call failed, but gettext() used information from LANG, LC_ALL and LANGUAGE variables. That was good, because I could use putenv() to change gettext() language on Windows and setlocale() on Linux. But now setlocale() on Windows fails, and gettext() always uses system locale, and messages are not translated. Actually, I don't need locales, they only bring problems, I'd prefer to always set it to POSIX locale to get consistent behaviour independent from server setup, but gettext() requires to use it :( The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49349 -- Edit this bug report at http://bugs.php.net/bug.php?id=49349&edit=1
Bug #49349 [Asn]: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)
Edit report at http://bugs.php.net/bug.php?id=49349&edit=1 ID: 49349 Updated by: paj...@php.net Reported by: raulsalitrero at gmail dot com Summary: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors) Status: Assigned Type: Bug Package: Gettext related Operating System: win32 only - windows xp sp3 PHP Version: 5.3.0 Assigned To: pajoye New Comment: No release date yet. Please, don't add other cases as the issue has been identified, clearly. Previous Comments: [2010-05-12 19:14:18] jasonsmith at yahoo dot com Is there a release date for 5.3.3? [2010-05-12 06:46:16] viii at iinet dot net dot au Windows Server 2008 R2 x64 with IIS 7.5 PHP 5.3.0, 5.3.2 Locale is English (Australian). Trying to get English (United States) to work. have ./locale/en_AU/LC_MESSAGES/messages.mo ./locale/en_US/LC_MESSAGES/messages.mo Always get the default (Australian) You stated: "The work around is explained in this report." So, but this escapes me. Where is the workaround? I have read this thread several times. Question: why does _SERVER["HTTP_ACCEPT_LANGUAGE"] have en-AU and not en_AU??? Or is this just a silly Winblows thing. [2010-05-06 09:20:47] paj...@php.net The work around is explained in this report. And yes, there will be a 5.3.3 which will have the fix in the library used by gettext. [2010-05-06 06:00:32] scott at etw dot ca Is there a release date for 5.3.3? Spent the last few months building a project in 5.3 and my final steps was to add language support which i cant do with gettext due to this bug, and to revert to 5.2x would require other major code changes [2010-05-05 12:12:39] sjake_it at hotmail dot com Same problem here with Windows Server 2003 SP2. This bug prevents me from upgrading to php 5.3.x It's been 8 months now so I hope this bug will be fixed quickly now. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49349 -- Edit this bug report at http://bugs.php.net/bug.php?id=49349&edit=1
Bug->Req #51777 [Fbk->Opn]: RegEx matching fails
Edit report at http://bugs.php.net/bug.php?id=51777&edit=1
ID: 51777
User updated by: trevor at ridgebizdev dot com
Reported by: trevor at ridgebizdev dot com
Summary: RegEx matching fails
-Status: Feedback
+Status: Open
-Type: Bug
+Type: Feature/Change Request
Package: PCRE related
-Operating System: Windows XP and Linux Server
+Operating System: Windows XP
PHP Version: 5.3.2
New Comment:
[Pcre]
;PCRE library backtracking limit.
; http://php.net/pcre.backtrack-limit
;pcre.backtrack_limit=10
;PCRE library recursion limit.
;Please note that if you set this value to a high number you may consume
all
;the available process stack and eventually crash PHP (due to reaching
the
;stack size limit imposed by the Operating System).
; http://php.net/pcre.recursion-limit
;pcre.recursion_limit=10
I have nothing set (I must be using the default). I use Windows XP
Professional with 4GB RAM and Core2Duo.
Previous Comments:
[2010-05-12 09:14:13] m...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works here. Do you have a pcre.backtrack_limit set?
[2010-05-09 18:36:54] trevor at ridgebizdev dot com
Description:
When a RegEx "looks" over ~32768 times during a successful match, every
RegEx function fails and returns the empty string.
Test script:
---
http://www.travelocity.com";);
// no problem with these first 2 RegExs
$response2 = preg_replace('/\s+/'," ",$response);
$mytitle =
preg_replace('/.*?<\s*title\s*>([^<]*)<.*/i','${1}',$response2);
echo "\nTitle Match Forward: ".$mytitle."\n\n";
// now, here's a problem
$mytitle2 =
preg_replace('/.*<\s*title\s*>([^<]*)<.*/i','${1}',$response2);
echo "\nTitle Match Backward: ".$mytitle2."\n\n";
?>
Expected result:
$mytitle gets extracted properly and echoed because the RegEx never
looks more than 32768 times starting at the beginning of the
travelocity.com page source. $mytitle2 never gets extracted because the
RegEx looks more than 32768 times successfully and preg_replace()
crashes into the empty string. Matching forward for the title is
working; matching backward for the title is failing for large buffers.
Actual result:
--
Title Match Forward: Travelocity Travel: Airline Tickets, Hotels,
Flights, Vacations, Cruises & Car Rentals
Title Match Backward:
--
Edit this bug report at http://bugs.php.net/bug.php?id=51777&edit=1
Bug #51758 [Fbk]: zend_object_handlers.h prescribes incorrect behavior of write property handler
Edit report at http://bugs.php.net/bug.php?id=51758&edit=1
ID: 51758
Updated by: cataphr...@php.net
Reported by: cataphr...@php.net
Summary: zend_object_handlers.h prescribes incorrect behavior
of write property handler
Status: Feedback
Type: Bug
Package: Class/Object related
Operating System: Not applicable
PHP Version: 5.3.2
New Comment:
Usually in zend_object.properties hash table. This is the code executed
if the hash table lookup is successful (otherwise there's a fallback to
__set) and the zval* stored is different from the one passed:
if (PZVAL_IS_REF(*variable_ptr)) {
zval garbage = **variable_ptr; /* old value should be destroyed */
/* To check: can't *variable_ptr be some system variable like
error_zval here? */
Z_TYPE_PP(variable_ptr) = Z_TYPE_P(value);
(*variable_ptr)->value = value->value;
if (Z_REFCOUNT_P(value) > 0) {
zval_copy_ctor(*variable_ptr);
}
zval_dtor(&garbage);
} else {
zval *garbage = *variable_ptr;
/* if we assign referenced variable, we should separate it */
Z_ADDREF_P(value);
if (PZVAL_IS_REF(value)) {
SEPARATE_ZVAL(&value);
}
*variable_ptr = value;
zval_ptr_dtor(&garbage);
}
As you can see, the reference count is changed.
Previous Comments:
[2010-05-12 09:39:57] m...@php.net
Where's the value modified in zend_std_weite_property()?
[2010-05-06 20:47:08] cataphr...@php.net
I also have some doubts about the accuracy of the first part (you may
only modify it if its reference count is 1). Why 1? Since
zend_std_write_property increments the refcount before storing the zval
in the hash table, it would make more sense if it read "...its reference
count is 0". Together with issue raised in body of the bug report, it
makes me think perhaps this comment was written thinking the refcount
would be incremented before the call to write_property.
[2010-05-06 20:40:04] cataphr...@php.net
Description:
zend_object_handler.h reads (line 39):
/* The following rule applies to write_property() and write_dimension()
implementations:
If you receive a value zval in write_property/write_dimension, you
may only modify it if
its reference count is 1. Otherwise, you must create a copy of that
zval before making
any changes. You should NOT modify the reference count of the value
passed to you. */
Perhaps I'm reading the last phrase out of context, but
zend_std_write_property() changes the reference count of the passed
value in multiple places.
Test script:
---
Not applicable.
Expected result:
Expected either no prescription for the refcount of the passed value not
to be changed or the refcount of the passed value actually not be
changed.
Actual result:
--
The implementation and the header prescription are inconsistent.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51758&edit=1
Bug #51758 [Fbk]: zend_object_handlers.h prescribes incorrect behavior of write property handler
Edit report at http://bugs.php.net/bug.php?id=51758&edit=1
ID: 51758
Updated by: cataphr...@php.net
Reported by: cataphr...@php.net
Summary: zend_object_handlers.h prescribes incorrect behavior
of write property handler
Status: Feedback
Type: Bug
Package: Class/Object related
Operating System: Not applicable
PHP Version: 5.3.2
New Comment:
Well, re-reading I think I misread your question. So to be clear:
The comment reads:
«You should NOT modify the reference count of the value passed to
you»
zend_std_write_property() changes the the reference count of the passed
"value" zval if
1. the property already exists in the object properties hash table or it
doesn't exist but there is no __set magic
2. the value stored (if any) is not the same as the "value" passed
3. the value passed is not a reference, or at least, if it is, its
refcount is 1
The call to __set itself may modify the refcount of "value".
Previous Comments:
[2010-05-12 20:11:05] cataphr...@php.net
Usually in zend_object.properties hash table. This is the code executed
if the hash table lookup is successful (otherwise there's a fallback to
__set) and the zval* stored is different from the one passed:
if (PZVAL_IS_REF(*variable_ptr)) {
zval garbage = **variable_ptr; /* old value should be destroyed */
/* To check: can't *variable_ptr be some system variable like
error_zval here? */
Z_TYPE_PP(variable_ptr) = Z_TYPE_P(value);
(*variable_ptr)->value = value->value;
if (Z_REFCOUNT_P(value) > 0) {
zval_copy_ctor(*variable_ptr);
}
zval_dtor(&garbage);
} else {
zval *garbage = *variable_ptr;
/* if we assign referenced variable, we should separate it */
Z_ADDREF_P(value);
if (PZVAL_IS_REF(value)) {
SEPARATE_ZVAL(&value);
}
*variable_ptr = value;
zval_ptr_dtor(&garbage);
}
As you can see, the reference count is changed.
[2010-05-12 09:39:57] m...@php.net
Where's the value modified in zend_std_weite_property()?
[2010-05-06 20:47:08] cataphr...@php.net
I also have some doubts about the accuracy of the first part (you may
only modify it if its reference count is 1). Why 1? Since
zend_std_write_property increments the refcount before storing the zval
in the hash table, it would make more sense if it read "...its reference
count is 0". Together with issue raised in body of the bug report, it
makes me think perhaps this comment was written thinking the refcount
would be incremented before the call to write_property.
[2010-05-06 20:40:04] cataphr...@php.net
Description:
zend_object_handler.h reads (line 39):
/* The following rule applies to write_property() and write_dimension()
implementations:
If you receive a value zval in write_property/write_dimension, you
may only modify it if
its reference count is 1. Otherwise, you must create a copy of that
zval before making
any changes. You should NOT modify the reference count of the value
passed to you. */
Perhaps I'm reading the last phrase out of context, but
zend_std_write_property() changes the reference count of the passed
value in multiple places.
Test script:
---
Not applicable.
Expected result:
Expected either no prescription for the refcount of the passed value not
to be changed or the refcount of the passed value actually not be
changed.
Actual result:
--
The implementation and the header prescription are inconsistent.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51758&edit=1
Bug #51799 [Asn->Csd]: FPM crashes if the include is enabled, but there are no files
Edit report at http://bugs.php.net/bug.php?id=51799&edit=1 ID: 51799 Updated by: f...@php.net Reported by: admin at saltwaterc dot net Summary: FPM crashes if the include is enabled, but there are no files -Status: Assigned +Status: Closed Type: Bug Package: FPM related Operating System: Linux PHP Version: 5.3.2 Assigned To: fat New Comment: This bug has been corrected in revision 299302. When glob() returns GLOB_NOMATCH, the log message has been changed from ERROR to WARNING and FPM continues to parse the conf file without stopping. Previous Comments: [2010-05-12 20:29:11] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=299302 Log: Fix #51799, when glob returns nothing, it was handle as an error instead of a warning. [2010-05-12 15:57:31] admin at saltwaterc dot net Description: If the include configuration option is enabled, but the pool directory is empty, php-fpm crashes pretty ugly. I could manage to enable the service by creating an empty default.conf file within the fpm.d directory, but obviously this isn't the solution. The used FPM is the latest trunk indicated by php-fpm.org http://svn.php.net/repository/php/php-src/trunk/sapi/fpm. Test script: --- The include line is: include=/usr/local/zend/etc/fpm.d/*.conf r...@test-lucid:/usr/local/zend/etc/fpm.d# ls -la total 8 drwxr-sr-x 2 root zend 4096 May 12 11:59 . drwxrwsr-x 7 root zend 4096 May 12 11:59 .. r...@test-lucid:/usr/local/zend/etc/fpm.d# Expected result: To be able to start the php-fpm service just with the default pool from php-fpm.conf if fpm.d is empty. In my humble opinion the application shouldn't crash if no pattern is matched. Actual result: -- May 12 12:10:52.239695 [ERROR] Nothing match the include pattern '/usr/local/zend/etc/fpm.d/*.conf' from /usr/local/zend/etc/php-fpm.conf at line 10. The backtrace is quite useless since the error is generated by sapi/fpm/fpm/fpm_conf.c, after the glob() call. -- Edit this bug report at http://bugs.php.net/bug.php?id=51799&edit=1
Bug #51758 [Fbk->Opn]: zend_object_handlers.h prescribes incorrect behavior of write property handler
Edit report at http://bugs.php.net/bug.php?id=51758&edit=1
ID: 51758
Updated by: cataphr...@php.net
Reported by: cataphr...@php.net
Summary: zend_object_handlers.h prescribes incorrect behavior
of write property handler
-Status: Feedback
+Status: Open
Type: Bug
Package: Class/Object related
Operating System: Not applicable
PHP Version: 5.3.2
Previous Comments:
[2010-05-12 20:31:13] cataphr...@php.net
Well, re-reading I think I misread your question. So to be clear:
The comment reads:
«You should NOT modify the reference count of the value passed to
you»
zend_std_write_property() changes the the reference count of the passed
"value" zval if
1. the property already exists in the object properties hash table or it
doesn't exist but there is no __set magic
2. the value stored (if any) is not the same as the "value" passed
3. the value passed is not a reference, or at least, if it is, its
refcount is 1
The call to __set itself may modify the refcount of "value".
[2010-05-12 20:11:05] cataphr...@php.net
Usually in zend_object.properties hash table. This is the code executed
if the hash table lookup is successful (otherwise there's a fallback to
__set) and the zval* stored is different from the one passed:
if (PZVAL_IS_REF(*variable_ptr)) {
zval garbage = **variable_ptr; /* old value should be destroyed */
/* To check: can't *variable_ptr be some system variable like
error_zval here? */
Z_TYPE_PP(variable_ptr) = Z_TYPE_P(value);
(*variable_ptr)->value = value->value;
if (Z_REFCOUNT_P(value) > 0) {
zval_copy_ctor(*variable_ptr);
}
zval_dtor(&garbage);
} else {
zval *garbage = *variable_ptr;
/* if we assign referenced variable, we should separate it */
Z_ADDREF_P(value);
if (PZVAL_IS_REF(value)) {
SEPARATE_ZVAL(&value);
}
*variable_ptr = value;
zval_ptr_dtor(&garbage);
}
As you can see, the reference count is changed.
[2010-05-12 09:39:57] m...@php.net
Where's the value modified in zend_std_weite_property()?
[2010-05-06 20:47:08] cataphr...@php.net
I also have some doubts about the accuracy of the first part (you may
only modify it if its reference count is 1). Why 1? Since
zend_std_write_property increments the refcount before storing the zval
in the hash table, it would make more sense if it read "...its reference
count is 0". Together with issue raised in body of the bug report, it
makes me think perhaps this comment was written thinking the refcount
would be incremented before the call to write_property.
[2010-05-06 20:40:04] cataphr...@php.net
Description:
zend_object_handler.h reads (line 39):
/* The following rule applies to write_property() and write_dimension()
implementations:
If you receive a value zval in write_property/write_dimension, you
may only modify it if
its reference count is 1. Otherwise, you must create a copy of that
zval before making
any changes. You should NOT modify the reference count of the value
passed to you. */
Perhaps I'm reading the last phrase out of context, but
zend_std_write_property() changes the reference count of the passed
value in multiple places.
Test script:
---
Not applicable.
Expected result:
Expected either no prescription for the refcount of the passed value not
to be changed or the refcount of the passed value actually not be
changed.
Actual result:
--
The implementation and the header prescription are inconsistent.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51758&edit=1
[PHP-BUG] Bug #51802 [NEW]: PHP temp files not deleted when also using a CGI script
From:
Operating system: Windows Server 2003
PHP version: 5.2.13
Package: CGI related
Bug Type: Bug
Bug description:PHP temp files not deleted when also using a CGI script
Description:
This bug is very specific to Windows. When executing a generic file upload
using PHP, if at anytime while the file is being uploaded Apache then runs
a CGI script like PERL or a C program, and the upload ends while the CGI
script is still running, the uploaded file(s) in the temp directory will
remain behind forever.
In order to avoid this the âphp_do_open_temporary_fileâ routine will
have to not use the âVCWD_OPEN_MODEâ routine to open the temp file. A
generic Windows âopenâ call allows child processes to inherit their
handles. The temp file would need to be opened with a âCreateFileâ
call to open the file and specify the pSecurityAttributes option with
bInheritHandle set to FALSE so that a child process will not inherit the
open file handle. The rub is this call uses a non-compatible handle so
everyone who uses this handle has to be modified as well.
Test script:
---
Write or use any simple PHP upload program. Next use CGI program below --
it doesn't need to do anything except take time. So start the PHP upload,
then start the CGI program below from a webpage. Make sure the PHP upload
completes before the script ends.
#include
void main(){
Sleep(2*60*1000); // sleep 2 minutes
}
Expected result:
The file should be uploaded and the temp file in the temp directory should
not be present when done. It should be moved to the destination directory.
Actual result:
--
The temp file remains forever in the temp directory, though the file is
copied correctly to the destination directory.
--
Edit bug report at http://bugs.php.net/bug.php?id=51802&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51802&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51802&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51802&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51802&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51802&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51802&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51802&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51802&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51802&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51802&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51802&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51802&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51802&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51802&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51802&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51802&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51802&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51802&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51802&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51802&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51802&r=mysqlcfg
Bug #50584 [Asn->Csd]: Windows installer does not configure Apache in silent mode
Edit report at http://bugs.php.net/bug.php?id=50584&edit=1 ID: 50584 Updated by: jmer...@php.net Reported by: mkucej at yahoo dot com Summary: Windows installer does not configure Apache in silent mode -Status: Assigned +Status: Closed Type: Bug Package: Windows Installer Operating System: Windows XP SP2 PHP Version: 5.3.1 Assigned To: jmertic New Comment: Fixed issues in SVN of this happening both when configuring Apache or IIS via the command line installer. Previous Comments: [2010-05-12 21:18:24] jmer...@php.net Automatic comment from SVN on behalf of jmertic Revision: http://svn.php.net/viewvc/?view=revision&revision=299304 Log: Bug #50584 - Fix problem with expecting newly created registry values to be available in the VB installer scripts by instead passing those values to the custom action via CustomActionData property. [2010-04-04 05:45:53] mkucej at yahoo dot com This problem persists in the 5.3.2 installer. Anybody cares? [2009-12-26 23:52:13] mkucej at yahoo dot com Description: Windows installer does not configure Apache in silent mode. It will insert the following into the httpd.conf: #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL This happens only in the silent mode. Reproduce code: --- msiexec /I php.msi /qn+ INSTALLDIR="C:\Program Files\PHP" APACHEDIR="C:\Program Files\Apache Software Foundation\Apache2.2\conf\" ADDLOCAL=ScriptExecutable,cgi,apache22,ext_php_pdo_sqlite /L c:\log.txt Actual result: -- #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL -- Edit this bug report at http://bugs.php.net/bug.php?id=50584&edit=1
[PHP-BUG] Bug #51803 [NEW]: Interface implementation silently fails
From: Operating system: Windows XP SP3 PHP version: 5.3.2 Package: Reproducible crash Bug Type: Bug Bug description:Interface implementation silently fails Description: Running the test script, PHP silently exists with the error code 255. If you remove the protected access type from the _test() function in the MyClass class, the script executes normally. Test script: --- http://bugs.php.net/bug.php?id=51803&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51803&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51803&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51803&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51803&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51803&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51803&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51803&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51803&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51803&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51803&r=support Expected behavior: http://bugs.php.net/fix.php?id=51803&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51803&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51803&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51803&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51803&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51803&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51803&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51803&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51803&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51803&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51803&r=mysqlcfg
Bug #51803 [Opn->Fbk]: Interface implementation silently fails
Edit report at http://bugs.php.net/bug.php?id=51803&edit=1 ID: 51803 Updated by: dtajchre...@php.net Reported by: kherge at me dot com Summary: Interface implementation silently fails -Status: Open +Status: Feedback Type: Bug Package: Reproducible crash Operating System: Windows XP SP3 PHP Version: 5.3.2 New Comment: Do you have error reporting settings at the right level.. display errors? I get a nice fatal error as expected.. da...@beirut:~$ php test.php PHP Fatal error: Access level to MyClass::_test() must be public (as in class MyInterface) in /home/david/test.php on line 9 Fatal error: Access level to MyClass::_test() must be public (as in class MyInterface) in /home/david/test.php on line 9 da...@beirut:~$ echo $? 255 Previous Comments: [2010-05-12 21:55:55] kherge at me dot com Description: Running the test script, PHP silently exists with the error code 255. If you remove the protected access type from the _test() function in the MyClass class, the script executes normally. Test script: --- http://bugs.php.net/bug.php?id=51803&edit=1
Bug #51803 [Com]: Interface implementation silently fails
Edit report at http://bugs.php.net/bug.php?id=51803&edit=1 ID: 51803 Comment by: kherge at me dot com Reported by: kherge at me dot com Summary: Interface implementation silently fails Status: Feedback Type: Bug Package: Reproducible crash Operating System: Windows XP SP3 PHP Version: 5.3.2 New Comment: Error reporting is currently set to 32767 (E_ALL | E_STRICT). Previous Comments: [2010-05-12 22:05:32] dtajchre...@php.net Do you have error reporting settings at the right level.. display errors? I get a nice fatal error as expected.. da...@beirut:~$ php test.php PHP Fatal error: Access level to MyClass::_test() must be public (as in class MyInterface) in /home/david/test.php on line 9 Fatal error: Access level to MyClass::_test() must be public (as in class MyInterface) in /home/david/test.php on line 9 da...@beirut:~$ echo $? 255 [2010-05-12 21:55:55] kherge at me dot com Description: Running the test script, PHP silently exists with the error code 255. If you remove the protected access type from the _test() function in the MyClass class, the script executes normally. Test script: --- http://bugs.php.net/bug.php?id=51803&edit=1
Bug #51803 [Fbk]: Interface implementation silently fails
Edit report at http://bugs.php.net/bug.php?id=51803&edit=1
ID: 51803
Updated by: dtajchre...@php.net
Reported by: kherge at me dot com
Summary: Interface implementation silently fails
Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Windows XP SP3
PHP Version: 5.3.2
New Comment:
Ditto on reproducing it.
C:\Documents and Settings\David\Desktop\php-5.3.2-Win32-VC6-x86>php
..\test.php
Fatal error: Access level to MyClass::_test() must be public (as in
class MyInte
rface) in C:\Documents and Settings\David\Desktop\test.php on line 9
C:\Documents and Settings\David\Desktop\php-5.3.2-Win32-VC6-x86>echo
%ERRORLEVEL%
255
I think it's a configuration issue on your end. Check your error
log/display error settings. Your class has to implement the method the
way that the interface describes it. Your interface defaults to public
for _test() and test() but you alter that.. a simpler test case:
class A implements Iterator {
private function next() { }
}
should yield the same error as in your example.
Previous Comments:
[2010-05-12 22:09:18] kherge at me dot com
Error reporting is currently set to 32767 (E_ALL | E_STRICT).
[2010-05-12 22:05:32] dtajchre...@php.net
Do you have error reporting settings at the right level.. display
errors? I get a nice fatal error as expected..
da...@beirut:~$ php test.php
PHP Fatal error: Access level to MyClass::_test() must be public (as in
class MyInterface) in /home/david/test.php on line 9
Fatal error: Access level to MyClass::_test() must be public (as in
class MyInterface) in /home/david/test.php on line 9
da...@beirut:~$ echo $?
255
[2010-05-12 21:55:55] kherge at me dot com
Description:
Running the test script, PHP silently exists with the error code 255.
If you
remove the protected access type from the _test() function in the
MyClass class,
the script executes normally.
Test script:
---
http://bugs.php.net/bug.php?id=51803&edit=1
Bug #51791 [Bgs]: constant() failed to check undefined constant and php interpreter stoped
Edit report at http://bugs.php.net/bug.php?id=51791&edit=1
ID: 51791
User updated by: iliavlad at mail dot ru
Reported by: iliavlad at mail dot ru
Summary: constant() failed to check undefined constant and php
interpreter stoped
Status: Bogus
Type: Bug
Package: Reproducible crash
Operating System: Windows, Linux
PHP Version: 5.3.2
New Comment:
Hi Mike,
according to manual http://php.net/manual/en/function.constant.php
constant() eturns the value of the constant, or NULL if the constant is
not defined. And this happens with php 5.2 version. With php 5.3 there
is a fatal error and php interpreter stops. There are no words about
fatal error in manual.
Previous Comments:
[2010-05-12 08:16:15] m...@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
[2010-05-11 12:12:45] iliavlad at mail dot ru
Description:
constant() failed to check undefined constant and php interpreter
stoped, but constant() should return NULL and php interpreter should
continue to work.
Test script:
---
class A
{
const B = 1;
}
var_dump(constant('A::B1'));
echo 5;
Expected result:
Warning: constant(): Couldn't find constant A::B1
NULL
5
Actual result:
--
>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
>php -r "class A { const B = 1;} var_dump(@constant('A::B1')); echo 5;"
>php -r "class A { const B = 1;} var_dump(constant('A::B1')); echo 5;"
Fatal error: Undefined class constant 'A::B1' in Command line code on
line 1
Call Stack:
0.0003 317608 1. {main}() Command line code:0
0.0003 317688 2. constant() Command line code:1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51791&edit=1
Bug #51791 [Bgs->Opn]: constant() failed to check undefined constant and php interpreter stoped
Edit report at http://bugs.php.net/bug.php?id=51791&edit=1
ID: 51791
Updated by: phi...@php.net
Reported by: iliavlad at mail dot ru
Summary: constant() failed to check undefined constant and php
interpreter stoped
-Status: Bogus
+Status: Open
Type: Bug
Package: Reproducible crash
Operating System: Windows, Linux
PHP Version: 5.3.2
New Comment:
I don't see this change mentioned at any of the following locations:
- http://php.net/php5news
- http://php.net/migration53
- http://php.net/function.constant
Therefore, it can't be completely bogus. Please explain if this BC break
in 5_3
is intentional. constant('IDONOTEXIST') still returns NULL however, with
E_WARNING instead of E_FATAL.
Previous Comments:
[2010-05-13 00:09:29] iliavlad at mail dot ru
Hi Mike,
according to manual http://php.net/manual/en/function.constant.php
constant() eturns the value of the constant, or NULL if the constant is
not defined. And this happens with php 5.2 version. With php 5.3 there
is a fatal error and php interpreter stops. There are no words about
fatal error in manual.
[2010-05-12 08:16:15] m...@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
[2010-05-11 12:12:45] iliavlad at mail dot ru
Description:
constant() failed to check undefined constant and php interpreter
stoped, but constant() should return NULL and php interpreter should
continue to work.
Test script:
---
class A
{
const B = 1;
}
var_dump(constant('A::B1'));
echo 5;
Expected result:
Warning: constant(): Couldn't find constant A::B1
NULL
5
Actual result:
--
>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
>php -r "class A { const B = 1;} var_dump(@constant('A::B1')); echo 5;"
>php -r "class A { const B = 1;} var_dump(constant('A::B1')); echo 5;"
Fatal error: Undefined class constant 'A::B1' in Command line code on
line 1
Call Stack:
0.0003 317608 1. {main}() Command line code:0
0.0003 317688 2. constant() Command line code:1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51791&edit=1
Bug #51791 [Opn->Ver]: constant() failed to check undefined constant and php interpreter stoped
Edit report at http://bugs.php.net/bug.php?id=51791&edit=1
ID: 51791
Updated by: bj...@php.net
Reported by: iliavlad at mail dot ru
Summary: constant() failed to check undefined constant and php
interpreter stoped
-Status: Open
+Status: Verified
Type: Bug
-Package: Reproducible crash
+Package: Scripting Engine problem
Operating System: Windows, Linux
PHP Version: 5.3.2
New Comment:
This is definitely a bug.
Previous Comments:
[2010-05-13 01:02:35] phi...@php.net
I don't see this change mentioned at any of the following locations:
- http://php.net/php5news
- http://php.net/migration53
- http://php.net/function.constant
Therefore, it can't be completely bogus. Please explain if this BC break
in 5_3
is intentional. constant('IDONOTEXIST') still returns NULL however, with
E_WARNING instead of E_FATAL.
[2010-05-13 00:09:29] iliavlad at mail dot ru
Hi Mike,
according to manual http://php.net/manual/en/function.constant.php
constant() eturns the value of the constant, or NULL if the constant is
not defined. And this happens with php 5.2 version. With php 5.3 there
is a fatal error and php interpreter stops. There are no words about
fatal error in manual.
[2010-05-12 08:16:15] m...@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
[2010-05-11 12:12:45] iliavlad at mail dot ru
Description:
constant() failed to check undefined constant and php interpreter
stoped, but constant() should return NULL and php interpreter should
continue to work.
Test script:
---
class A
{
const B = 1;
}
var_dump(constant('A::B1'));
echo 5;
Expected result:
Warning: constant(): Couldn't find constant A::B1
NULL
5
Actual result:
--
>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
>php -r "class A { const B = 1;} var_dump(@constant('A::B1')); echo 5;"
>php -r "class A { const B = 1;} var_dump(constant('A::B1')); echo 5;"
Fatal error: Undefined class constant 'A::B1' in Command line code on
line 1
Call Stack:
0.0003 317608 1. {main}() Command line code:0
0.0003 317688 2. constant() Command line code:1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51791&edit=1
[PHP-BUG] Bug #51804 [NEW]: SplFileInfo::getLinkTarget() Fails.
From:
Operating system: All Windows OS
PHP version: 5.3SVN-2010-05-13 (SVN)
Package: SPL related
Bug Type: Bug
Bug description:SplFileInfo::getLinkTarget() Fails.
Description:
SplFileInfo::getLinkTarget() fails .we have a filesymlink created for a
file (filesymbolic.txt) and tried to read the target of the filesymlink
created and it returns an error .This happens for Directory also.
When this Function used on accessing symlinks over remote share it returns
an error with 'Bad File Descriptor'.
Test script:
---
getLinkTarget());
?>
Expected result:
bool(true)
string(16) filesymbolic.txt
Actual result:
--
bool(true)
Fatal error: Uncaught exception 'RuntimeException' with message 'Unable to
read link C:\Program Files (x86)\Apache Software
Foundation\Apache2.2\htdocs\symlinktodir, error: No such file or directory'
in C:\Program Files (x86)\Apache Software
Foundation\Apache2.2\htdocs\getLinkTarget.php:5 Stack trace: #0 C:\Program
Files (x86)\Apache Software
Foundation\Apache2.2\htdocs\getLinkTarget.php(5):
SplFileInfo->getLinkTarget() #1 {main} thrown in C:\Program Files
(x86)\Apache Software Foundation\Apache2.2\htdocs\getLinkTarget.php on line
5
--
Edit bug report at http://bugs.php.net/bug.php?id=51804&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51804&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51804&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51804&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51804&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51804&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51804&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51804&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51804&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51804&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51804&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51804&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51804&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51804&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51804&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51804&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51804&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51804&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51804&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51804&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51804&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51804&r=mysqlcfg
Bug #51791 [Ver->Csd]: constant() aborts execution when fail to check undefined constant
Edit report at http://bugs.php.net/bug.php?id=51791&edit=1
ID: 51791
Updated by: fel...@php.net
Reported by: iliavlad at mail dot ru
Summary: constant() aborts execution when fail to check
undefined constant
-Status: Verified
+Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Windows, Linux
PHP Version: 5.3.2
-Assigned To:
+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.
Previous Comments:
[2010-05-13 04:13:32] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=299320
Log: - Fixed bug #51791 (constant() aborts execution when fail to check
undefined constant)
[2010-05-13 03:16:14] bj...@php.net
This is definitely a bug.
[2010-05-13 01:02:35] phi...@php.net
I don't see this change mentioned at any of the following locations:
- http://php.net/php5news
- http://php.net/migration53
- http://php.net/function.constant
Therefore, it can't be completely bogus. Please explain if this BC break
in 5_3
is intentional. constant('IDONOTEXIST') still returns NULL however, with
E_WARNING instead of E_FATAL.
[2010-05-13 00:09:29] iliavlad at mail dot ru
Hi Mike,
according to manual http://php.net/manual/en/function.constant.php
constant() eturns the value of the constant, or NULL if the constant is
not defined. And this happens with php 5.2 version. With php 5.3 there
is a fatal error and php interpreter stops. There are no words about
fatal error in manual.
[2010-05-12 08:16:15] m...@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
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=51791
--
Edit this bug report at http://bugs.php.net/bug.php?id=51791&edit=1
Req #51777 [Opn]: RegEx matching fails
Edit report at http://bugs.php.net/bug.php?id=51777&edit=1
ID: 51777
User updated by: trevor at ridgebizdev dot com
Reported by: trevor at ridgebizdev dot com
Summary: RegEx matching fails
Status: Open
Type: Feature/Change Request
Package: PCRE related
Operating System: Windows XP
PHP Version: 5.3.2
New Comment:
Setting the pcre.backtrack_limit makes 51777 an installation feature
request; however, because no warning is fired, the report remains a bug.
Previous Comments:
[2010-05-12 20:10:54] trevor at ridgebizdev dot com
[Pcre]
;PCRE library backtracking limit.
; http://php.net/pcre.backtrack-limit
;pcre.backtrack_limit=10
;PCRE library recursion limit.
;Please note that if you set this value to a high number you may consume
all
;the available process stack and eventually crash PHP (due to reaching
the
;stack size limit imposed by the Operating System).
; http://php.net/pcre.recursion-limit
;pcre.recursion_limit=10
I have nothing set (I must be using the default). I use Windows XP
Professional with 4GB RAM and Core2Duo.
[2010-05-12 09:14:13] m...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works here. Do you have a pcre.backtrack_limit set?
[2010-05-09 18:36:54] trevor at ridgebizdev dot com
Description:
When a RegEx "looks" over ~32768 times during a successful match, every
RegEx function fails and returns the empty string.
Test script:
---
http://www.travelocity.com";);
// no problem with these first 2 RegExs
$response2 = preg_replace('/\s+/'," ",$response);
$mytitle =
preg_replace('/.*?<\s*title\s*>([^<]*)<.*/i','${1}',$response2);
echo "\nTitle Match Forward: ".$mytitle."\n\n";
// now, here's a problem
$mytitle2 =
preg_replace('/.*<\s*title\s*>([^<]*)<.*/i','${1}',$response2);
echo "\nTitle Match Backward: ".$mytitle2."\n\n";
?>
Expected result:
$mytitle gets extracted properly and echoed because the RegEx never
looks more than 32768 times starting at the beginning of the
travelocity.com page source. $mytitle2 never gets extracted because the
RegEx looks more than 32768 times successfully and preg_replace()
crashes into the empty string. Matching forward for the title is
working; matching backward for the title is failing for large buffers.
Actual result:
--
Title Match Forward: Travelocity Travel: Airline Tickets, Hotels,
Flights, Vacations, Cruises & Car Rentals
Title Match Backward:
--
Edit this bug report at http://bugs.php.net/bug.php?id=51777&edit=1
Bug #51581 [Com]: getDefaultProperties incorrect for static properties
Edit report at http://bugs.php.net/bug.php?id=51581&edit=1 ID: 51581 Comment by: ChadFulton at gmail dot com Reported by: ChadFulton at gmail dot com Summary: getDefaultProperties incorrect for static properties Status: Assigned Type: Bug Package: Reflection related Operating System: Mac OSx 10.6 PHP Version: 5.3.2 Assigned To: dmitry New Comment: Thanks for taking this issue up! Previous Comments: [2010-05-12 15:45:58] m...@php.net Dmitry, could you please review the fix-refs-to-default-static-members patch? Thank you. [2010-05-12 15:45:35] m...@php.net The following patch has been added/updated: Patch Name: fix-reflection-of-default-static-members Revision: 1273671935 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-reflection-of-default-static-members&revision=1273671935 [2010-05-12 15:42:00] m...@php.net The following patch has been added/updated: Patch Name: fix-refs-to-default-static-members Revision: 1273671720 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-refs-to-default-static-members&revision=1273671720 [2010-04-17 02:24:07] ChadFulton at gmail dot com Description: The array ReflectionClass's getDefaultProperties() method changes for static properties, depending upon what value the static property currently holds. I suppose there is an argument to be made that this is expected/desired, since static properties are meant to hold across all instances of the class. However, it doesn't seem like it necessarily fits as part of a function to get the *default* property. Test script: --- getDefaultProperties()); foo::$bar = 'new static value, no longer default though'; print_r($r->getDefaultProperties()); ?> Expected result: Array ( [bar] => true default value ) Array ( [bar] => true default value ) Actual result: -- Array ( [bar] => true default value ) Array ( [bar] => new static value, no longer default though ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51581&edit=1
