#20405 [NEW]: Integer of zero equals a string value
From: [EMAIL PROTECTED] Operating system: Redhat 7.2 PHP version: 4.2.2 PHP Bug Type: Unknown/Other Function Bug description: Integer of zero equals a string value Outputs: They're equal! -- Edit bug report at http://bugs.php.net/?id=20405&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20405&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20405&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20405&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20405&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20405&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20405&r=support Expected behavior: http://bugs.php.net/fix.php?id=20405&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20405&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20405&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20405&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20405&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20405&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20405&r=isapi
#20801 [NEW]: undefined symbol: xml_utf8_decode
From: [EMAIL PROTECTED] Operating system: Linux/Debian PHP version: 4.2.3 PHP Bug Type: Apache related Bug description: undefined symbol: xml_utf8_decode I've compiled PHP 4.2.3, patched to work with GD2, as an apache module. I'm using apache-ssl, and when I try to start it, it gives me the following error: Starting web server: apache-sslSyntax error on line 243 of /etc/apache-ssl/httpd.conf: Cannot load /usr/lib/apache/1.3/libphp4.so into server: /usr/lib/apache/1.3/libphp4.so: undefined symbol: xml_utf8_decode failed compiled with: ./configure --prefix=/usr --with-regex=php --with-config-file-path=/etc/php4/apache --with-apxs=/usr/bin/apxs --disable-rpath --disable-debug --enable-memory-limit --enable-calendar --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-bcmath --with-bz2 --enable-ctype --with-db2 --with-iconv --with-ndbm --enable-exif --enable-filepro --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --with-xml=/usr --with-expat-dir=/usr --enable-yp --with-zlib --without-pgsql --disable-static --with-layout=GNU --with-curl=shared,/usr --with-dom=shared,/usr --with-zlib-dir=/usr --with-gd=shared,/usr --with-jpeg-dir=shared,/usr --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-ldap=shared,/usr --with-mcal=shared,/usr --with-mhash=shared,/usr --with-mm --with-mysql=shared --without-unixODBC --with-recode=shared,/usr --enable-xslt --with-xslt-sablot=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --without-sybase-ct --with-ttf=shared,/usr --with-t1lib=shared,/usr -- Edit bug report at http://bugs.php.net/?id=20801&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20801&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20801&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20801&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20801&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20801&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20801&r=support Expected behavior: http://bugs.php.net/fix.php?id=20801&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20801&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20801&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20801&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20801&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20801&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20801&r=isapi
#20801 [Fbk->Csd]: undefined symbol: xml_utf8_decode
ID: 20801 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Apache related Operating System: Linux/Debian PHP Version: 4.2.3 New Comment: Today's CVS snapshot works perfectly. Previous Comments: [2002-12-04 02:05:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-03 16:06:59] [EMAIL PROTECTED] I've compiled PHP 4.2.3, patched to work with GD2, as an apache module. I'm using apache-ssl, and when I try to start it, it gives me the following error: Starting web server: apache-sslSyntax error on line 243 of /etc/apache-ssl/httpd.conf: Cannot load /usr/lib/apache/1.3/libphp4.so into server: /usr/lib/apache/1.3/libphp4.so: undefined symbol: xml_utf8_decode failed compiled with: ./configure --prefix=/usr --with-regex=php --with-config-file-path=/etc/php4/apache --with-apxs=/usr/bin/apxs --disable-rpath --disable-debug --enable-memory-limit --enable-calendar --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-bcmath --with-bz2 --enable-ctype --with-db2 --with-iconv --with-ndbm --enable-exif --enable-filepro --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --with-xml=/usr --with-expat-dir=/usr --enable-yp --with-zlib --without-pgsql --disable-static --with-layout=GNU --with-curl=shared,/usr --with-dom=shared,/usr --with-zlib-dir=/usr --with-gd=shared,/usr --with-jpeg-dir=shared,/usr --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-ldap=shared,/usr --with-mcal=shared,/usr --with-mhash=shared,/usr --with-mm --with-mysql=shared --without-unixODBC --with-recode=shared,/usr --enable-xslt --with-xslt-sablot=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --without-sybase-ct --with-ttf=shared,/usr --with-t1lib=shared,/usr -- Edit this bug report at http://bugs.php.net/?id=20801&edit=1
#20982 [NEW]: sort doesn't sort
From: [EMAIL PROTECTED] Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4.2.2 PHP Bug Type: Arrays related Bug description: sort doesn't sort # cat sort.php # php -v 4.2.2 # php -q sort.php fruits[0] = lemon fruits[1] = orange fruits[2] = banana fruits[3] = apple # -- Edit bug report at http://bugs.php.net/?id=20982&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20982&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20982&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20982&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20982&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20982&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20982&r=support Expected behavior: http://bugs.php.net/fix.php?id=20982&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20982&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20982&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20982&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20982&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20982&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20982&r=isapi
#20982 [Com]: sort doesn't sort
ID: 20982
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4.2.2
New Comment:
I also tried other various sort functions and they all failed to sort:
# cat sort.php
"lemon", "a"=>"orange", "b"=>"banana",
"c"=>"apple");
asort ($fruits);
reset ($fruits);
while (list ($key, $val) = each ($fruits)) {
echo "$key = $val\n";
}
// ksort() demo
echo "\n";
$fruits = array ("d"=>"lemon", "a"=>"orange", "b"=>"banana",
"c"=>"apple");
ksort ($fruits);
reset ($fruits);
while (list ($key, $val) = each ($fruits)) {
echo "$key = $val\n";
}
// usort() demo
echo "\n";
$fruits = array();
function cmp ($a, $b) {
return strcmp($a["fruit"], $b["fruit"]);
}
$fruits[0]["fruit"] = "lemons";
$fruits[1]["fruit"] = "apples";
$fruits[2]["fruit"] = "grapes";
usort($fruits, "cmp");
while (list ($key, $value) = each ($fruits)) {
echo "\$fruits[$key]: " . $value["fruit"] . "\n";
}
?>
# php -q sort.php
fruits[0] = lemon
fruits[1] = orange
fruits[2] = banana
fruits[3] = apple
d = lemon
a = orange
b = banana
c = apple
d = lemon
a = orange
b = banana
c = apple
$fruits[0]: lemons
$fruits[1]: apples
$fruits[2]: grapes
#
Previous Comments:
[2002-12-13 00:09:11] [EMAIL PROTECTED]
# cat sort.php
# php -v
4.2.2
# php -q sort.php
fruits[0] = lemon
fruits[1] = orange
fruits[2] = banana
fruits[3] = apple
#
--
Edit this bug report at http://bugs.php.net/?id=20982&edit=1
#20995 [NEW]: gd.c:1345: structure has no member named `free'
From: [EMAIL PROTECTED] Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4CVS-2002-12-13 (stable) PHP Bug Type: Compile Failure Bug description: gd.c:1345: structure has no member named `free' /bin/sh libtool --silent --mode=compile gcc -I/usr/local/include -Iext/gd/ -I/usr/local_src /php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC -I/usr/local_src/php/php4-STABLE-20021 2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main -I/usr/local_src/php/php 4-STABLE-200212131430 -I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/ mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat -I/usr/pkg/include -I/us r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c /usr/local_src/php/ph p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo In file included from /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89: /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In function `_php_image_output _ctx': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73: structure has no member nam ed `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105: structure has no member na med `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_type': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_create_fro m': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure has no member named `free' gmake: *** [ext/gd/gd.lo] Error 1 --- I'm using gd-2.0.7 -- Edit bug report at http://bugs.php.net/?id=20995&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20995&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20995&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20995&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20995&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20995&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20995&r=support Expected behavior: http://bugs.php.net/fix.php?id=20995&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20995&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20995&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20995&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20995&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20995&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20995&r=isapi
#20995 [Bgs->Opn]: gd.c:1345: structure has no member named `free'
ID: 20995 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2002-12-13 (stable) New Comment: I wished when you guys say that the bug was fixed in cvs, you should supply the date of the cvs version. In my case, I compiled from cvs snapshot last night. So unless it was fixed this morning, I don't think it could be fixed in cvs. Previous Comments: [2002-12-13 13:15:14] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. http://bugs.php.net/20083 [2002-12-13 13:13:12] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-13 13:00:48] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=compile gcc -I/usr/local/include -Iext/gd/ -I/usr/local_src /php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC -I/usr/local_src/php/php4-STABLE-20021 2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main -I/usr/local_src/php/php 4-STABLE-200212131430 -I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/ mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat -I/usr/pkg/include -I/us r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c /usr/local_src/php/ph p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo In file included from /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89: /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In function `_php_image_output _ctx': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73: structure has no member nam ed `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105: structure has no member na med `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_type': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_create_fro m': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure has no member named `free' gmake: *** [ext/gd/gd.lo] Error 1 --- I'm using gd-2.0.7 -- Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20995 [Com]: gd.c:1345: structure has no member named `free'
ID: 20995
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
I just checked, there is only one install of gd-2.0.7 and one gd.h
('locate gd.h' confirmed that).
in /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345:
#if HAVE_LIBGD204
io_ctx->gd_free(io_ctx);
#else
io_ctx->free(io_ctx); <<<-- 1345
#endif
If it's doing line 1345 that means that configured failed to detect
gd-2.0.7 being compatible with gd-2.0.4 to set the proper define.
Previous Comments:
[2002-12-13 13:25:13] [EMAIL PROTECTED]
I think the error you are seeing is due to your system having more then
one gd library. Old gd versions by default went to /usr, while the new
release go to /usr/local, the result is a header confusion responsible
for the error you are seeing. To confirm this see if you have more then
one copy of gd, by doing 'locate gd.h'.
[2002-12-13 13:22:43] [EMAIL PROTECTED]
I wished when you guys say that the bug was fixed in cvs, you should
supply the date of the cvs version.
In my case, I compiled from cvs snapshot last night. So unless it was
fixed this morning, I don't think it could be fixed in cvs.
[2002-12-13 13:15:14] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
http://bugs.php.net/20083
[2002-12-13 13:13:12] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-12-13 13:00:48] [EMAIL PROTECTED]
/bin/sh libtool --silent --mode=compile gcc -I/usr/local/include
-Iext/gd/ -I/usr/local_src
/php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC
-I/usr/local_src/php/php4-STABLE-20021
2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main
-I/usr/local_src/php/php
4-STABLE-200212131430
-I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu
de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2
-I/usr/pkg/include/
mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat
-I/usr/pkg/include -I/us
r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c
/usr/local_src/php/ph
p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo
In file included from
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89:
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In
function `_php_image_output
_ctx':
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73:
structure has no member nam
ed `free'
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105:
structure has no member na
med `free'
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function
`_php_image_type':
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure
has no member named
`free'
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure
has no member named
`free'
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function
`_php_image_create_fro
m':
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure
has no member named
`free'
gmake: *** [ext/gd/gd.lo] Error 1
---
I'm using gd-2.0.7
--
Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20995 [Com]: gd.c:1345: structure has no member named `free'
ID: 20995
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
checking config.log revealed:
configure:27284: gcc -c -g -O2 -I/usr/pkg/include conftest.c 1>&5
configure:27272: gd.h: No such file or directory
configure: failed program was:
#line 27270 "configure"
#include "confdefs.h"
#include
#include
int main() {
gdIOCtx *ctx;
ctx = malloc(sizeof(gdIOCtx));
ctx->gd_free = 1;
; return 0; }
seems like it can't find gd.h. very strange.
# locate gd.h
/usr/local/include/gd.h <<-- symlink
/usr/local_install/gd-2.0.7/include/gd.h
/usr/local_src/gd/gd-2.0.7/gd.h
/usr/local_src/php/php-4.2.2/ext/gd/php_gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/libgd/gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/php_gd.h
Previous Comments:
[2002-12-13 13:45:49] [EMAIL PROTECTED]
I just checked, there is only one install of gd-2.0.7 and one gd.h
('locate gd.h' confirmed that).
in /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345:
#if HAVE_LIBGD204
io_ctx->gd_free(io_ctx);
#else
io_ctx->free(io_ctx); <<<-- 1345
#endif
If it's doing line 1345 that means that configured failed to detect
gd-2.0.7 being compatible with gd-2.0.4 to set the proper define.
[2002-12-13 13:25:13] [EMAIL PROTECTED]
I think the error you are seeing is due to your system having more then
one gd library. Old gd versions by default went to /usr, while the new
release go to /usr/local, the result is a header confusion responsible
for the error you are seeing. To confirm this see if you have more then
one copy of gd, by doing 'locate gd.h'.
[2002-12-13 13:22:43] [EMAIL PROTECTED]
I wished when you guys say that the bug was fixed in cvs, you should
supply the date of the cvs version.
In my case, I compiled from cvs snapshot last night. So unless it was
fixed this morning, I don't think it could be fixed in cvs.
[2002-12-13 13:15:14] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
http://bugs.php.net/20083
[2002-12-13 13:13:12] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
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/20995
--
Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20995 [Com]: gd.c:1345: structure has no member named `free'
ID: 20995
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
config.nice:
'./configure' \
'--prefix=/usr/local_install/php-4.2.2' \
'--with-config-file-path=/usr/local/etc' \
'--with-gd=shared,/usr/local' \
'--with-curl=shared,/usr/local' \
'--with-system-regex' \
'--with-gettext=shared,/usr/pkg' \
'--with-pgsql=shared,/usr/local' \
'--with-mysql=shared,/usr/pkg' \
'--with-mcrypt=shared,/usr/pkg' \
'--with-pcre-regex' \
'--with-tiff-dir=/usr/pkg' \
'--with-jpeg-dir=/usr/pkg' \
'--with-png-dir=/usr/pkg' \
'--with-xpm-dir' \
'--with-ttf=/usr/pkg' \
'--with-freetype-dir=/usr/pkg' \
'--with-zlib-dir=shared,/usr' \
'--enable-dbase' \
'--enable-gd-native-ttf' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sockets' \
'--enable-xml' \
'--enable-trans-sid' \
'--enable-discard-path' \
'--enable-force-cgi-redirect' \
'--enable-memory-limit' \
'--enable-track-vars' \
'--without-t1lib' \
'--disable-static' \
'--enable-shared' \
Also note this snippet from 'configure':
27268 cat > conftest.$ac_ext <
27273 #include
27274
27275 int main() {
27276
27277 gdIOCtx *ctx;
27278 ctx = malloc(sizeof(gdIOCtx));
27279 ctx->gd_free = 1;
27280
27281 ; return 0; }
27282 EOF
---
27272 #include
my 'gd.h' is in '/usr/local/gd.h'. Seems like that include line is only
looking in the system include path. It's not even using the path that
was provided in --with-gd.
Previous Comments:
[2002-12-13 14:59:24] [EMAIL PROTECTED]
what's your configure line? (see config.nice)
[2002-12-13 14:53:22] [EMAIL PROTECTED]
checking config.log revealed:
configure:27284: gcc -c -g -O2 -I/usr/pkg/include conftest.c 1>&5
configure:27272: gd.h: No such file or directory
configure: failed program was:
#line 27270 "configure"
#include "confdefs.h"
#include
#include
int main() {
gdIOCtx *ctx;
ctx = malloc(sizeof(gdIOCtx));
ctx->gd_free = 1;
; return 0; }
seems like it can't find gd.h. very strange.
# locate gd.h
/usr/local/include/gd.h <<-- symlink
/usr/local_install/gd-2.0.7/include/gd.h
/usr/local_src/gd/gd-2.0.7/gd.h
/usr/local_src/php/php-4.2.2/ext/gd/php_gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/libgd/gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/php_gd.h
[2002-12-13 13:45:49] [EMAIL PROTECTED]
I just checked, there is only one install of gd-2.0.7 and one gd.h
('locate gd.h' confirmed that).
in /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345:
#if HAVE_LIBGD204
io_ctx->gd_free(io_ctx);
#else
io_ctx->free(io_ctx); <<<-- 1345
#endif
If it's doing line 1345 that means that configured failed to detect
gd-2.0.7 being compatible with gd-2.0.4 to set the proper define.
[2002-12-13 13:25:13] [EMAIL PROTECTED]
I think the error you are seeing is due to your system having more then
one gd library. Old gd versions by default went to /usr, while the new
release go to /usr/local, the result is a header confusion responsible
for the error you are seeing. To confirm this see if you have more then
one copy of gd, by doing 'locate gd.h'.
[2002-12-13 13:22:43] [EMAIL PROTECTED]
I wished when you guys say that the bug was fixed in cvs, you should
supply the date of the cvs version.
In my case, I compiled from cvs snapshot last night. So unless it was
fixed this morning, I don't think it could be fixed in cvs.
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/20995
--
Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#21002 [NEW]: Unaligned Access
From: [EMAIL PROTECTED] Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4CVS-2002-12-13 (stable) PHP Bug Type: Compile Warning Bug description: Unaligned Access Related bug: 20433 (closed) The above bug shouldn't have been closed as the Unaligned Access is still being reported using 12/13 snap. The patch posted in bug 20433 (toward the end) does resolve these issues. Here is the URL again: ftp://codon.genopole-lille.fr/pub/php-4.3.0RC2-stat+onupdateint+zendparam.patch -- Edit bug report at http://bugs.php.net/?id=21002&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21002&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21002&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21002&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21002&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21002&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21002&r=support Expected behavior: http://bugs.php.net/fix.php?id=21002&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21002&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21002&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21002&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21002&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21002&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21002&r=isapi
#21004 [NEW]: Header Location Fails
From: [EMAIL PROTECTED] Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4CVS-2002-12-13 (stable) PHP Bug Type: URL related Bug description: Header Location Fails RE: Bug #19754 shouldn't be closed because CVS-2002-12-13 still exihibit this problem. index.php: http://".$_SERVER['HTTP_HOST']; $location.= dirname($_SERVER['PHP_SELF'])."/"."index2.php"; header($location); ?> --- index2.php: You have been redirected"; ?> --- calling index.php should redir to index2.php and echo out: You have been redirected Instead both Mozzila 1.2b and IE 6.x show a blank page. -- Edit bug report at http://bugs.php.net/?id=21004&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21004&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21004&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21004&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21004&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21004&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21004&r=support Expected behavior: http://bugs.php.net/fix.php?id=21004&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21004&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21004&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21004&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21004&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21004&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21004&r=isapi
#21005 [NEW]: libpng 1.2.5; segfault while loading png image
From: [EMAIL PROTECTED] Operating system: Linux 2.4.18 PHP version: 4.2.3 PHP Bug Type: GD related Bug description: libpng 1.2.5; segfault while loading png image After recompiling php 4.2.3 with the gd image functions, I've found that libpng 1.2.5 is not compatible with php 4.2.3. While loading a png file using ImageCreateFromPNG($img); where $img is the filename, php would segfault. After recompiling php multiple times, i've still had the same problem. I gave the stable version of php in the development stage a try, and still recieved a segfault. So then i used the strace function at the command line along with the php cli to figure out that it would segfault when the png image was loaded. When i viewed the libpng website, i found the following... "The current public release, libpng 1.2.5, has a new API (since 1.0.x) for dynamically enabling and disabling certain optimizations (currently limited to MMX code--which is compiled into GNU C versions only if PNG_THREAD_UNSAFE_OK is defined, due to the gcc code's use of static global variables to work around addressing limitations). As a consequence of this and some other changes, its DLL and shared-library (.so) numbers were bumped from 2 to 3." After reading this, i've decided to downgrade to libpng1.0.15 and recompiled php. After doing this, the segfault would not appear again. Hopes this helps... -- Edit bug report at http://bugs.php.net/?id=21005&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21005&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21005&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21005&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21005&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21005&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21005&r=support Expected behavior: http://bugs.php.net/fix.php?id=21005&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21005&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21005&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21005&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21005&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21005&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21005&r=isapi
#21004 [Com]: Header Location Fails
ID: 21004 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: HTTP related Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2002-12-13 (stable) New Comment: I don't think it's directing at all. FYI, works fine under PHP-4.2.2, but not CVS. Using 4.3-CVS - # lynx -dump -head http://www.minnesota.com/~tom/php/redir/index.php HTTP/1.1 500 Internal Server Error Date: Sat, 14 Dec 2002 18:13:20 GMT Server: Apache/1.3.27 (Unix) PHP/4.3.0-dev X-Powered-By: PHP/4.3.0-dev Location: http://www.minnesota.com/~tom/php/redir/index2.php Connection: close Content-Type: text/html Using 4.2.2 --- # lynx -dump -head http://www.minnesota.com/~tom/php/redir/index.php HTTP/1.1 302 Found Date: Sat, 14 Dec 2002 18:17:29 GMT Server: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6g PHP/4.2.2 X-Powered-By: PHP/4.2.2 Location: http://www.minnesota.com/~tom/php/redir/index2.php Connection: close Content-Type: text/html --- In this case I don't think it's Mozilla or IE. Previous Comments: [2002-12-14 04:11:19] [EMAIL PROTECTED] Does it redirect though? What does 'lynx -dump -head ' output? Maybe IE6 and Mozilla 1.2b are more strict about the path? Since your example adds one extra / in the url.. [2002-12-13 19:12:45] [EMAIL PROTECTED] RE: Bug #19754 shouldn't be closed because CVS-2002-12-13 still exihibit this problem. index.php: http://".$_SERVER['HTTP_HOST']; $location.= dirname($_SERVER['PHP_SELF'])."/"."index2.php"; header($location); ?> --- index2.php: You have been redirected"; ?> --- calling index.php should redir to index2.php and echo out: You have been redirected Instead both Mozzila 1.2b and IE 6.x show a blank page. -- Edit this bug report at http://bugs.php.net/?id=21004&edit=1
#21002 [Bgs->Opn]: Unaligned Access
ID: 21002 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Compile Warning Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2002-12-13 (stable) New Comment: If the associated bug ID I listed was closed, yet the problem persists, what's the correct way of reporting the problem again w/o my bug being marked as bogus? If the old bug was closed, yet the problem is still in CVS, marking new related bugs as bogus wouldn't solve the initial problem. The patch provided was not applied to CVS as of 12/13. Should I have added comments to bug 20433 even if it was already closed? Previous Comments: [2002-12-14 03:49:13] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. http://bugs.php.net/bug.php?id=20994&edit=1 [2002-12-13 16:31:42] [EMAIL PROTECTED] Related bug: 20433 (closed) The above bug shouldn't have been closed as the Unaligned Access is still being reported using 12/13 snap. The patch posted in bug 20433 (toward the end) does resolve these issues. Here is the URL again: ftp://codon.genopole-lille.fr/pub/php-4.3.0RC2-stat+onupdateint+zendparam.patch -- Edit this bug report at http://bugs.php.net/?id=21002&edit=1
#20433 [Com]: Unaligned access error messages at runtime
ID: 20433 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Warning Operating System: Tru64, NetBSD(Alpha platform) PHP Version: 4.3.0-RC1 Assigned To: helly New Comment: I found the same problems on NetBSD/Alpha-1.6. The patch listed does fix the problem but apparently it hasn't made it's way into CVS as of 12/13/2002. Since this bug was closed, I reported another bug #20433. It was then marked bogus due to the problem already being reported, not fixed, but closed. Previous Comments: [2002-12-10 10:26:28] [EMAIL PROTECTED] I work on ALPHA/Tru64 with the same pb as above. But I've found 4 more fix (cf. patch at the end). Moreover, there is another source of confusion with int/long in "zend_parse_parameters()" function. The variable for token "l" should be a long and the 2nd variable for token "s" should be a int. This patch fix (I hope) these pb : ftp://codon.genopole-lille.fr/pub/php-4.3.0RC2-stat+onupdateint+zendparam.patch [2002-11-30 12:39:49] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-11-30 10:35:24] [EMAIL PROTECTED] The problem is OnUpdateInt which will result in an error on 64bit systems. Compiling and testing now. [2002-11-16 10:47:30] [EMAIL PROTECTED] Verified on NetBSD/Alpha. [2002-11-15 05:34:33] [EMAIL PROTECTED] Verified with 4.3.0RC1 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/20433 -- Edit this bug report at http://bugs.php.net/?id=20433&edit=1
#20994 [Com]: int/long confusion in 64bits machine
ID: 20994 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Scripting Engine problem Operating System: any 64bit PHP Version: 4.3.0RC3 New Comment: This issue will cause segmentation faults under php cgi NetBSD/Alpha-1.6. Previous Comments: [2002-12-14 12:53:44] [EMAIL PROTECTED] FYI: there's a README.SUBMITTING_PATCH in the distribution, containing the guidelines for ... submitting a patch. [2002-12-14 03:50:29] [EMAIL PROTECTED] Could you provide that patch in unified diff format? And against the CVS HEAD? [2002-12-13 12:15:35] [EMAIL PROTECTED] There are locations in source where variables are declared int or long and are menipulated with long or int pointer respectively. - The function "OnUpdateInt" use long pointer (the case is already referenced in bug#20433 but I found more variables concerned). - In function "zend_parse_parameters()", the variable for token "l" should be a long and the 2nd variable for token "s" should be a int. The patch above try to fix the 2 cases : ftp://codon.genopole-lille.fr/pub/php-4.3.0RC2-onupdateint+zendparam.patch -- Julien -- Edit this bug report at http://bugs.php.net/?id=20994&edit=1
#21004 [Fbk->Opn]: Header Location Fails
ID: 21004 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: HTTP related Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2002-12-13 (stable) New Comment: I tested this on a DSO. There was no error from apache in the log when accessing index.php. Previous Comments: [2002-12-15 03:51:55] [EMAIL PROTECTED] And how is PHP installed there? DSO or CGI? What does Apache logs have to say about that internal error you're getting? [2002-12-14 12:19:42] [EMAIL PROTECTED] I don't think it's directing at all. FYI, works fine under PHP-4.2.2, but not CVS. Using 4.3-CVS - # lynx -dump -head http://www.minnesota.com/~tom/php/redir/index.php HTTP/1.1 500 Internal Server Error Date: Sat, 14 Dec 2002 18:13:20 GMT Server: Apache/1.3.27 (Unix) PHP/4.3.0-dev X-Powered-By: PHP/4.3.0-dev Location: http://www.minnesota.com/~tom/php/redir/index2.php Connection: close Content-Type: text/html Using 4.2.2 --- # lynx -dump -head http://www.minnesota.com/~tom/php/redir/index.php HTTP/1.1 302 Found Date: Sat, 14 Dec 2002 18:17:29 GMT Server: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6g PHP/4.2.2 X-Powered-By: PHP/4.2.2 Location: http://www.minnesota.com/~tom/php/redir/index2.php Connection: close Content-Type: text/html --- In this case I don't think it's Mozilla or IE. [2002-12-14 04:11:19] [EMAIL PROTECTED] Does it redirect though? What does 'lynx -dump -head ' output? Maybe IE6 and Mozilla 1.2b are more strict about the path? Since your example adds one extra / in the url.. [2002-12-13 19:12:45] [EMAIL PROTECTED] RE: Bug #19754 shouldn't be closed because CVS-2002-12-13 still exihibit this problem. index.php: http://".$_SERVER['HTTP_HOST']; $location.= dirname($_SERVER['PHP_SELF'])."/"."index2.php"; header($location); ?> --- index2.php: You have been redirected"; ?> --- calling index.php should redir to index2.php and echo out: You have been redirected Instead both Mozzila 1.2b and IE 6.x show a blank page. -- Edit this bug report at http://bugs.php.net/?id=21004&edit=1
#21004 [Fbk->Opn]: Header Location Fails
ID: 21004
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
No it doesn't work now. If you click on the URL I typed earlier from
Minnesota.com, it's running PHP-4.2.2 not PHP-4.3-CVS. Per my other
message, redir works fine in 4.2.2 but NOT in 4.3-cvs. I only switch to
4.3-cvs to do the tests, after which, I switch back to 4.2.2.
header("Location: ") *DOES NOT* work in 4.3-cvs.
Previous Comments:
[2002-12-15 16:16:11] [EMAIL PROTECTED]
So it works now?
[2002-12-15 11:39:03] [EMAIL PROTECTED]
I tested this on a DSO. There was no error from apache in the log when
accessing index.php.
[2002-12-15 03:51:55] [EMAIL PROTECTED]
And how is PHP installed there? DSO or CGI?
What does Apache logs have to say about that internal
error you're getting?
[2002-12-14 12:19:42] [EMAIL PROTECTED]
I don't think it's directing at all. FYI, works fine under PHP-4.2.2,
but not CVS.
Using 4.3-CVS
-
# lynx -dump -head http://www.minnesota.com/~tom/php/redir/index.php
HTTP/1.1 500 Internal Server Error
Date: Sat, 14 Dec 2002 18:13:20 GMT
Server: Apache/1.3.27 (Unix) PHP/4.3.0-dev
X-Powered-By: PHP/4.3.0-dev
Location: http://www.minnesota.com/~tom/php/redir/index2.php
Connection: close
Content-Type: text/html
Using 4.2.2
---
# lynx -dump -head http://www.minnesota.com/~tom/php/redir/index.php
HTTP/1.1 302 Found
Date: Sat, 14 Dec 2002 18:17:29 GMT
Server: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6g PHP/4.2.2
X-Powered-By: PHP/4.2.2
Location: http://www.minnesota.com/~tom/php/redir/index2.php
Connection: close
Content-Type: text/html
---
In this case I don't think it's Mozilla or IE.
[2002-12-14 04:11:19] [EMAIL PROTECTED]
Does it redirect though?
What does 'lynx -dump -head ' output?
Maybe IE6 and Mozilla 1.2b are more strict about the path?
Since your example adds one extra / in the url..
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/21004
--
Edit this bug report at http://bugs.php.net/?id=21004&edit=1
#21004 [Opn]: Header Location Fails
ID: 21004
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
is 4.3-dev the same as 4CVS-2002-12-13 (stable)? Cause I used the snap
from stable branch.
Previous Comments:
[2002-12-15 20:27:43] [EMAIL PROTECTED]
I'm unable to reproduce this with 4.3.0-dev.
[2002-12-15 17:02:14] [EMAIL PROTECTED]
No it doesn't work now. If you click on the URL I typed earlier from
Minnesota.com, it's running PHP-4.2.2 not PHP-4.3-CVS. Per my other
message, redir works fine in 4.2.2 but NOT in 4.3-cvs. I only switch to
4.3-cvs to do the tests, after which, I switch back to 4.2.2.
header("Location: ") *DOES NOT* work in 4.3-cvs.
[2002-12-15 16:16:11] [EMAIL PROTECTED]
So it works now?
[2002-12-15 11:39:03] [EMAIL PROTECTED]
I tested this on a DSO. There was no error from apache in the log when
accessing index.php.
[2002-12-15 03:51:55] [EMAIL PROTECTED]
And how is PHP installed there? DSO or CGI?
What does Apache logs have to say about that internal
error you're getting?
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/21004
--
Edit this bug report at http://bugs.php.net/?id=21004&edit=1
#20994 [Com]: int/long confusion in 64bits machine
ID: 20994
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: any 64bit
PHP Version: 4.3.0RC3
New Comment:
The patch provided fixed the unaligned access errors on my
NetBSD/Alpha-1.6 machine (64-bit). However, it also caused:
header("Location: ...");
to fail for redirections. Examining the patch, it does patch that
function. I'm not sure why it breaks.
Previous Comments:
[2002-12-15 22:27:39] [EMAIL PROTECTED]
Yes, but I tested the patch under AIX/64bit, and I got a broken build.
Not sure whether this is related to my machine, the patch or the
combination, but for now - I'd rather investigate.
Additionally - AIX uses a long for tv_usec only under certain
conditions. Otherwise it's a signed int, so the patch needs work,
regardless.
[2002-12-14 14:43:20] [EMAIL PROTECTED]
This issue will cause segmentation faults under php cgi
NetBSD/Alpha-1.6.
[2002-12-14 12:53:44] [EMAIL PROTECTED]
FYI: there's a README.SUBMITTING_PATCH in the distribution, containing
the guidelines for ... submitting a patch.
[2002-12-14 03:50:29] [EMAIL PROTECTED]
Could you provide that patch in unified diff format?
And against the CVS HEAD?
[2002-12-13 12:15:35] [EMAIL PROTECTED]
There are locations in source where variables are declared int or long
and are menipulated with long or int pointer respectively.
- The function "OnUpdateInt" use long pointer (the case is already
referenced in bug#20433 but I found more variables concerned).
- In function "zend_parse_parameters()", the variable for token "l"
should be a long and the 2nd variable for token "s" should be a int.
The patch above try to fix the 2 cases :
ftp://codon.genopole-lille.fr/pub/php-4.3.0RC2-onupdateint+zendparam.patch
--
Julien
--
Edit this bug report at http://bugs.php.net/?id=20994&edit=1
#21004 [Opn->Csd]: Header Location Fails
ID: 21004
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: HTTP related
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
I wiped the slate clean and fetched another snap. Then started a fresh
compile. This time I noticed that I had patched (and forgot that I did
when I reported the bug) the previous snap source to fix the unaligned
access errors, due to 64-bit integers (see Bug #20994). The patch
provided in Bug #20994 fixed the unaligned access problem but caused
header() to fail.
The header() function was patched in that patch file provided in Bug
#20994.
Please close this bug. My apologies for any time wasted. I've also
noted in Bug #20994 that it will break header() function.
Previous Comments:
[2002-12-15 22:55:25] [EMAIL PROTECTED]
is 4.3-dev the same as 4CVS-2002-12-13 (stable)? Cause I used the snap
from stable branch.
[2002-12-15 20:27:43] [EMAIL PROTECTED]
I'm unable to reproduce this with 4.3.0-dev.
[2002-12-15 17:02:14] [EMAIL PROTECTED]
No it doesn't work now. If you click on the URL I typed earlier from
Minnesota.com, it's running PHP-4.2.2 not PHP-4.3-CVS. Per my other
message, redir works fine in 4.2.2 but NOT in 4.3-cvs. I only switch to
4.3-cvs to do the tests, after which, I switch back to 4.2.2.
header("Location: ") *DOES NOT* work in 4.3-cvs.
[2002-12-15 16:16:11] [EMAIL PROTECTED]
So it works now?
[2002-12-15 11:39:03] [EMAIL PROTECTED]
I tested this on a DSO. There was no error from apache in the log when
accessing index.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/21004
--
Edit this bug report at http://bugs.php.net/?id=21004&edit=1
Bug #16786: ereg_replace substitution behaving badly
From: [EMAIL PROTECTED]
Operating system: Linux 2.2.19
PHP version: 4.2.0
PHP Bug Type: Regexps related
Bug description: ereg_replace substitution behaving badly
Hi,
I have just downloaded PHP4.0.2 and several pieces of code broke because
ereg_replace() seemed to be working incorrectly:
if for example I did the following:
$str = "word1-word2";
$str = ereg_replace("^([^-]*)-(.*)", '\1+\2', $str);
it works as expected, ($str == "word1+word2")
The problem arises if one of the parenthasized subexpression is empty the
\x (where x is the number of the subexpression) in the replace string does
not get replaced at all, instead of with the empty string eg:
$str = "-word2";
$str = ereg_replace("^([^-]*)-(.*)", '\1+\2', $str);
for this example I'd expect the result to be ($str == "+word2") but
instead you get ($str == "\1+word2") because \1 is empty.
I don't believe that this is meant to happen but if it is how are we meant
to deal with such a case?
--
Edit bug report at http://bugs.php.net/?id=16786&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16786&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16786&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16786&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16786&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16786&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16786&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16786&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16786&r=submittedtwice
Bug #16786 Updated: ereg_replace substitution behaving badly
ID: 16786
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Regexps related
Operating System: Linux 2.2.19
PHP Version: 4.2.0
New Comment:
This code should demonstrate the problem:
Previous Comments:
[2002-04-24 06:30:42] [EMAIL PROTECTED]
Could you paste complete code?
(With complete code, we can test immediately and put the code
to test suite, if it's needed)
[2002-04-24 05:12:16] [EMAIL PROTECTED]
Hi,
I have just downloaded PHP4.0.2 and several pieces of code broke
because ereg_replace() seemed to be working incorrectly:
if for example I did the following:
$str = "word1-word2";
$str = ereg_replace("^([^-]*)-(.*)", '\1+\2', $str);
it works as expected, ($str == "word1+word2")
The problem arises if one of the parenthasized subexpression is empty
the \x (where x is the number of the subexpression) in the replace
string does not get replaced at all, instead of with the empty string
eg:
$str = "-word2";
$str = ereg_replace("^([^-]*)-(.*)", '\1+\2', $str);
for this example I'd expect the result to be ($str == "+word2") but
instead you get ($str == "\1+word2") because \1 is empty.
I don't believe that this is meant to happen but if it is how are we
meant to deal with such a case?
--
Edit this bug report at http://bugs.php.net/?id=16786&edit=1
Bug #17132 Updated: [chm] bug on function.header.html
ID: 17132 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.0CVS-2002-05-09 New Comment: There is a new version available (built 2002-05-09), in which I can't find an error at the "header" function. (Don't have the old version to check it). Would you please check this new version if the problem still persisits? Previous Comments: [2002-05-10 04:38:27] [EMAIL PROTECTED] Reclassified. [2002-05-09 23:50:06] [EMAIL PROTECTED] I have found a bug on page function.header.html [chm date: 2002-04-20]... 'document.all.unotes' is null or not an object -- Edit this bug report at http://bugs.php.net/?id=17132&edit=1
Bug #17028 Updated: [chm] bug on language.types.resource.html
ID: 17028 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: There is a new version available (built 2002-05-09), in which I don't get such an error. (Don't have the old version to check it). Would you please check this new version if the problem still persisits? Thomas Previous Comments: [2002-05-06 09:23:01] [EMAIL PROTECTED] WinME (4.90.3000) + IE 5.5 (128-bit Cipher Strength) Thanks, Dennis Williams [2002-05-06 04:07:55] [EMAIL PROTECTED] Strange. I still cannot reproduce any of these bugs with IE6 + Winxp and IE5 + Win2k. What Win OS do you have? Goba [2002-05-06 01:06:31] [EMAIL PROTECTED] I have found a bug on page language.types.resource.html [chm date: 2002-04-20]... I don't know if this is exactly a bug...it seems to do with IE 5.5 and script debugging. (I do have Microsoft Script Debugger installed on my system.) Even though I have script debugging turned off (and continue flag set to true when scripting errors encountered) I still get this pop-up on most pages in the .chm format help file: Internet Explorer Script Error An error has occurred in the script on this page. Line: 3 Char: 25 Error: 'document.all.unotes' is null or not an object Code: 0 URL: ... Do you want to continue running scripts on this page? Yes|No Line number, character number and error message seem to remain constant on all pages where this occurs. Thanks, Dennis Williams -- Edit this bug report at http://bugs.php.net/?id=17028&edit=1
Bug #17289 Updated: missing word in german translation
ID: 17289 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: N.A. PHP Version: 4.2.1 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Thanks for the note! Previous Comments: [2002-05-17 10:42:23] [EMAIL PROTECTED] in http://de.php.net/manual/de/class.variant.php (german translation of the manual): VARIANT (unknown) VARIANT -- VARIANT Klasse Synopsis $vVar = new VARIANT($var) Beschreibung Ein einfacher Container, um Variablen VARIANT Strukturen zu verpacken. There is missing the word 'in' between 'Variablen' and 'VARIANT'. The correct sentence must be something like: Ein einfacher Container, um Variablen in VARIANT Strukturen zu verpacken. -- Edit this bug report at http://bugs.php.net/?id=17289&edit=1
Bug #17081 Updated: $_GET != $HTTP_GET_VARS
ID: 17081 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: RH 7.2 PHP Version: 4.2.0 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-05-07 17:10:04] [EMAIL PROTECTED] This is not really a bug, making this a documentation issue. Derick [2002-05-07 15:58:11] [EMAIL PROTECTED] There is a problem with $_GET and $HTTP_GET_VARS. In documentation, in Predefined Variables is mentioned: "$HTTP_GET_VARS contains the same information, but is not an autoglobal." That's true only in one condition - when we are talking about REAL variables passed by GET. But when we set one variable explicity in $HTTP_GET_VARS it is doesn't set in $_GET and vice versa, ie: $HTTP_GET_VARS["sthnew"] = "some str"; echo $_GET["sthnew"]; // There is no such index And: $_GET["sthnew"] = "some str"; echo $HTTP_GET_VARS["sthnew"]; // There is no such index but !! $HTTP_SESSION_VARS["sthnew"] = "some str"; echo $_SESSION["sthnew"]; // Everything is OK I know that _GET and HTTP_GET_VARS shouldn't be set explicity, but I'm doing sth like URL coding and decoding to hide variables from being watched by users and I'm coding also session id. After decoding I write session sid in HTTP_GET_VARS and call session_start(). But session_start() use _only_ $_GET array, not $HTTP_GET_VARS and of course sessions doesn't work. I think you should change documentation or change this feature :) When I read: "$HTTP_GET_VARS contains the same information..." it means for me THE SAME ALL THE TIME... If it doesn't it is very confusing :( Especially that $_SESSION and $HTTP_SESSION_VARS contains the same information all the time. Adam -- Edit this bug report at http://bugs.php.net/?id=17081&edit=1
Bug #17028 Updated: [chm] bug on language.types.resource.html
ID: 17028 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: Hi, there seems to be a misunderstanding. While Goba asked about the software, I've meant the new version of the manual at http://www.php.net/download-docs.php (curr. build 2002-05-20). Thomas Previous Comments: [2002-05-17 20:26:00] [EMAIL PROTECTED] Now I can't do the "Edit Submission" on the actual bug, it states that I "can't change bug to that state"...Did I miss something? Anyway thanks...where is this newer version? All I see is the version 5, built March 20th. Dennis Williams [2002-05-16 14:51:10] [EMAIL PROTECTED] There is a new version available (built 2002-05-09), in which I don't get such an error. (Don't have the old version to check it). Would you please check this new version if the problem still persisits? Thomas [2002-05-06 09:23:01] [EMAIL PROTECTED] WinME (4.90.3000) + IE 5.5 (128-bit Cipher Strength) Thanks, Dennis Williams [2002-05-06 04:07:55] [EMAIL PROTECTED] Strange. I still cannot reproduce any of these bugs with IE6 + Winxp and IE5 + Win2k. What Win OS do you have? Goba [2002-05-06 01:06:31] [EMAIL PROTECTED] I have found a bug on page language.types.resource.html [chm date: 2002-04-20]... I don't know if this is exactly a bug...it seems to do with IE 5.5 and script debugging. (I do have Microsoft Script Debugger installed on my system.) Even though I have script debugging turned off (and continue flag set to true when scripting errors encountered) I still get this pop-up on most pages in the .chm format help file: Internet Explorer Script Error An error has occurred in the script on this page. Line: 3 Char: 25 Error: 'document.all.unotes' is null or not an object Code: 0 URL: ... Do you want to continue running scripts on this page? Yes|No Line number, character number and error message seem to remain constant on all pages where this occurs. Thanks, Dennis Williams -- Edit this bug report at http://bugs.php.net/?id=17028&edit=1
Bug #16959 Updated: ereg_replace returns wrong characters
ID: 16959 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Regexps related Operating System: Linux and Win2K PHP Version: 4.2.0 New Comment: I have had this problem too, I posted a bug report about it on the 24 April and Yohgaki responded asking me to put some code up, I did but he never responded again. I'm supprised that this bug hasn't been fixed because it's a real show stopper for us and it is causing alot of problems because we need some stuff from php 4.2.x but we can't upgrade because all our other code breaks and I imagine there are loads of other people in the same situation. Previous Comments: [2002-05-02 02:25:53] [EMAIL PROTECTED] This is small script for testing. In PHP <= 4.1.x, this script returns empty string. But, PHP 4.2.0 and PHP 4.2.1RC1 return '\1'. The return value in PHP >= 4.2.0 should be corrected. ereg_replace() is used for session id propagation in GET mode of PHPlib. It is not work well because it is affected by this problem. -- Edit this bug report at http://bugs.php.net/?id=16959&edit=1
Bug #16792 Updated: [chm] bug on features.http-auth.html
ID: 16792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: This bug can be closed after feedback about the version from http://weblabor.hu/php-doc-chm/manual_notes_test.zip tom Previous Comments: [2002-05-20 15:33:02] [EMAIL PROTECTED] Can you please test this with http://weblabor.hu/php-doc-chm/manual_notes_test.zip Thank you Goba [2002-04-24 14:01:47] [EMAIL PROTECTED] What OS do you exactly use? What IE do you have installed. Aren't there errors on other pages? This error should pop up on all pages all the time, or nowhere, or on all pages sometimes, depending on what is the real error ;) (Note for phpdoc bug readers: this is the form of bug reports from the new chms. I hope it is good enough. I have included automations to post page names and CHM dates for guys to be able to trace if this error is corrected since that CHM release or not.) [2002-04-24 09:14:07] [EMAIL PROTECTED] I have found a bug on page features.http-auth.html [chm date: 2002-04-20]... I found at least 2 bugs with the same message reported: 'document.all.unotes' is null or not an object Reported on openning following items: "HTTP authentication with PHP" and "Function reference" items on line 3, char 25. Manual php_manual_en.chm distributed in php_manual_sample_5.zip -- Edit this bug report at http://bugs.php.net/?id=16792&edit=1
Bug #12839 Updated: Descrepancy in Manual (Appendix G)
ID: 12839 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: win32 (9x SE) PHP Version: 4.0.6 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Previous Comments: [2001-08-19 09:44:53] [EMAIL PROTECTED] Follow up on previous - Here's a quick list of what appears to be erratta in Appendix G: function listed as aliases to themselves: xpath_eval xpath_eval_expression xpath_init xpath_new_context As I'm still working my way through these, there may be more.. like the msql function prevously noted. [2001-08-19 07:22:36] [EMAIL PROTECTED] This may just be my misunderstanding.. in either case, i'm sure that if I'm a little confused, others might be as well. I've been working on assembling an expression file for HomeSite.. in so doing I wanted to create a set which highlights those functions which are "aliases".. So, I'm working with Appendix G and noted the following: The appendix essentailly states the "reverse" of the function documentation... The manual indicates the chop() is an alias to rtrim(), while the appendix indicates the reverse, naming chop() the "master function".. and rtrim() the alias...??? Also, on a different note - msql_affected_rows is labeled as as alias of itself? how can a function be an alias of itself? Can someone please clarify Appendix G? from the manual on chop: This function is an alias of rtrim(). Whil Appendix G indicates that chop() is the master function? This is repeated with most functions listed in G. Thanks, in advance for the input. -- Edit this bug report at http://bugs.php.net/?id=12839&edit=1
Bug #12868 Updated: Appendix G Descrepancies..
ID: 12868 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: win32 PHP Version: 4.0.6 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Previous Comments: [2001-12-11 16:50:39] [EMAIL PROTECTED] This seems okay now. But, maybe the alias appendix should be auto-generated via something like "genaliasindex" ? [2001-08-21 13:35:12] [EMAIL PROTECTED] It doesn't matter at all indeed. For chop/rtrim: chop used to be main function, but since it's in perl and behaving differently over there, _and_ rtrim is consistent with trim and ltrim, I decided to document chop as the alias. Will update aliases.xml too. I recently suggested a better indication to aliases (in phpdoc/README -> CONVENTIONS), but that hasn't been implemented yet -> be patient. Btw: is_float will be master now, is_double the alias... PHP doesn't have double-precision floats, there's only one flavour. [2001-08-21 01:28:38] [EMAIL PROTECTED] Update status... [2001-08-21 01:28:13] [EMAIL PROTECTED] I don't understand why it matters which is the 'master' and which is the alias? I would guess that the reason for the inconsistency in the documentation is that it really doesn't matter which is which, so the doc team is not all that careful about it. But that's just a guess...this wouldn't be all that hard to clear up. FWIW, rtrim() is an alias to chop() and fputs() is an alias to fwrite(). [2001-08-21 00:12:18] [EMAIL PROTECTED] This is truly a followup to my previous post - message about what appears to be "descrepancies" in Appendix G.. which has further some confusion as to "which" functions are "truly" an alias and which is the "master function".. I guess I need to "understand" what the master function is supposed to be, and what an alias is supposed to be. Perhaps I have these backwards, and thus the confusion, but some of this doesn't quite set right.. The first function in the list (chop) is labeled as the master function, and it's alias as (rtrim).. but when you go to the master function, (chop) it's documentation indicates it's the alias. and to see rtrim for details. There are some functions in this list like - fwrite() and fputs() - where fwrite is labled as the master and fputs the alias.. while the documentaion for both functions do not indicate either as an alias.. This goes on.. naturally some of these make perfect sense, if you looke at is_double() marked as a master - having aliases of is_float() and is_real().. the documentation corresponds perfectly.. i.e. if you call up is_float() or is_real() it directs you to is_double().. which brings "some" understanding back. and jives with what "I" would preceive as the relationship between a "master function" and an alias. Input on this matter would "greatly" be appreciated.. thanks a bunch. -- Edit this bug report at http://bugs.php.net/?id=12868&edit=1
Bug #17190 Updated: Date() gives error for date prior to 1-1-1970
ID: 17190 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows NT 4.0 PHP Version: 4.2.0 New Comment: Yep, the exact output is Invalid date range Warning: unexpected error in date() in D:\Test\t.php on line 8 Previous Comments: [2002-05-22 06:52:35] [EMAIL PROTECTED] Please, someone check on Windows the routine I wrote. Maybe on Windows date() return error if time is -1. [2002-05-22 06:50:46] [EMAIL PROTECTED] I'm using PHP 4.1.2 and no error on date() as got on: The only error is that date will allways show the date of time = -1 on invalid range (< 1970 OR > 2038). Is only a code bug. You should verify if $time is -1. [2002-05-14 04:08:10] [EMAIL PROTECTED] Look also www.php.net/strtotime [2002-05-14 03:53:09] [EMAIL PROTECTED] Reopening as a documentation problem. I threw a quick glance on the php.net/date page last night and I couldn't find it there. If it's nere, it needs to be outlined better, or well, documented at all. [2002-05-14 02:19:09] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. This is a problem in Windows, not in PHP. Derick 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/17190 -- Edit this bug report at http://bugs.php.net/?id=17190&edit=1
Bug #14732 Updated: Broken links in global.ent
ID: 14732 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: all PHP Version: 4.1.1 New Comment: Just a short update on links with probs: Connect failure: url.icap, url.openssl Host not found: url.mersenne.twister 404: Not Found: url.nis, url.stepwise.macosx-client, spec.hyperwave Thomas Previous Comments: [2002-04-06 06:10:41] [EMAIL PROTECTED] According to the checkent script, the following urls are still (or again) broken: url.icap: Could not open document: url.ldap.ldapworld: Could not open document: url.mersenne.twister: unknown host: www.scp.syr.edu url.nis: Could not open document: url.pfpro.download: unknown host: testmanager.signio.com Segmentation fault A segfault??? Damn... [2001-12-28 10:33:56] [EMAIL PROTECTED] broken links fixed for - adabas - ldap - libiconv [2001-12-28 09:55:54] [EMAIL PROTECTED] Please commit that little script into phpdoc into the scripts directory. We have some scripts there to test XML files, such as the entities.php or dbtags.php. It would be nice to make this test from time to time. To answer your current bug report, I have not time currently to skim through these addresses and find the right, so anybody with sufficient time, or who knows some of the right links would be welcome :) -- Goba [2001-12-28 08:04:05] [EMAIL PROTECTED] Hi, just wrote a little script and checked global.ent url.adabas: unknown host (www.adabas.com) url.hyperwave-proto: document not found (http://www.hyperwave.de/7.17-hg-prot) url.iicm: unknown host (iicm.edu) url.iptc: document not found or unreachable (http://www.iptc.org/) url.ldap.ldapworld: document not found or unreachable (http://elvira.innosoft.com/ldapworld) url.libiconv: document not found (http://clisp.cons.org/~haible/packages-libiconv.html) url.malinimg: document not found (http://www.pvv.org/~ssb/malin/bilder/mi/twain001.jpg) url.mersenne.twister: unknown host (www.scp.syr.edu) url.nis: document not found (http://www.desy.de/~sieversm/ypdoku/ypdoku/ypdoku.html) Georg -- Edit this bug report at http://bugs.php.net/?id=14732&edit=1
#20226 [NEW]: can't do "foo.php/path.inf" via cgi (with patch)
From: [EMAIL PROTECTED]
Operating system: Unix
PHP version: 4.2.3
PHP Bug Type: Feature/Change Request
Bug description: can't do "foo.php/path.inf" via cgi (with patch)
I use php as a cgi usuing Apache's "Action" directive. If I put a script
in /u/joe/pub/example.php and visit http://joe/example.php/foo then Apache
puts /example.php/foo in PATH_INFO, and PHP tries to open
/u/joe/pub/example.php/foo. (Internal server error; premature end of
script headers)
This patch checks /u, /u/joe, /u/joe/pub, etc.; if one of them is a
regular file (in this case /u/joe/pub/example.php) then that file is used
as the script filename. Now the script runs, with the entire PATH_INFO
passed to it. (It's up to the script to figure out which part to
ignore.)
--- main/fopen_wrappers.c.orig Fri Aug 23 01:00:49 2002
+++ main/fopen_wrappers.c Sun Nov 3 02:54:26 2002
@@ -388,6 +388,23 @@
SG(request_info).path_translated = NULL;
return FAILURE;
}
+
+ /* check for /home/joe/public_html/example.php/pathinfo */
+ if (1) {
+ char *s;
+ for (s=filename+1; *s; s++) {
+ if (*s == PHP_DIR_SEPARATOR && *(s-1) != PHP_DIR_SEPARATOR) {
+ *s = 0;
+ if (0 == stat (filename, &st)) {
+ if (S_ISREG(st.st_mode)) {
+ break;
+ }
+ }
+ *s = PHP_DIR_SEPARATOR;
+ }
+ }
+ }
+
fp = VCWD_FOPEN(filename, "rb");
/* refuse to open anything that is not a regular file */
--
Edit bug report at http://bugs.php.net/?id=20226&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20226&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20226&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20226&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20226&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20226&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20226&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20226&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20226&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20226&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20226&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20226&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20226&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20226&r=isapi
Bug #16220 Updated: mistake in writing
ID: 16220 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.1.2 New Comment: This is already fixed in CVS, and appear on the net after the next automatic build-process. Thanks for notification! Previous Comments: [2002-03-22 10:20:46] [EMAIL PROTECTED] reclassified [2002-03-22 09:20:04] [EMAIL PROTECTED] http://de.php.net/manual/de/preface.php there is a mistake in writing " Vorwort (...) Aber PHP knn noch mehr. (...)" you have to change "knn" and make "kann" out of it. please excuse my bad english. so long etrigan.de -- Edit this bug report at http://bugs.php.net/?id=16220&edit=1
Bug #16234 Updated: important language features only mentioned in passing
ID: 16234 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: WinXP PHP Version: 4.1.2 New Comment: "global" as well as "static" are listed in the "List of Keywords" (http://at.php.net/manual/en/reserved.php), and are described in the Language Reference (exactly Variable Scope, http://at.php.net/manual/en/language.variables.scope.php), which is also linked from the Keyword-list. Previous Comments: [2002-03-23 11:49:07] [EMAIL PROTECTED] There is no page for the keywords "global" or "static". Neither can be found in the index. There are many things like this that are only mentioned in passing, without having an actual definition. -- Edit this bug report at http://bugs.php.net/?id=16234&edit=1
#21946 [Com]: Trying to create COM object - Apache crash
ID: 21946
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows NT 4.0, Service pack 6a
PHP Version: 4.3.0
New Comment:
I had this same issue on Win2k Pro running Apache 3.1.26.
I have other php scripts that were running fine. Only the one with COM
was blowing up.
Application popup: Apache.exe - Application Error : The instruction at
"0x10030727" referenced memory at "0x04243b30". The memory could not be
"read".
The latest stable release solved my issue. Thanks!
Previous Comments:
[2003-01-29 18:26:16] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-01-29 15:03:55] [EMAIL PROTECTED]
Original lines from ASP :
Q= Server.CreateObject("ixsso.Query");
util = Server.CreateObject("ixsso.Util");
Q.Query = "test";
Q.Columns = "DocTitle, Vpath, filename, size, write,
characterization, rank, path, DocSubject, DocKeywords";
RS = Q.CreateRecordSet("nonsequential");
but as I said I have commented all the lines after first line. I have
read in some forum that someone did succeed to integrate PHP with
Microsoft Index Server.
Best regards,
Dominik
[2003-01-29 14:58:09] [EMAIL PROTECTED]
I'm trying to write a search form using PHP Version 4.3.0, Apache
version 2.0.44, Windows NT 4.0 with service pack 6 and Microsoft Index
Server 2.0. I used example from IISSamples - ASP (query.asp). ASP
example works fine on IIS 4.0 - I use Index Server for indexing Word
and PDF documents and is essential part of my intranet. After submiting
a form (using POST method), page calls itself and retrieves a search
string. The first and only line after it causes Apache to crash. The
line is Index Server COM object creation using line :
$Q = new COM("ixsso.Query");
$Util = new COM("ixsso.Util");
I have commented everything bellow including the second line and crash
is reproducible.
Hope enough information was provided.
Best regards,
Dominik
[2003-01-29 12:12:40] [EMAIL PROTECTED]
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.
[2003-01-29 11:34:52] [EMAIL PROTECTED]
Forgot to mention that 2.0.43 and 2.0.44 are apache versions.
Best regards,
Dominik
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/21946
--
Edit this bug report at http://bugs.php.net/?id=21946&edit=1
#20575 [NEW]: arg-separator.output default value causes invalid HTML
From: [EMAIL PROTECTED] Operating system: Linux 2.2.19 PHP version: 4.2.3 PHP Bug Type: URL related Bug description: arg-separator.output default value causes invalid HTML The arg-separator.output default value of "&" causes an invalid HTML/XHTML page to be displayed when PHP attaches the PHPSESSID to any hrefs on the page that already have a querystring. eg: becomes: which is invalid HTML. It should be: This issue causes problems when sending pages as application/xhtml+xml as Mozilla will detect the error and refuse to display the page. Changing the default value (to "&") should theoretically not cause any backwards compatibility issues since it gets translated (to "&") by the web browser. It will however, help those of us who _do not_ have access to the PHP configuration files on the web server. -- Edit bug report at http://bugs.php.net/?id=20575&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20575&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20575&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20575&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20575&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20575&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20575&r=support Expected behavior: http://bugs.php.net/fix.php?id=20575&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20575&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20575&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20575&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20575&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20575&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20575&r=isapi
#20674 [NEW]: extra quotes added to page
From: [EMAIL PROTECTED] Operating system: Linux 7.2 PHP version: 4.2.3 PHP Bug Type: Session related Bug description: extra quotes added to page I have the following line of code in a script: echo ""; Which worked just fine. I then added a session_register statement to the script: "; ?> The problem was that after this when the script processes for the first time the generated source code becomes: "; ?> Note the spurious set of quotes around window.open(. These quotes make the button inoperative. If I do a refresh, the quotes disappear and it works fine. I've made sure the browser cache is clear so I know that isn't the problem. I've replicated the problem multiple times. The problem could be browser related but if the same source is being sent each time from the Apache server, I'm not sure why the browser would interpret it differently on the initial load of the page as opposed to following a refresh. Considering the browser is IE, anything is possible. './configure' '--with-mysql=/usr/local/mysql' '--with-apxs=/usr/local/apache/bin/apxs' '--enable-bcmath' '--with-gd' '--enable-sockets' '--enable-track-vars' '--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/local/lib' '--with-zlib-dir=/usr/lib' '--with-png' '--with-ttf' -- Edit bug report at http://bugs.php.net/?id=20674&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20674&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20674&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20674&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20674&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20674&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20674&r=support Expected behavior: http://bugs.php.net/fix.php?id=20674&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20674&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20674&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20674&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20674&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20674&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20674&r=isapi
#22439 [NEW]: fsockopen - Segmentation fault
From: tom at linuxsystems dot be
Operating system: Linux 2.4.20
PHP version: 4.3.1
PHP Bug Type: Sockets related
Bug description: fsockopen - Segmentation fault
Hi all,
I compiled a new webserver (Apache/1.3.27 (Unix) PHP/4.3.1 mod_perl/1.27)
and moved my scripts (from a Apache/1.3.27 (Unix) PHP/4.3.0 mod_perl/1.27)
to the new server.
One of my scripts contains following code:
$webport = fsockopen ("www.linuxsystems.be", 80, $errno, $errstr, 2);
if ($webport)
print("Web server: [ ON ] ");
else
print("Web server: [ OFF ] ");
$dnsport = fsockopen ("ns1.linuxsystems.be", 53, $errno, $errstr, 2);
if ($dnsport)
print("DNS server: [ ON ] ");
else
print("DNS server: [ OFF ] ");
What happens:
When a service is not on (and fsockopen can not connect) I get a
Segmentation fault in Apache:
[Wed Feb 26 16:25:08 2003] [notice] child pid 32070 exit
signal Segmentation fault (11)
I copied to my other webserver (with 4.3.0) and there everythings run
fine.
My phpinfo (new machine): http://customer.linuxsystems.be/phpinfo.php
Old phpinfo (where script can run on):
http://www.internetgids.be/phpinfo.php
Help is welcome :-)
Kind Regards,
Tom Myny
--
Edit bug report at http://bugs.php.net/?id=22439&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22439&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22439&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22439&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22439&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22439&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22439&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22439&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22439&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22439&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22439&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22439&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22439&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22439&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22439&r=gnused
#22439 [Fbk->Csd]: fsockopen - Segmentation fault
ID: 22439
User updated by: tom at linuxsystems dot be
Reported By: tom at linuxsystems dot be
-Status: Feedback
+Status: Closed
Bug Type: Sockets related
Operating System: Linux 2.4.20
PHP Version: 4.3.1
New Comment:
New code works perfect!
Thx Sniper, i will see this code in 4.3.2 then ;-)
Kind Regards,
Tom Myny
Previous Comments:
[2003-02-26 09:47:42] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-02-26 09:46:56] tom at linuxsystems dot be
Hi all,
I compiled a new webserver (Apache/1.3.27 (Unix) PHP/4.3.1
mod_perl/1.27) and moved my scripts (from a Apache/1.3.27 (Unix)
PHP/4.3.0 mod_perl/1.27) to the new server.
One of my scripts contains following code:
$webport = fsockopen ("www.linuxsystems.be", 80, $errno, $errstr, 2);
if ($webport)
print("Web server: [
ON ] ");
else
print("Web server: [ OFF ] ");
$dnsport = fsockopen ("ns1.linuxsystems.be", 53, $errno, $errstr, 2);
if ($dnsport)
print("DNS server: [ ON ] ");
else
print("DNS server: [ OFF ] ");
What happens:
When a service is not on (and fsockopen can not connect) I get a
Segmentation fault in Apache:
[Wed Feb 26 16:25:08 2003] [notice] child pid 32070 exit
signal Segmentation fault (11)
I copied to my other webserver (with 4.3.0) and there everythings run
fine.
My phpinfo (new machine): http://customer.linuxsystems.be/phpinfo.php
Old phpinfo (where script can run on):
http://www.internetgids.be/phpinfo.php
Help is welcome :-)
Kind Regards,
Tom Myny
--
Edit this bug report at http://bugs.php.net/?id=22439&edit=1
#24155 [NEW]: imagerotate fail to copy entire source image
From: tom at gksystems dot com
Operating system: all
PHP version: 4.3.2
PHP Bug Type: GD related
Bug description: imagerotate fail to copy entire source image
Description:
When rotating an image which is taller-than-wide through an angle > 225
and <= 315 degrees, only a square portion of the image is copied. The
remainder is black.
ext/libgd/gd.c has a bug in gdImageRotate270:
for (uY = 0; uYsx; uY++) {
for (uX = 0; uXsx; uX++) {
uY and uX both have a range of src->sx, so only a square region is copied.
The first line should be:
for (uY = 0; uYsy; uY++) {
Reproduce code:
---
// June 12, 2003 Tom Robinson
// Display a 30x50 yellow rectangle, rotated 270 degrees CCW.
$im = ImageCreateTrueColor(30,50);
imagefill($im,0,0,16777215-255);
$im = imagerotate($im,270,255);
header("Content-type: image/png");
imagepng($im);
Expected result:
See a yellow rectangle.
Actual result:
--
See a rectangle with a yellow square and the rest is black.
--
Edit bug report at http://bugs.php.net/?id=24155&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24155&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24155&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24155&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24155&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24155&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24155&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24155&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24155&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24155&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24155&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24155&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24155&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24155&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24155&r=gnused
#31130 [NEW]: DomDocument::saveHTML() produces outdated HTML
From: tom at whyscream dot net
Operating system: Linux (gentoo)
PHP version: 5.0.3
PHP Bug Type: DOM XML related
Bug description: DomDocument::saveHTML() produces outdated HTML
Description:
The HTML that is generated by DomDocument::saveHTML() (and probably
saveHTMLFile() too) does not validate as XHTML (as in '1.0 Transitional').
In stead it follows common practice for HTML4.
Since some time, it's Good Practice (TM) to use simple rules like:
- always give a value to an attribute
- close single-tag elements with a '/>' instead of '>'
etc.
All common browsers understand this syntax, even when a HTML 4.0 DTD is
specified.
With the current implementation, it's impossible to create valid XHTML
(snippets) using the php5 DOM extension.
Reproduce code:
---
$doc = new DomDocument();
$input = $doc->createElement('input');
$input->setAttribute('type', 'checkbox');
$input->setAttribute('checked', 'checked');
$doc->appendChild($input);
echo $doc->saveHTML();
Expected result:
This should generate a string like:
which is valid XHTML.
Actual result:
--
The generated string looks like this:
This code gives 2 parse errors:
- no value for attribute 'checked'
- end tag for 'input' omitted (i,e, missing the forward slash)
--
Edit bug report at http://bugs.php.net/?id=31130&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31130&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31130&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31130&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31130&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31130&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31130&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31130&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31130&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31130&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31130&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31130&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31130&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31130&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31130&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31130&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31130&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31130&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31130&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31130&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31130&r=mysqlcfg
#31130 [WFx]: DomDocument::saveHTML() produces outdated HTML
ID: 31130
User updated by: tom at whyscream dot net
Reported By: tom at whyscream dot net
Status: Wont fix
Bug Type: DOM XML related
Operating System: Linux (gentoo)
PHP Version: 5.0.3
New Comment:
When I submitted the bug, I had some problems with saveXML() that
prevented me from producing usable XHTML with it. I found out how to
work around these issues the next day, and of course I was wrong (it
was there all the time, but I missed it while checking the manual).
Sorry for bothering you :)
Previous Comments:
[2004-12-17 07:47:42] [EMAIL PROTECTED]
It's called saveHTML and not saveXHTML for a reason ;) saveHTML
produces HTML 4.0 and as Derick pointed out, you have to use saveXML
(which works perfectly fine for me).
If you really want to have changed that, complain to the libxml2
people. We just use their function.
[2004-12-16 20:03:37] [EMAIL PROTECTED]
Tried ->saveXML() ?
[2004-12-16 18:36:03] tom at whyscream dot net
Description:
The HTML that is generated by DomDocument::saveHTML() (and probably
saveHTMLFile() too) does not validate as XHTML (as in '1.0
Transitional'). In stead it follows common practice for HTML4.
Since some time, it's Good Practice (TM) to use simple rules like:
- always give a value to an attribute
- close single-tag elements with a '/>' instead of '>'
etc.
All common browsers understand this syntax, even when a HTML 4.0 DTD is
specified.
With the current implementation, it's impossible to create valid XHTML
(snippets) using the php5 DOM extension.
Reproduce code:
---
$doc = new DomDocument();
$input = $doc->createElement('input');
$input->setAttribute('type', 'checkbox');
$input->setAttribute('checked', 'checked');
$doc->appendChild($input);
echo $doc->saveHTML();
Expected result:
This should generate a string like:
which is valid XHTML.
Actual result:
--
The generated string looks like this:
This code gives 2 parse errors:
- no value for attribute 'checked'
- end tag for 'input' omitted (i,e, missing the forward slash)
--
Edit this bug report at http://bugs.php.net/?id=31130&edit=1
#25779 [NEW]: ftp_ssl_connect()
From: tom at smediag dot com
Operating system: Unix
PHP version: 4.3.3
PHP Bug Type: FTP related
Bug description: ftp_ssl_connect()
Description:
Hello,
I am not sure if everything is ok in ftp_ssl_connect() function ... I am
trying to connect ftp server using this function but I cant ... I will be
grateful if you can tell me what should I do ... or ... what should I
install on the server .
Reproduce code:
---
define('AUTO_TXN_HOST', 'ftp.domain.com');
$sftp = ftp_ssl_connect( AUTO_TXN_HOST, 22 ); // problem is in this line
Expected result:
I should be connected
Actual result:
--
Warning: ftp_ssl_connect(): php_network_getaddresses: getaddrinfo failed:
Name or service not known in /home/httpd/my/account/site/script.php
--
Edit bug report at http://bugs.php.net/?id=25779&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25779&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25779&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25779&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25779&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25779&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25779&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25779&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25779&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25779&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25779&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25779&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25779&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25779&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25779&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25779&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25779&r=float
#26184 [NEW]: unable to detect character encoding
From: tom at nooper dot com Operating system: Redhat 8 PHP version: 4.3.4 PHP Bug Type: mbstring related Bug description: unable to detect character encoding Description: I get the following error generated: mb_convert_encoding(): Unable to detect character encoding Up to 4.3.3 this works no problem. I compiled php with same options including the --enable-mbstring=all. If I look at phpinfo() output it seems that all the languages are missing no matter if I compile with --enable-mbstring=ja or other. I noticed another bug which was closed that fixed a bug in the reporting of phpinfo() for mbstring where it was suggested that all languages were included now from 4.3.4 independant of compile options. The code snippet that was used to generate the error above is simply: echo mb_convert_encoding($jText, 'SJIS','AUTO'); where $jText is some "EUC-JP" text. I tried the latest php snapshot from cvs also and it also doesn't work. If you need a short example program to reproduce this problem, I can look into it from Monday/Tuesday. -- Edit bug report at http://bugs.php.net/?id=26184&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26184&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26184&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26184&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26184&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26184&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26184&r=support Expected behavior: http://bugs.php.net/fix.php?id=26184&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26184&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26184&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26184&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26184&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26184&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26184&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26184&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26184&r=float
#26184 [NoF->Csd]: unable to detect character encoding
ID: 26184 User updated by: tom at nooper dot com Reported By: tom at nooper dot com -Status: No Feedback +Status: Closed Bug Type: mbstring related Operating System: Redhat 8 PHP Version: 4.3.4 Assigned To: moriyoshi New Comment: Thanks guys... sorry for lack of feedback. I've not had time to test a new php build in dev yet since trying it last time. I'll reopen the bug if the suggested fix fails, but for now you can assume it works. Previous Comments: [2003-11-17 18:19:32] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-11-11 15:38:02] [EMAIL PROTECTED] Please try setting mbstring.language to the appropriate language name in your php.ini. [2003-11-09 04:00:52] tom at nooper dot com Description: I get the following error generated: mb_convert_encoding(): Unable to detect character encoding Up to 4.3.3 this works no problem. I compiled php with same options including the --enable-mbstring=all. If I look at phpinfo() output it seems that all the languages are missing no matter if I compile with --enable-mbstring=ja or other. I noticed another bug which was closed that fixed a bug in the reporting of phpinfo() for mbstring where it was suggested that all languages were included now from 4.3.4 independant of compile options. The code snippet that was used to generate the error above is simply: echo mb_convert_encoding($jText, 'SJIS','AUTO'); where $jText is some "EUC-JP" text. I tried the latest php snapshot from cvs also and it also doesn't work. If you need a short example program to reproduce this problem, I can look into it from Monday/Tuesday. -- Edit this bug report at http://bugs.php.net/?id=26184&edit=1
#27591 [NEW]: JPEG 2000 IPTC not found by GetImageSize + iptcparse
From: tom at kornack dot com Operating system: Mac OS X 10.3.2 PHP version: 5CVS-2004-03-14 (dev) PHP Bug Type: GetImageSize related Bug description: JPEG 2000 IPTC not found by GetImageSize + iptcparse Description: JPEG 2000 IPTC blocks are not returned by the GetImageSize imageinfo array. This information is increasingly important with the next generation of digital cameras that will call for compressed, 16-bit files. Reproduce code: --- A sample JPEG 2000 image file is available here: http://listera.org/pub/iptc/iptctestimage.jp2 This code is also available here: http://listera.org/pub/iptc/iptctest.phps A sample JPEG that does work is available here: http://listera.org/pub/iptc/iptctestimage.jpg Expected result: Title: Title Metadata Actual result: -- Title: -- Edit bug report at http://bugs.php.net/?id=27591&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27591&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27591&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27591&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27591&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27591&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27591&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27591&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27591&r=support Expected behavior: http://bugs.php.net/fix.php?id=27591&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27591&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27591&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27591&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27591&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27591&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27591&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27591&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27591&r=float
#27595 [NEW]: throw new Exception() crash
From: tom at webcrumb dot com Operating system: Windows XP PHP version: 5.0.0b4 (beta4) PHP Bug Type: Zend Engine 2 problem Bug description: throw new Exception() crash Description: The following test code runs fine the first 29 (your mileage may vary) times the page is viewed. On the 30th time, CPU usage shoots to 100% briefly and Apache 2 crashes hard. '30' is the magic number for my system, I imagine your mileage may vary if this is - as I suspect - some sort of memory corruption bug. The problem appears to be with the exception handling mechanism, since I can comment all the code out, or attempt to refresh the page 50+ times with a class declaration / simple method call. Reproduce code: --- getMessage(); } ?> Expected result: 'Testing' should appear on screen. Actual result: -- For the first 29 times the page is viewed, 'Testing' appears. On the 30th time, Apache 2 crashes hard. -- Edit bug report at http://bugs.php.net/?id=27595&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27595&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27595&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27595&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27595&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27595&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27595&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27595&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27595&r=support Expected behavior: http://bugs.php.net/fix.php?id=27595&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27595&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27595&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27595&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27595&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27595&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27595&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27595&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27595&r=float
#27591 [Fbk->Opn]: JPEG 2000 IPTC not found by GetImageSize + iptcparse
ID: 27591 User updated by: tom at kornack dot com Reported By: tom at kornack dot com -Status: Feedback +Status: Open Bug Type: GetImageSize related Operating System: Mac OS X 10.3.2 PHP Version: 5CVS-2004-03-14 (dev) New Comment: Thanks for the speedy response! iptctestimate.jp2 was created using Adobe Photoshop and the j2k plugin. I have had no problems with these files thus far, opening then with OS X native applications, web browsers, etc. I have not been able to get tbe reference jj2000 application to run on OS X yet. Here's a new file to try, created using Graphic Converter: http://listera.org/pub/iptc/iptctestimage2.jp2 Pierre: Please let me know which program you'd like me to try. Does the code actually work on jp2 files that you generate? Tom Previous Comments: [2004-03-14 08:44:56] [EMAIL PROTECTED] Hello, It seems that this jp2 image is broken. None of the tools I used to test can open it, even not the jp2 reference tools. Which tools have been used to create this file? pierre [2004-03-14 00:42:50] tom at kornack dot com Description: JPEG 2000 IPTC blocks are not returned by the GetImageSize imageinfo array. This information is increasingly important with the next generation of digital cameras that will call for compressed, 16-bit files. Reproduce code: --- A sample JPEG 2000 image file is available here: http://listera.org/pub/iptc/iptctestimage.jp2 This code is also available here: http://listera.org/pub/iptc/iptctest.phps A sample JPEG that does work is available here: http://listera.org/pub/iptc/iptctestimage.jpg Expected result: Title: Title Metadata Actual result: -- Title: -- Edit this bug report at http://bugs.php.net/?id=27591&edit=1
#23331 [Com]: Memory leak in ISAPI
ID: 23331 Comment by: tom at cliksoftware dot com Reported By: jakub at icewarp dot com Status: No Feedback Bug Type: IIS related Operating System: win32 PHP Version: 4CVS, 5CVS New Comment: This bug appears to be still outstanding, is the fix in the pipeline yet? 4.3.5 RC_3 seemed to fix it a bit, but RC_4 has made it worse. It still it unstable on high traffic boards, please fix soon :) Previous Comments: [2004-03-18 06:30:14] osvetlik at kerio dot com We are embedding PHP in our products and we have the same problem. It is very important for us to have this issue solved ASAP, if we may help, please, tell us how. [2003-12-30 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2003-12-16 14:31:02] msisolak at yahoo dot com The recent changes have fixed a big chunk of the leaks, but there are still a couple of memory types that are not getting freed. I'll have a couple of more patches to close out this bug soon. [2003-12-14 20:16:31] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Some fixes have been committed recently which should fix this bug. Please try the snapshot out. [2003-10-04 08:40:57] jakub at icewarp dot com I think I tracked down the leak. In this function: TSRM_API void *ts_resource_ex(ts_rsrc_id id, THREAD_T *th_id) There's at the end this: TSRM_SAFE_RETURN_RSRC(thread_resources->storage, id, thread_resources->count); Now if I uncomment this. It does not leak the memory for the 2 calls from my last post. The call translates to return &thread_resources->storage; Why should this leak? Please, C++ people help us here. 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/23331 -- Edit this bug report at http://bugs.php.net/?id=23331&edit=1
#27802 [NEW]: FastCGI PHP_FCGI_CHILDREN default unstable and undocumented.
From: tom at hur dot st Operating system: FreeBSD 4.9-STABLE PHP version: 4.3.5 PHP Bug Type: CGI related Bug description: FastCGI PHP_FCGI_CHILDREN default unstable and undocumented. Description: If you don't set the env variable PHP_FCGI_CHILDREN, PHP doesn't default to 8 as README.FastCGI suggests; it doesn't bother spawning extra processes at all (default is 0). After PHP_FCGI_MAX_REQUESTS, PHP segfaults. No apparant useful information from core or ktrace, other than seeing that it's not forking and falling over after exactly PHP_FCGI_MAX_REQUESTS; the fix looks fairly easy, though.. except maybe at children = 0 :) -- Edit bug report at http://bugs.php.net/?id=27802&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27802&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27802&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27802&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27802&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27802&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27802&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27802&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27802&r=support Expected behavior: http://bugs.php.net/fix.php?id=27802&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27802&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27802&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27802&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27802&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27802&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27802&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27802&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27802&r=float
#27741 [Com]: IIS down while request .php file
ID: 27741 Comment by: tom at cliksoftware dot com Reported By: yjt at 5kg dot net Status: Closed Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.5 New Comment: I got this error again, using IIS/Win2k Server/PHP (ISAPI) 4.3.6RC3_dev - are you sure its completely fixed? Previous Comments: [2004-04-08 05:16:29] cash at ourupgrade dot dot net I have the same problem, it makes IIS down, and all website can not be accessed. Now I use 4.3.6 rc3, it fix this problem. [2004-04-04 15:24:42] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. [2004-04-04 15:19:22] robert at shilston dot com I downloaded the 4.3.5 zip package for windows, and am running as ISAPI on Windows XP Pro sp1. Every few page loads, "Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0" (page itself is ""). [2004-04-04 00:36:13] jaw959 at new dot rr dot com I'm getting this bug... I was upgrading PHP from 4.3.4 to 4.3.5. I'm not loading any additional extensions, and I used the same .ini file as with 4.3.4. I completely wiped out the C:\PHP files, and then loaded in the new ones (and made a new copy of php4ts.dll to system32). Now, all of a sudden, I get Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0. Warning: Unknown list entry type in request shutdown (2) in C:\Inetpub\wwwroot\index.php on line 2 Then, dllhost gets a memory error, and all .php scripts on my website give this error: "The remote procedure call failed and did not execute." Shortly after, it works again, and then shortly after that I get the warnings again, and then it continues in the cycle of normal operation, warnings, and RPC failing. If you have any ideas, please let me know. [2004-04-01 02:38:23] flekj at atlas dot cz We have the same problem... Unknown list entry type in request shutdown (2) in Unknown on line 0... and a lot of following bugs in every script... It seems that php is running for a short time correctly and then crashes.. We are not using Zend Encoder, so reason of this bug will be different. There was no change in our php.ini file, we use the same ini file in previous version of PHP (4.3.4) without any problem... 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/27741 -- Edit this bug report at http://bugs.php.net/?id=27741&edit=1
#29612 [NEW]: Variable $php_errormsg disappears
From: tom at bitworks dot de
Operating system: Debian woody Apache/1.3.27 (Unix
PHP version: 4.3.8
PHP Bug Type: *Directory/Filesystem functions
Bug description: Variable $php_errormsg disappears
Description:
Searching for the behavior of all file functions and the right locking
mechanisms I tried to use fopen(filename,xb) with former umask(0222). That
was intended to trigger an error and look into $php_errormsg
But $php_errormsg was disappeared
Reproduce code:
---
error_reporting(E_ALL);
ini_set('track_errors','1');
$dateiname = 'opentest123.txt';
$mask = umask(0222);
echo "Mask: $mask";
$fh = fopen($dateiname,'xb+');
$_errors = debug_backtrace();
if (!$fh)
{
echo "Fehler: $php_errormsg";
echo "Fehler: $php_errormsg";
echo '';
print_r($_errors);
echo '';
}
else
{
echo "Datei $dateiname wurde angelegt";
$write_ok = fwrite($fh, 'Testtext');
echo "Schreibversuch in $dateiname: $php_errormsg";
}
Expected result:
Fehler: failed to open stream: Permission denied
Actual result:
--
Notice: Undefined variable: php_errormsg in
/home/thomas/public_html/test/artikel_locking/opentest.php on line 27
== echo "Schreibversuch in $dateiname: $php_errormsg";
--
Edit bug report at http://bugs.php.net/?id=29612&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29612&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29612&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29612&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29612&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29612&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29612&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29612&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29612&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29612&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29612&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29612&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29612&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29612&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29612&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29612&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29612&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29612&r=float
#29612 [Opn]: Variable $php_errormsg disappears
ID: 29612
User updated by: tom at bitworks dot de
Reported By: tom at bitworks dot de
Status: Open
Bug Type: *Directory/Filesystem functions
Operating System: Debian woody Apache/1.3.27 (Unix
PHP Version: 4.3.8
New Comment:
the open command was only:
$fh = fopen($dateiname,'xb');
without '+'
Previous Comments:
[2004-08-11 13:28:21] tom at bitworks dot de
Description:
Searching for the behavior of all file functions and the right locking
mechanisms I tried to use fopen(filename,xb) with former umask(0222).
That was intended to trigger an error and look into $php_errormsg
But $php_errormsg was disappeared
Reproduce code:
---
error_reporting(E_ALL);
ini_set('track_errors','1');
$dateiname = 'opentest123.txt';
$mask = umask(0222);
echo "Mask: $mask";
$fh = fopen($dateiname,'xb+');
$_errors = debug_backtrace();
if (!$fh)
{
echo "Fehler: $php_errormsg";
echo "Fehler: $php_errormsg";
echo '';
print_r($_errors);
echo '';
}
else
{
echo "Datei $dateiname wurde angelegt";
$write_ok = fwrite($fh, 'Testtext');
echo "Schreibversuch in $dateiname: $php_errormsg";
}
Expected result:
Fehler: failed to open stream: Permission denied
Actual result:
--
Notice: Undefined variable: php_errormsg in
/home/thomas/public_html/test/artikel_locking/opentest.php on line 27
== echo "Schreibversuch in $dateiname: $php_errormsg";
--
Edit this bug report at http://bugs.php.net/?id=29612&edit=1
#29424 [Com]: Width and Height inverted for JPEG2000 files
ID: 29424 Comment by: tom at kornack dot com Reported By: bertrand dot bourgier at free dot fr Status: Open Bug Type: GetImageSize related Operating System: Windows 2000 Pro PHP Version: 5.0.0 New Comment: I have seen this with php 5.0.0 on Mac OS X. I just had to code a kludge to fix this! Previous Comments: [2004-07-28 11:50:08] bertrand dot bourgier at free dot fr Description: Take a JPEG2000 file (indifferently JPC or JP2 format). JPC format sample file: http://www.crc.ricoh.com/~gormish/jpeg2000conformance/J2KP4files/codestreams_profile0/p0_04.j2k JP2 format sample file: http://www.crc.ricoh.com/~gormish/jpeg2000conformance/J2KP4files/testfiles_jp2/file1.jp2 I downloaded those 2 files so that I can do my tests locally and avoid any network related issue. Then, when I run 'getimagesize' on those JPEG2000 files, I get a result, but the Width and Height information are inverted. Reproduce code: --- Test 1: Height: $height"; ?> Test 2: Height: $height"; ?> Expected result: Test 1: Width: 640 Height: 480 Test 2: Width: 768 Height: 512 Actual result: -- Test 1: Width: 480 Height: 640 Test 2: Width: 512 Height: 768 As you can see, Width and Height are inverted. -- Edit this bug report at http://bugs.php.net/?id=29424&edit=1
#29548 [Opn]: Apache2/PHP Module crashes
ID: 29548 User updated by: tom at ideaweb dot de Reported By: tom at ideaweb dot de Status: Open Bug Type: XSLT related Operating System: Debian Testing PHP Version: 4.3.8 New Comment: it happens with sablot 1.0.1. with 0.98 there are no problems. Previous Comments: [2004-09-04 21:47:43] [EMAIL PROTECTED] Use ext/domlxml and its xslt support instead. [2004-08-07 13:49:00] [EMAIL PROTECTED] Looks like a problem in the XSLT/Sablotron extension of PHP 4.3 (not my area ;) ) [2004-08-06 15:18:12] tom at ideaweb dot de Description: hi, i have a small content management system, which transforms xml documents to evaluated php templates. with huge data the apache2.0.50 crashes with the following message in the error log: httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:15:58 2004] [notice] child pid 20982 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:16:08 2004] [notice] child pid 21091 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:23:50 2004] [notice] child pid 21440 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:50:11 2004] [notice] child pid 28053 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:52:20 2004] [notice] child pid 28197 exit signal Aborted (6) if i change some content in cdata notes, the transformation over sabltron xsl works in some cases again. with small documents no problem. Reproduce code: --- sorry its to complex to post this in 20 line. if you have questions contact me. Expected result: no crashes at any kind programming failures... Actual result: -- root:/etc/firewall# /www/apache/current/bin/httpd -X Aborted the apache webserver quits only with "Aborted",the the same error message in the error log and without a core file. ??? -- Edit this bug report at http://bugs.php.net/?id=29548&edit=1
#30494 [NEW]: sin() seems to give a wrong output if you convert it to radius
From: tom at neighbour dot nl Operating system: Windows XP PHP version: 4.3.9 PHP Bug Type: Math related Bug description: sin() seems to give a wrong output if you convert it to radius Description: I have used this function to get the angle of B in a triangle. $B = rad2deg( asin(10/14) ); The output seems to be correct giving me around 45 degrees when i use the asin() function. But when i use the sin() function to get the length of side b in a different triangle: rad2deg( SIN(45) ); it should be giving me around 0.7 back but it gives me 48. When i remove the rad2deg() function and use normal radius sin(45) then it gives me the corect answer which is 0.85 Reproduce code: --- $B = rad2deg( asin(10/14) ); rad2deg( SIN(45) ); Expected result: I expect to see the proper answer which is 0.7 instead of getting 48 Actual result: -- As stated above my actual result is 48 -- Edit bug report at http://bugs.php.net/?id=30494&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30494&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30494&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30494&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30494&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30494&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30494&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30494&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30494&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30494&r=support Expected behavior: http://bugs.php.net/fix.php?id=30494&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30494&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30494&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30494&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30494&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30494&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30494&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30494&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30494&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30494&r=mysqlcfg
#24860 [NEW]: register_shutdown_function param doesn't take array(obj, method)
From: tom at minnesota dot com Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4.3.2 PHP Bug Type: Scripting Engine problem Bug description: register_shutdown_function param doesn't take array(obj, method) Description: It seems like register_shutdown_function doesn't take a param of array(obj, method): register_shutdown_function(array(&$this, 'MyDestructor')); --- Fails with this error: Warning: Unknown(): Unable to call Array() - function does not exist in Unknown on line 0. Reproduce code: --- Expected result: Pseudo destructor to perform properly with register_shutdown_function taking an array(obj, method). Actual result: -- Warning: Unknown(): Unable to call Array() - function does not exist in Unknown on line 0. -- Edit bug report at http://bugs.php.net/?id=24860&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24860&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24860&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24860&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24860&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24860&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24860&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24860&r=support Expected behavior: http://bugs.php.net/fix.php?id=24860&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24860&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24860&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24860&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24860&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24860&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24860&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24860&r=gnused
#24860 [Fbk->Csd]: register_shutdown_function param doesn't take array(obj, method)
ID: 24860 User updated by: tom at minnesota dot com Reported By: tom at minnesota dot com -Status: Feedback +Status: Closed Bug Type: Scripting Engine problem Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4.3.2 New Comment: php4-STABLE-200307300130 worked. Previous Comments: [2003-07-29 19:40:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Works fine here with the exact code you pasted. Please try the snapshot indicated above. [2003-07-29 17:16:09] tom at minnesota dot com Description: It seems like register_shutdown_function doesn't take a param of array(obj, method): register_shutdown_function(array(&$this, 'MyDestructor')); --- Fails with this error: Warning: Unknown(): Unable to call Array() - function does not exist in Unknown on line 0. Reproduce code: --- Expected result: Pseudo destructor to perform properly with register_shutdown_function taking an array(obj, method). Actual result: -- Warning: Unknown(): Unable to call Array() - function does not exist in Unknown on line 0. -- Edit this bug report at http://bugs.php.net/?id=24860&edit=1
#24864 [NEW]: Warning: Unexpected character in input
From: tom at minnesota dot com Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4CVS-2003-07-30 (stable) PHP Bug Type: CGI related Bug description: Warning: Unexpected character in input Description: When accessing a simple page with via the browser and php (cgi): I get: --- Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Parse error: parse error in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 --- Works fine with apache module and older 4.3.1 cgi. Reproduce code: --- Expected result: Show the phpinfo page. -- Edit bug report at http://bugs.php.net/?id=24864&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24864&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24864&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24864&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24864&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24864&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24864&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24864&r=support Expected behavior: http://bugs.php.net/fix.php?id=24864&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24864&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24864&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24864&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24864&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24864&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24864&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24864&r=gnused
#24864 [Opn]: Warning: Unexpected character in input
ID: 24864 User updated by: tom at minnesota dot com Reported By: tom at minnesota dot com Status: Open Bug Type: CGI related Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2003-07-30 (stable) New Comment: I should also note that accessing the phpinfo.phtml page via shell and php (cgi) directly works fine. It shows that error when accessing the script with php cgi through Apache. Previous Comments: [2003-07-30 01:18:14] tom at minnesota dot com Description: When accessing a simple page with via the browser and php (cgi): I get: --- Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Parse error: parse error in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 --- Works fine with apache module and older 4.3.1 cgi. Reproduce code: --- Expected result: Show the phpinfo page. -- Edit this bug report at http://bugs.php.net/?id=24864&edit=1
#24864 [Opn]: Kludge Resolution
ID: 24864 User updated by: tom at minnesota dot com -Summary: Warning: Unexpected character in input Reported By: tom at minnesota dot com Status: Open Bug Type: CGI related Operating System: NetBSD/Alpha (64bit) - 1.6 -PHP Version: 4CVS-2003-07-30 (stable) +PHP Version: 4.3.2 New Comment: If I change the php cgi file: cat /usr/local/libexec/cgi-bin/php --- #!/bin/sh export SCRIPT_FILENAME=$PATH_TRANSLATED /usr/local_install/php-4-200307300130-cgi/bin/php --- Then now it displays the phpinfo page properly. Some notes I found relating to this problem in previous PHP versions: --- It appears that when Apache executes the RedHat php cgi it passes SCRIPT_FILENAME as /var/www/cgi-bin/php and PATH_TRANSLATED is the name of the php script /var/www/maplab/htdocs/index.phtml. The php cgi on the other hand does not execute against PATH_TRANSLTED it executes against SCRIPT_FILENAME. The result is if you use the RedHat Apache/Php-CGI in the default configuration, every time the Php CGI executes, it uses itself (a binary file) as the input file to translate. And then it spews garbage because it is trying to parse a binary file. --- Previous Comments: [2003-07-30 01:21:48] tom at minnesota dot com I should also note that accessing the phpinfo.phtml page via shell and php (cgi) directly works fine. It shows that error when accessing the script with php cgi through Apache. [2003-07-30 01:18:14] tom at minnesota dot com Description: When accessing a simple page with via the browser and php (cgi): I get: --- Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Warning: Unexpected character in input: ' in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 Parse error: parse error in /usr/local_install/php-4-200307300130-cgi/bin/php on line 4819 --- Works fine with apache module and older 4.3.1 cgi. Reproduce code: --- Expected result: Show the phpinfo page. -- Edit this bug report at http://bugs.php.net/?id=24864&edit=1
#27802 [Bgs]: FastCGI PHP_FCGI_CHILDREN default unstable and undocumented.
ID: 27802 User updated by: tom at hur dot st Reported By: tom at hur dot st Status: Bogus Bug Type: CGI related Operating System: FreeBSD 4.9-STABLE PHP Version: 4.3.5 New Comment: The original behavior of not behaving as documented and crashing after a fixed number of requests was correct? Silly me, sorry about wasting your time. Previous Comments: [2004-07-05 13:54:26] [EMAIL PROTECTED] Not a code bug. The previous behaviour was correct. Unfortunately, the bogus code change has made it into PHP 4.3.7. Newer releases will revert to the proper behaviour. [2004-03-31 11:52:20] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. [2004-03-31 09:01:51] tom at hur dot st Description: If you don't set the env variable PHP_FCGI_CHILDREN, PHP doesn't default to 8 as README.FastCGI suggests; it doesn't bother spawning extra processes at all (default is 0). After PHP_FCGI_MAX_REQUESTS, PHP segfaults. No apparant useful information from core or ktrace, other than seeing that it's not forking and falling over after exactly PHP_FCGI_MAX_REQUESTS; the fix looks fairly easy, though.. except maybe at children = 0 :) -- Edit this bug report at http://bugs.php.net/?id=27802&edit=1
#29548 [NEW]: Apache2/PHP Module crashes
From: tom at ideaweb dot de Operating system: Debian Testing PHP version: 4.3.8 PHP Bug Type: *XML functions Bug description: Apache2/PHP Module crashes Description: hi, i have a small content management system, which transforms xml documents to evaluated php templates. with huge data the apache2.0.50 crashes with the following message in the error log: httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:15:58 2004] [notice] child pid 20982 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:16:08 2004] [notice] child pid 21091 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:23:50 2004] [notice] child pid 21440 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:50:11 2004] [notice] child pid 28053 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:52:20 2004] [notice] child pid 28197 exit signal Aborted (6) if i change some content in cdata notes, the transformation over sabltron xsl works in some cases again. with small documents no problem. Reproduce code: --- sorry its to complex to post this in 20 line. if you have questions contact me. Expected result: no crashes at any kind programming failures... Actual result: -- root:/etc/firewall# /www/apache/current/bin/httpd -X Aborted the apache webserver quits only with "Aborted",the the same error message in the error log and without a core file. ??? -- Edit bug report at http://bugs.php.net/?id=29548&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29548&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29548&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29548&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29548&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29548&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29548&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29548&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29548&r=support Expected behavior: http://bugs.php.net/fix.php?id=29548&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29548&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29548&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29548&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29548&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29548&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29548&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29548&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29548&r=float
#27908 [Com]: xml default_handlers not being called
ID: 27908
Comment by: tom at ideaweb dot de
Reported By: ahundiak at ingr dot com
Status: Verified
Bug Type: XML related
Operating System: Linux
PHP Version: 5CVS-2004-04-08
New Comment:
i have the same problem too. in version 4 there are no
problems, but in php5 this is broken. the bug is not
fixed till 5.0.0. i think it is a very import "core"
function to get "old" applications of version 4
running!!
Previous Comments:
[2004-04-07 12:34:00] ahundiak at ingr dot com
Description:
As the test case shows, it does not appear that the default handler is
being called under PHP5RC1. The other handlers seem to work but the
default handler is required to get the document type line. PHP4.3.5
works. Using libxml2 2.6.5.
Reproduce code:
---
function x_default_handler($xp,$data)
{
echo "x_default_handler $data\n";
}
$xp = xml_parser_create();
xml_set_default_handler($xp,'x_default_handler');
xml_parse($xp,'',TRUE);
xml_parser_free($xp);
echo "Parse Test " . PHP_VERSION . " Done\n";
Expected result:
x_default_handler
x_default_handler
Parse Test 5.0.0RC1 Done
Actual result:
--
Parse Test 5.0.0RC1
--
Edit this bug report at http://bugs.php.net/?id=27908&edit=1
#29563 [NEW]: locking problem
From: tom at bitworks dot de Operating system: Debian Linux Woody & Apache/1.3. PHP version: 4.3.8 PHP Bug Type: Filesystem function related Bug description: locking problem Description: There seam to be several logical implementation faults, concerning flock() and dio_open() 1.) Opening a file by the first process with $fh = dio_open($dateiname,O_RDWR + O_NONBLOCK ,0 ); does not trigger a failure opening the file twice by an other process with the same method You always get the ressource handle 2.) Opening the file twice, after having opened with upper method, by the flock(..., LOCK_NB) function, causes a waiststate for the flock() process. That problem should be solved. Remark: Mandatory locking on LINUX only works, if You mount the volume with option "mand" (-o mand) (missing Information in documentation) Programs like vi nevertheless are able to override the "mandatory locking" with the "x!" command. (only checked for a LINUX Debian Woody system) Expected result: Triggering a failure (return false) Actual result: -- Waiting for locking -- Edit bug report at http://bugs.php.net/?id=29563&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29563&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29563&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29563&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29563&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29563&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29563&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29563&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29563&r=support Expected behavior: http://bugs.php.net/fix.php?id=29563&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29563&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29563&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29563&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29563&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29563&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29563&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29563&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29563&r=float
[PHP-BUG] Req #61182 [NEW]: Assume Opening PHP Tag
From: Operating system: PHP version: 5.4.0RC8 Package: *Configuration Issues Bug Type: Feature/Change Request Bug description:Assume Opening PHP Tag Description: PHP is probably the only language I know which requires an opening tag (i.e . In the early days, when web pages were mostly static, and PHP was used to add dynamic elements, it made sense to require an opening tag to drop-into PHP execution. These days however, the opposite is more often the case. You normally have a complete PHP web application, into which HTML and other static text is inject, rather than injecting dynamic elements into static web pages. What I'd like to see is a new directive added to php.ini. Call it what you want, e.g. assume_open_tag or omit_open_tag. This would require a few changes in coding practice. For example, if omit_open_tag is On, then the behaviour of the include() and require() constructs will change. They too will assume the files being required contain PHP from line 1. Programmer will not longer be able to use include() and require() to load file contents, instead the programmer would have to use file_get_contents or some other alternative, though this would arguably a good thing, as using require() and include() to load and output non-php could be vulnerability, hence it's already bad practice to use include/require() to load non-PHP files. I think this change would be consistant with some of the changes made in 5.4 which demonstrates PHP embracing modern programming idioms from other languages. Ideally, I'd like this to become the default behaviour of PHP, though obviously for at least the first major release, it would of course be defaulted to Off. Thoughts? -- Edit bug report at https://bugs.php.net/bug.php?id=61182&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61182&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61182&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61182&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61182&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61182&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61182&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61182&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61182&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61182&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61182&r=support Expected behavior: https://bugs.php.net/fix.php?id=61182&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61182&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61182&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61182&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61182&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61182&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61182&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61182&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61182&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61182&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61182&r=mysqlcfg
Req #61182 [Opn]: Assume Opening PHP Tag
Edit report at https://bugs.php.net/bug.php?id=61182&edit=1 ID: 61182 User updated by: tom at tomwardrop dot com Reported by: tom at tomwardrop dot com Summary:Assume Opening PHP Tag Status: Open Type: Feature/Change Request Package:*Configuration Issues PHP Version:5.4.0RC8 Block user comment: N Private report: N New Comment: Are there not other directives that can break a lot of code? Remember, this would default to off. I don't see why as a server owner, I should have this option made unavailable purely because it can break other code. If you wanted to write code that worked regardless of this setting, you could do something like: Of course, for that to work then implicit_open_tag is On, the parser would have to ignore the "". This would be shorthand for opening and closing a php tag, and should be placed at the top of any template file that has the requirement to work regardless of whether the opening tag is optional. I hope this idea isn't dismissed on the grounds that it's difficult to implement, because I think it's workable. Having optional opening tags would no doubt be a step in the right direction for PHP, and I'm sure that if you didn't have backwards compatible to be concerned about, you'd probably make opening tags implicit with no option to make it otherwise. As I said earlier, the decision to make the opening tag explicit was desirable at the time PHP was conceived, but I believe it's one of those legacy decisions that needs to be re- evaluated. Previous Comments: [2012-02-25 08:50:31] ras...@php.net So this would basically be a "break all existing code" .ini switch? I don't think that is a good idea. -------- [2012-02-25 08:37:03] tom at tomwardrop dot com Description: PHP is probably the only language I know which requires an opening tag (i.e . In the early days, when web pages were mostly static, and PHP was used to add dynamic elements, it made sense to require an opening tag to drop-into PHP execution. These days however, the opposite is more often the case. You normally have a complete PHP web application, into which HTML and other static text is inject, rather than injecting dynamic elements into static web pages. What I'd like to see is a new directive added to php.ini. Call it what you want, e.g. assume_open_tag or omit_open_tag. This would require a few changes in coding practice. For example, if omit_open_tag is On, then the behaviour of the include() and require() constructs will change. They too will assume the files being required contain PHP from line 1. Programmer will not longer be able to use include() and require() to load file contents, instead the programmer would have to use file_get_contents or some other alternative, though this would arguably a good thing, as using require() and include() to load and output non-php could be vulnerability, hence it's already bad practice to use include/require() to load non-PHP files. I think this change would be consistant with some of the changes made in 5.4 which demonstrates PHP embracing modern programming idioms from other languages. Ideally, I'd like this to become the default behaviour of PHP, though obviously for at least the first major release, it would of course be defaulted to Off. Thoughts? -- Edit this bug report at https://bugs.php.net/bug.php?id=61182&edit=1
Req #61182 [Opn]: Assume Opening PHP Tag
Edit report at https://bugs.php.net/bug.php?id=61182&edit=1
ID: 61182
User updated by: tom at tomwardrop dot com
Reported by: tom at tomwardrop dot com
Summary:Assume Opening PHP Tag
Status: Open
Type: Feature/Change Request
Package:*Configuration Issues
PHP Version:5.4.0RC8
Block user comment: N
Private report: N
New Comment:
It's not just about the extra characters, but like the end ?> tag (which
thankfully is optional), any white-space or otherwise non-printable characters
before the opening tag can cause "headers sent" issues. You could solve that
problem by implementing the ignore white-space rule I've already mentioned,
where any white-space before the opening tag is ignored.
The more I think about this and talk to the others, the more it becomes
apparent
that what I'm actually asking for, is a distinction to made between PHP
templates, and PHP scripts/applications. If PHP were to define these two
distinct concepts, then you could do more than just make the opening tag
optional. For example, you could have a template() or render() method to act as
an include() for php templates. Unlike include() however, this render() method
would return the output of the file, instead of sending it straight to the
browser. This would negate the need to capture template output using the output
buffer functions (something that I believe most frameworks end up using).
Making such a distinction would also allow web servers like Apache to treat PHP
files differently. You may create a rule in Apache to render all .phpt files as
PHP templates, rendering everything else as PHP script or application files. We
may then see mod_php implement an application mode, where one can define a
single-point of entry into their application. This could have flow-on
performance benefits, where mod_php could cache the parsed PHP, then either
fork
it on each request, or instantiate a new application class. Such a feature
would
mean frameworks wouldn't have to stuff around with .htaccess files, and would
mean that programmers don't need to add the following to the top of all their
files: if (defined('SOME_CONSTANT')) exit;
While there's momentum among the PHP developers to move forward with
modernising
the language, I think now would be a good idea to consider some of these more
fundamental changes. PHP's built-in template engine, ease of deployment, and
it's dynamic, traditional OO constructs would still remain PHP's strengths.
With all this said, I'd be happy to save such changes to a major release
intended to break legacy code, like PHP 6. I'd like to keep in mind too that
code portability isn't relevant to most people who don't intend to release
their
code as open source. Typically, those people using PHP in a business context
have control of their server. It's only shared hosting environments where
portability becomes a potential issue. All I'm saying is don't rule out ideas
based on the lowest common denominator.
Previous Comments:
[2012-02-25 14:12:03] phpmpan at mpan dot pl
After a bit of thinking I came to a conclusion that PHARs can, in theory, have
such thing implemented. Some metadata may be included in PHAR to tell PHP that
every source file in the archive assumes "" tag. Thought it's used to *enable*
`assume_open_tag`. But, if you want to use it to disable the feature, it's even
worse. This breaks lots of existing code. Mixing PHP with HTML is an example of
bad design, but there are lots of such things and PHP devs can't just say "from
today your code is not working, because we have decided to break it". Adding
some magical sequence of characters at the begining is not a solution for this
problem. Do you imagine administrators going through all of the files on their
servers and adding "" to fix the broken code? Even harder to imagine in
case of obfuscated or PHARed code.
I believe there is enough problems with server incompatibilities already. No
need to make next one. I would be much more happy to see UTF-8 to be a standard
feature on every host. A requirement to write "" at the
begining of the file to not write "" thing is optional. The problem is that virtually any
code has to use it to be portable. This means it's not really optional.
[2012-02-25 09:24:21] tom at tomwardrop dot com
Are there not other directives that can break a lot of code? Remember, this
would default to off. I don't see why as a server owner, I should have this
option made unavailable purely because it can break other code. If you wanted
to
write code that worked rega
Req #61182 [Opn]: Assume Opening PHP Tag
Edit report at https://bugs.php.net/bug.php?id=61182&edit=1
ID: 61182
User updated by: tom at tomwardrop dot com
Reported by: tom at tomwardrop dot com
Summary:Assume Opening PHP Tag
Status: Open
Type: Feature/Change Request
Package:*Configuration Issues
PHP Version:5.4.0RC8
Block user comment: N
Private report: N
New Comment:
I do agree with you, hence my last comment. Adding optional open tags alone
would be more hassle than it's worth, you're right. However, if PHP was to
provide more than just optional open tags, like some of the application-
orientated features I've mentioned, then the hassle would probably be worth it.
Of course, this goes beyond the scope of this feature request, but it would
make
for an interesting discussion none-the-less. PHP is overdue to receive some
kind
of application persistance so code isn't re-parsed and re-initialized after
every request.
I'm happy for this ticket to be closed, though I would love to see more thought
put into evolving PHP beyond its current template-orientated form, which lately
seems to work against developers more than it helps them.
Previous Comments:
[2012-02-26 01:47:05] phpmpan at mpan dot pl
Note: I'm NOT against the idea itself. I'm just thinking that in the current
form it can do more harm than good.
What you're asking for is redefining the whole PHP world. Let's imagine that
PHP6 includes your idea and it's *not* optional. What happens?
1. Many of PHP books become obsolete
We all know mixing code and output is bad, but the books
take this approach because it's simpler. It allows authors
to show the basic ideas of PHP without requiring the reader
to download/install third party template engine.
But if .php files are no longer templates, books need
to be rewritten. Lots of money for authors, but I think
it's not dev's goal.
2. Lots of currently used code becomes obsolete
If one needs to write code for a server that has
this feature enabled, any template-like code should
be avoided. This means we can use only "safe" libraries.
Which are "safe"? Only those for which the author states
they're compatible with `assume_open_tags`.
In other words: less code for us to use. Many things needs
to be rewritten. This is bad.
3. Admins will simply refuse to enable the feature
I love the idea of removing magic_quotes. At the same time
I believe many admins will hesitate to upgrade to PHP6,
because they have irrational belief that the magic_quotes
feature was protecting them.
Now imagine what will they do with `assume_open_tags`.
Will they enable it? Will they risk breaking already
deployed applications? I don't think so. If they're afraid
to leave their servers without magic_quote "protection",
they'll be even more scared of the fact that they can beak
something seriously by enabling `assume_open_tags`.
Setting `assume_open_tags` on per-directory basis (for example
with .htaccess in Apache) doesn't solve the problem, because
PHP libraries may be shared between multiple applications.
I believe that books should be rewritten, real template engines should be used,
we should update our code et cetera. But real life is real life. Encountering
pieces of software that were not upgraded for 20-30 years is not an uncommon
thing ("20-30yrs" does not apply to PHP, but I know apps that were not updated
since PHP4). `magic_quotes` are deprecated for years and many people seen
they're bad even earlier. There was enough time to update applications that
depends on them. And even if some code is not fixed, removing magic_quotes
doesn't make it stop working. The case of `assume_open_tags` is different. If
it's optional, it needs to become a standard to be accepted. And this should be
done quickly. I can't imagine building separate versions of libraries for
server with this feature enabled and without it. Authors will simply keep using
versions with " tag (which
thankfully is optional), any white-space or otherwise non-printable characters
before the opening tag can cause "headers sent" issues. You could solve that
problem by implementing the ignore white-space rule I've already mentioned,
where any white-space before the opening tag is ignored.
The more I think about this and talk to the others, the more it becomes
apparent
that what I'm actually asking for, is a distinction to made between PHP
templates, and PHP scripts/applications. If PHP were to define these two
distinct concepts, then you could do more than just make the opening tag
optional. For example, you could have a template() or render() method to act
Req #52504 [Com]: Support relative namespaces
Edit report at https://bugs.php.net/bug.php?id=52504&edit=1
ID: 52504
Comment by: tom at tomwardrop dot com
Reported by:robert dot de dot wilde at online dot nl
Summary:Support relative namespaces
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
I was just about to post the exact same feature suggestion. I'm using PHP 5.4
RC8
after 2 years of programming Ruby (I have a project that better lends itself to
PHP template-orientated nature), and this was one of the first things I tried
to
do, reference a resource one level up in the namespace hierarchy. Luckily, my
namespace isn't too deep, but I can imagine some of the larger frameworks which
have 3-6+ level deep namespaces could really benefit from this.
I'm surprised none of the dev's have commented on this.
Previous Comments:
[2010-08-18 15:44:12] robert dot de dot wilde at online dot nl
Any developer can have a look?
[2010-07-31 10:54:14] giorgio dot liscio at email dot it
very nice, i really like it
it would be nice too having * on import
works only if __autoload or spl_autoload_register is used, otherwise triggers
an error
use MyNS\Test\*; // imports all classes in the "Test" namespace
use MyNS\Test\**; // imports all the namespace hierarchy (including
subpackages) from namespace Test
__autoload($className, $importAll = FALSE, $importDeep = FALSE)
{
// handle * as a full dir import
// ** imports subdirs too
}
in my framework i need to put
use \FW\String;
use \FW\Int;
use \FW\Float;
use \FW\Vector;
use \FW\Dictionary;
use \FW\Types;
etc in every file...
[2010-07-31 09:58:03] robert dot de dot wilde at online dot nl
Description:
It would be nice to have relative namespace support to keep code clean and
flexible.
When inside of a namespace, it would be nice to have some directory-path-like
option like '..'.
Test script:
---
namespace MyNs\Some\Path\Going\A\Long\Way
{
class GoClass extends ..\..\Short\Way\GoClass // <<
{}
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=52504&edit=1
Req #13756 [Com]: exponential ** operator
Edit report at https://bugs.php.net/bug.php?id=13756&edit=1 ID: 13756 Comment by: tom at r dot je Reported by:san...@php.net Summary:exponential ** operator Status: Closed Type: Feature/Change Request Package:Feature/Change Request Operating System: n/a PHP Version:4.0.6 Block user comment: N Private report: N New Comment: Indeed! Seems very despotic just to say "No. Deal with it" with no further discussion or explanation why. Previous Comments: [2012-07-08 23:31:23] hello at wesalvaro dot com le why not? [2002-04-27 16:17:03] j...@php.net not going to happen. just suck it up and use pow(). [2001-10-19 18:51:47] jer...@php.net I proposed that earlier (along with ^^) [ZendEnginge ML, june 27th & july 3rd]. Anyway, I think it should be added, there is simply no power operator now, and pow() is both a bit bugly and overloaded (both ^^ and ** at the same time). [2001-10-19 11:24:28] hholz...@php.net ** is Pascal, not C [2001-10-19 10:36:03] san...@php.net It would be nice to have an exponential operator. ** would be a logical choice, just like in C. Example: echo 2**3; // prints 8 I know we have pow(), but an operator for this would be nice... -- Edit this bug report at https://bugs.php.net/bug.php?id=13756&edit=1
Req #29812 [Com]: rename() don't overwrite existing files at windows (as at linux)
Edit report at https://bugs.php.net/bug.php?id=29812&edit=1 ID: 29812 Comment by: tom at r dot je Reported by:melker at kuh dot at Summary:rename() don't overwrite existing files at windows (as at linux) Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: winxp PHP Version:4.3.8 Block user comment: N Private report: N New Comment: This isn't restricted to Windows XP but also affects other versions. I've tested Windows Vista and Windows Server 2008, both have this same problem. Previous Comments: [2004-08-24 12:36:20] melker at kuh dot at Description: Hi, rename ( 'file1', 'file2' ); behaviour at linux: If there is a 'file2', the file2 will be overwritten by file1. at windows xp: If there is a 'file2', a warning is given and the file2 isn't overwritten with file1. Reproduce code: --- rename ( 'file1', 'file2' ); Expected result: I would expect, that rename() works with the same behaviour at all operating systems. So, please overwrite existing files or give a warning at all os. Actual result: -- rename() at linux, existing files will be overwritten, at winxp, the rename-process fails, a php-warning is given. -- Edit this bug report at https://bugs.php.net/bug.php?id=29812&edit=1
Bug #55182 [Com]: finfo_file() doesn't detect right mime-type
Edit report at https://bugs.php.net/bug.php?id=55182&edit=1 ID: 55182 Comment by: tom at tombartling dot com Reported by:dominique at ramaekers-stassart dot be Summary:finfo_file() doesn't detect right mime-type Status: Open Type: Bug Package:Unknown/Other Function Operating System: Ubuntu 10.04 PHP Version:5.3SVN-2011-07-11 (SVN) Block user comment: N Private report: N New Comment: This also fails to detect the correct mime-type for PHP files. If the file starts with ... and the PHP code is anywhere else in the file, it returns text/html as the mime-type. It fails to detect a CSV file correctly. This is a problem for the CodeIgniter framework, since it's file upload class uses this function. I'm on Red Hat Enterprise Linux Server release 5.8 (Tikanga). Previous Comments: [2011-07-11 16:33:30] dominique at ramaekers-stassart dot be Description: The finfo_file command detects openxml documents (xlsb, xlsx,...) as application/zip files. Can this be fixed? There are a lot of people who have to hack the mediawiki code to allow these files for upload. With these hacks they lose a part of there security: the checking of the finfo_file-mime-type against the file extension itself... Test script: --- php > $finfo = finfo_open(FILEINFO_MIME_TYPE); php > echo finfo_file($finfo, '/mnt/Transfert/test.xlsb'); application/zip -- Edit this bug report at https://bugs.php.net/bug.php?id=55182&edit=1
#48155 [NEW]: imagettftext and imagefttext do not accurately position text horizontally
From: tom at streamsense dot net Operating system: Windows Server 2008 PHP version: 5.2.9 PHP Bug Type: GD related Bug description: imagettftext and imagefttext do not accurately position text horizontally Description: Whilst PHP can very accurately get the bounding box of TTF text, when drawing it does not position the text accurately on the X axis. The error margin varies depending on the glyphs being drawn. System Windows NT S15289149 6.0 build 6001 (Windows Server 2008) PHP Version 5.2.9-2 Build Date Apr 9 2009 08:22:37 GD Version bundled (2.0.34 compatible) FreeType Version2.1.9 Reproduce code: --- http://www.pastebin.ca/1413488 Expected result: All text should be contained within the red bounding box. Actual result: -- http://bayimg.com/image/dapmiaabh.jpg Text is not contained with the indicated red bounding boxes. -- Edit bug report at http://bugs.php.net/?id=48155&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48155&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48155&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48155&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48155&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48155&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48155&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48155&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48155&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48155&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48155&r=support Expected behavior: http://bugs.php.net/fix.php?id=48155&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48155&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48155&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48155&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48155&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48155&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48155&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48155&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48155&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48155&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48155&r=mysqlcfg
#48155 [Fbk->Opn]: imagettftext and imagefttext do not accurately position text horizontally
ID: 48155 User updated by: tom at streamsense dot net Reported By: tom at streamsense dot net -Status: Feedback +Status: Open Bug Type: GD related Operating System: Windows Server 2008 -PHP Version: 5.2.9 +PHP Version: 5.3.0RC2-dev New Comment: Confirmed reproducable on PHP Version 5.3.0RC2-dev GD Version bundled (2.0.34 compatible) FreeType Version2.3.9 Previous Comments: [2009-05-05 19:28:10] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-05 18:22:49] tom at streamsense dot net Description: Whilst PHP can very accurately get the bounding box of TTF text, when drawing it does not position the text accurately on the X axis. The error margin varies depending on the glyphs being drawn. System Windows NT S15289149 6.0 build 6001 (Windows Server 2008) PHP Version 5.2.9-2 Build Date Apr 9 2009 08:22:37 GD Version bundled (2.0.34 compatible) FreeType Version2.1.9 Reproduce code: --- http://www.pastebin.ca/1413488 Expected result: All text should be contained within the red bounding box. Actual result: -- http://bayimg.com/image/dapmiaabh.jpg Text is not contained with the indicated red bounding boxes. -- Edit this bug report at http://bugs.php.net/?id=48155&edit=1
#48155 [Fbk->Opn]: imagettftext and imagefttext do not accurately position text horizontally
ID: 48155 User updated by: tom at streamsense dot net Reported By: tom at streamsense dot net -Status: Feedback +Status: Open Bug Type: GD related Operating System: Windows Server 2008 PHP Version: 5.3.0RC2-dev New Comment: The font is arial black, included with any windows install, but this is totally reproducable with any font (or at least all i've tried). I've tried tahoma, arial, arial black, times new roman. Previous Comments: [2009-05-05 19:39:03] paj...@php.net Please post a link to the font you use. [2009-05-05 19:36:15] tom at streamsense dot net Confirmed reproducable on PHP Version 5.3.0RC2-dev GD Version bundled (2.0.34 compatible) FreeType Version2.3.9 [2009-05-05 19:28:10] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-05 18:22:49] tom at streamsense dot net Description: Whilst PHP can very accurately get the bounding box of TTF text, when drawing it does not position the text accurately on the X axis. The error margin varies depending on the glyphs being drawn. System Windows NT S15289149 6.0 build 6001 (Windows Server 2008) PHP Version 5.2.9-2 Build Date Apr 9 2009 08:22:37 GD Version bundled (2.0.34 compatible) FreeType Version2.1.9 Reproduce code: --- http://www.pastebin.ca/1413488 Expected result: All text should be contained within the red bounding box. Actual result: -- http://bayimg.com/image/dapmiaabh.jpg Text is not contained with the indicated red bounding boxes. -- Edit this bug report at http://bugs.php.net/?id=48155&edit=1
#48334 [NEW]: DateTime2 sometimes allows construct with an invalid string
From: tom at ix dot tc
Operating system: Windows Vista
PHP version: 5.2.9
PHP Bug Type: Date/time related
Bug description: DateTime2 sometimes allows construct with an invalid string
Description:
I was initialising DateTime objects to test validity of date strings when
I came across an odd bug. The string "East Anglia" gets parsed the same way
as some time today.
Strangely, strtotime does not parse the string.
Reproduce code:
---
$date = new DateTime('A');
echo $date->format('U');
will correctly throw an exception: Fatal error: Uncaught exception
'Exception' with message 'DateTime::__construct() [datetime.--construct]: Failed to parse time
string (AAA) at position 0 (A):
$date = new DateTime('East Anglia');
echo $date->format('U');
Gets parsed as if it were now + 7 hours.
Expected result:
An exception: Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct() [datetime.--construct]: Failed to parse time
string (AAA) at position 0 (A):
Actual result:
--
Gets parsed as a time string.
--
Edit bug report at http://bugs.php.net/?id=48334&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48334&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48334&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48334&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48334&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48334&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48334&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48334&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48334&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48334&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48334&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48334&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48334&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48334&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48334&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48334&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48334&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48334&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48334&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48334&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48334&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48334&r=mysqlcfg
#48744 [NEW]: Segmentation fault with open_basedir enabled
From: tom at ideaweb dot de
Operating system: Linux Debian Etch
PHP version: 5.3.0
PHP Bug Type: Safe Mode/open_basedir
Bug description: Segmentation fault with open_basedir enabled
Description:
Segmentation fault if the following line is enabled in apache.conf:
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql
Maybe i made something wrong or its not a bug in php, because i not
really understand the debug output, but i hope it helps =)
(gdb) run -X
Starting program: /www/apache/2.2.11/bin/httpd -X
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1212832064 (LWP 4837)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212832064 (LWP 4837)]
0xb757a7b7 in OnUpdateBaseDir (entry=0x824fba0,
new_value=0x83b6398
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7b593a0,
mh_arg3=0x0, stage=4) at /www/src/php-5.3.0/main/fopen_wrappers.c:103
103 if (!*p || !**p) {
(gdb) bt
#0 0xb757a7b7 in OnUpdateBaseDir (entry=0x824fba0,
new_value=0x83b6398
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7b593a0,
mh_arg3=0x0, stage=4) at /www/src/php-5.3.0/main/fopen_wrappers.c:103
#1 0xb75f6d09 in zend_alter_ini_entry_ex (name=0x819a670
"open_basedir", name_length=13,
new_value=0x8228770
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4, force_change=0) at
/www/src/php-5.3.0/Zend/zend_ini.c:285
#2 0xb75f6b0f in zend_alter_ini_entry (name=0x819a670 "open_basedir",
name_length=13,
new_value=0x8228770
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4) at /www/src/php-
5.3.0/Zend/zend_ini.c:243
#3 0xb76a86b6 in apply_config (dummy=0x8228df8) at /www/src/php-
5.3.0/sapi/apache2handler/apache_config.c:197
#4 0xb76a7a73 in php_handler (r=0x837fe30) at /www/src/php-
5.3.0/sapi/apache2handler/sapi_apache2.c:547
#5 0x0807dad7 in ap_run_handler (r=0x837fe30) at config.c:157
#6 0x08080bc7 in ap_invoke_handler (r=0x837fe30) at config.c:372
#7 0x080c8658 in ap_process_request (r=0x837fe30) at
http_request.c:282
#8 0x080c581e in ap_process_http_connection (c=0x836fd40) at
http_core.c:190
#9 0x08084a87 in ap_run_process_connection (c=0x836fd40) at
connection.c:43
#10 0x080f846d in child_main (child_num_arg=) at
prefork.c:650
#11 0x080f86a5 in make_child (s=0x813d648, slot=0) at prefork.c:690
#12 0x080f944c in ap_mpm_run (_pconf=0x81380a8, plog=0x8188328,
s=0x813d648) at prefork.c:966
#13 0x0806b44f in main (argc=135487648, argv=0x836db60) at main.c:740
--
Edit bug report at http://bugs.php.net/?id=48744&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48744&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48744&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48744&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48744&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48744&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48744&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48744&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48744&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48744&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48744&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48744&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48744&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48744&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48744&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48744&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48744&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48744&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48744&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48744&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48744&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48744&r=mysqlcfg
#48744 [Fbk->Opn]: Segmentation fault with open_basedir enabled
ID: 48744
User updated by: tom at ideaweb dot de
Reported By: tom at ideaweb dot de
-Status: Feedback
+Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
New Comment:
Its really strange, because i have several php53 installations without
any trouble with the same configuration, but only on one dev server it
crashes. if you cannot reproduce, its not a big deal that you can get
access to our dev server, there are not secrets and no data...
ServerAdmin webmas...@ecolint.ch
ServerName ecodev.ecolint.ch
ServerAlias ecm.ideaweb.de
ServerAlias 217.169.129.40
#ErrorDocument 404 /
DocumentRoot /var/www/ecolint.ch/dev/ecolint/trunk/admin
CustomLog /var/www/ecolint.ch/logs/access_log combined
ErrorLog /var/www/ecolint.ch/logs/error_log
Options -MultiViews -Indexes -Includes +FollowSymlinks
AllowOverride All
Order allow,deny
Allow from all
Alias /mysql/ /var/www/ecolint.ch/mysql/
Options -MultiViews -Indexes -Includes -FollowSymlinks
AllowOverride All
Order allow,deny
Allow from all
php_admin_flag register_globals off
php_admin_flag magic_quotes_gpc off
php_admin_flag magic_quotes_runtime off
php_admin_value default_charset utf-8
php_admin_value session.save_path /www/htdocs/ecolint.ch/tmp/
php_admin_value upload_tmp_dir /www/htdocs/ecolint.ch/tmp/
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
Previous Comments:
[2009-07-01 05:56:00] ras...@php.net
I can't reproduce this. Where in your apache.conf do you have that
line? As in which config blocks is it inside?
[2009-06-30 16:40:31] tom at ideaweb dot de
Description:
Segmentation fault if the following line is enabled in apache.conf:
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql
Maybe i made something wrong or its not a bug in php, because i not
really understand the debug output, but i hope it helps =)
(gdb) run -X
Starting program: /www/apache/2.2.11/bin/httpd -X
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1212832064 (LWP 4837)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212832064 (LWP 4837)]
0xb757a7b7 in OnUpdateBaseDir (entry=0x824fba0,
new_value=0x83b6398
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7b593a0,
mh_arg3=0x0, stage=4) at /www/src/php-5.3.0/main/fopen_wrappers.c:103
103 if (!*p || !**p) {
(gdb) bt
#0 0xb757a7b7 in OnUpdateBaseDir (entry=0x824fba0,
new_value=0x83b6398
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7b593a0,
mh_arg3=0x0, stage=4) at /www/src/php-5.3.0/main/fopen_wrappers.c:103
#1 0xb75f6d09 in zend_alter_ini_entry_ex (name=0x819a670
"open_basedir", name_length=13,
new_value=0x8228770
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4, force_change=0) at
/www/src/php-5.3.0/Zend/zend_ini.c:285
#2 0xb75f6b0f in zend_alter_ini_entry (name=0x819a670 "open_basedir",
name_length=13,
new_value=0x8228770
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4) at /www/src/php-
5.3.0/Zend/zend_ini.c:243
#3 0xb76a86b6 in apply_config (dummy=0x8228df8) at /www/src/php-
5.3.0/sapi/apache2handler/apache_config.c:197
#4 0xb76a7a73 in php_handler (r=0x837fe30) at /www/src/php-
5.3.0/sapi/apache2handler/sapi_apache2.c:547
#5 0x0807dad7 in ap_run_handler (r=0x837fe30) at config.c:157
#6 0x08080bc7 in ap_invoke_handler (r=0x837fe30) at config.c:372
#7 0x080c8658 in ap_process_request (r=0x837fe30) at
http_request.c:282
#8 0x080c581e in ap_process_http_connection (c=0x836fd40) at
http_core.c:190
#9 0x08084a87 in ap_run_process_connection (c=0x836fd40) at
connection.c:43
#10 0x080f846d in child_main (child_num_arg=) at
prefork.c:650
#11 0x080f86a5 in make_child (s=0x813d648, slot=0) at prefork.c:690
#12 0x080f944c in ap_mpm_run (_pconf=0x81380a8, plog=0x8188328,
s=0x813d648) at prefork.c:966
#13 0x0806b44f in main (argc=135487648, argv=0x836db60) at main.c:740
---
#48744 [Opn]: Segmentation fault with open_basedir enabled
ID: 48744
User updated by: tom at ideaweb dot de
Reported By: tom at ideaweb dot de
Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
New Comment:
Thread Safety is disabled (shown in phpinfo()), but i did never
enabled it on our servers, and we have lot... and i'm using apache2-
mpm-prefork... these default configurations ran never in trouble for
me, on high traffic sites too, but in this case it crashes on each
request. =(
./configure \
"--enable-so" \
"--enable-cgi" \
"--enable-info" \
"--enable-rewrite" \
"--enable-usertrack" \
"--enable-deflate" \
"--enable-dav" \
"--enable-unique-id" \
"--enable-dav-fs" \
"--enable-dav-lock" \
"--enable-mime-magic" \
"--enable-proxy" \
"--enable-ssl" \
"--with-ssl=/usr" \
"--prefix=/www/apache/2.2.11"
[...]
checking which MPM to use... prefork
[...]
./configure \
--prefix=/www/prog/php/5.3.0 \
--with-apxs2=/www/apache/2.2.11/bin/apxs \
--with-config-file-path=/www/etc \
--with-iconv=/usr/local \
--with-iconv-dir=/usr/local \
--with-mysqli=/www/prog/mysql/current/bin/mysql_config \
--with-mysql-sock=/www/share/mysql/current/mysqld.sock \
--with-pdo-mysql=/www/prog/mysql/current/ \
--with-mysql=/www/prog/mysql/current/ \
--enable-safe-mode=no \
--enable-discard \
--enable-magic-quotes \
--enable-track-vars \
--with-zlib \
--with-zlib-dir=/usr \
--enable-trans-sid \
--with-openssl=/usr \
--enable-wddx \
--enable-bcmath \
--enable-shmop \
--enable-mhash \
--enable-ftp \
--enable-calendar \
--with-gd \
--with-freetype \
--with-freetype-dir=/usr \
--with-jpeg \
--with-jpeg-dir=/usr \
--enable-exif \
--with-png \
--with-png-dir=/usr \
--enable-mbstring \
--enable-sockets \
--with-mhash=/usr \
--with-ldap=/usr \
--with-kerberos=/usr \
--with-libxml-dir=/usr \
--with-gettext \
--with-xsl=/usr \
--enable-soap \
--with-mcrypt \
--enable-debug
Previous Comments:
[2009-07-01 17:59:47] sjoerd-php at linuxonly dot nl
Are you perhaps running a multithreaded Apache server with a
non-thread-safe PHP module?
Check "Thread Safety" in phpinfo() and whether you have
apache2-mpm-worker or apache2-mpm-prefork.
[2009-07-01 07:33:34] tom at ideaweb dot de
Its really strange, because i have several php53 installations without
any trouble with the same configuration, but only on one dev server it
crashes. if you cannot reproduce, its not a big deal that you can get
access to our dev server, there are not secrets and no data...
ServerAdmin webmas...@ecolint.ch
ServerName ecodev.ecolint.ch
ServerAlias ecm.ideaweb.de
ServerAlias 217.169.129.40
#ErrorDocument 404 /
DocumentRoot /var/www/ecolint.ch/dev/ecolint/trunk/admin
CustomLog /var/www/ecolint.ch/logs/access_log combined
ErrorLog /var/www/ecolint.ch/logs/error_log
Options -MultiViews -Indexes -Includes +FollowSymlinks
AllowOverride All
Order allow,deny
Allow from all
Alias /mysql/ /var/www/ecolint.ch/mysql/
Options -MultiViews -Indexes -Includes -FollowSymlinks
AllowOverride All
Order allow,deny
Allow from all
php_admin_flag register_globals off
php_admin_flag magic_quotes_gpc off
php_admin_flag magic_quotes_runtime off
php_admin_value default_charset utf-8
php_admin_value session.save_path /www/htdocs/ecolint.ch/tmp/
php_admin_value upload_tmp_dir /www/htdocs/ecolint.ch/tmp/
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
[2009-07-01 05:56:00] ras...@php.net
I can't reproduce this. Where in your apache.conf do you have that
line? As in which config blocks is it inside?
[2009-06-30 16:40:31] tom at ideaweb dot de
Description:
Segmentation fault if the following line is enabled in apache.conf:
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql
Maybe i made something wrong or its not a bug in php, because i not
really understand the debug output, but i hope it helps =)
(gdb) run -X
Starting program: /www/apache/2.2.11/bin/httpd -X
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1212832064 (LWP 4837)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212832064
#48744 [Fbk->Opn]: Segmentation fault with open_basedir enabled
ID: 48744 User updated by: tom at ideaweb dot de Reported By: tom at ideaweb dot de -Status: Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux Debian Etch PHP Version: 5.3.0 Assigned To: fb-req-jani New Comment: Without php.ini the server keeps crashing, but i think with "wrong configuration parameters" the server should not crash... Previous Comments: [2009-07-10 14:00:09] jleg at nrw dot net Hi, i just wanted to confirm this behaviour - we recently upgraded one of our development servers from PHP 5.2.9 to 5.3.0, and experienced similar segfaulting. Test script only contains "phpinfo()". It segfaults one time out of three. System is a CentOS 5.3, standard httpd (prefork). Updating PHP was the only change. Reverting back to 5.2.9 stops segfaulting, as well as removing the "php_admin_value open_basedir" in apache config. To build the PHP 5.3.0, the same configure-script as fpr 5.2.x was used - with the exception of including "mysqlnd". Error msg in log while segfaulting is (note that garbage in "allowed paths"): PHP Warning: Unknown: open_basedir restriction in effect. File(<>/t.php) is not within the allowed path(s): (\³<\³< Àg= ) in Unknown on line 0 PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 regards, Jan [2009-07-07 17:23:23] j...@php.net Obvious thing to check is what are the differences in your working installation and this non-working one's php.ini, configure line, loaded modules, apache settings..etc. ---- [2009-07-01 19:48:11] tom at ideaweb dot de Thread Safety is disabled (shown in phpinfo()), but i did never enabled it on our servers, and we have lot... and i'm using apache2- mpm-prefork... these default configurations ran never in trouble for me, on high traffic sites too, but in this case it crashes on each request. =( ./configure \ "--enable-so" \ "--enable-cgi" \ "--enable-info" \ "--enable-rewrite" \ "--enable-usertrack" \ "--enable-deflate" \ "--enable-dav" \ "--enable-unique-id" \ "--enable-dav-fs" \ "--enable-dav-lock" \ "--enable-mime-magic" \ "--enable-proxy" \ "--enable-ssl" \ "--with-ssl=/usr" \ "--prefix=/www/apache/2.2.11" [...] checking which MPM to use... prefork [...] ./configure \ --prefix=/www/prog/php/5.3.0 \ --with-apxs2=/www/apache/2.2.11/bin/apxs \ --with-config-file-path=/www/etc \ --with-iconv=/usr/local \ --with-iconv-dir=/usr/local \ --with-mysqli=/www/prog/mysql/current/bin/mysql_config \ --with-mysql-sock=/www/share/mysql/current/mysqld.sock \ --with-pdo-mysql=/www/prog/mysql/current/ \ --with-mysql=/www/prog/mysql/current/ \ --enable-safe-mode=no \ --enable-discard \ --enable-magic-quotes \ --enable-track-vars \ --with-zlib \ --with-zlib-dir=/usr \ --enable-trans-sid \ --with-openssl=/usr \ --enable-wddx \ --enable-bcmath \ --enable-shmop \ --enable-mhash \ --enable-ftp \ --enable-calendar \ --with-gd \ --with-freetype \ --with-freetype-dir=/usr \ --with-jpeg \ --with-jpeg-dir=/usr \ --enable-exif \ --with-png \ --with-png-dir=/usr \ --enable-mbstring \ --enable-sockets \ --with-mhash=/usr \ --with-ldap=/usr \ --with-kerberos=/usr \ --with-libxml-dir=/usr \ --with-gettext \ --with-xsl=/usr \ --enable-soap \ --with-mcrypt \ --enable-debug [2009-07-01 17:59:47] sjoerd-php at linuxonly dot nl Are you perhaps running a multithreaded Apache server with a non-thread-safe PHP module? Check "Thread Safety" in phpinfo() and whether you have apache2-mpm-worker or apache2-mpm-prefork. [2009-07-01 07:33:34] tom at ideaweb dot de Its really strange, because i have several php53 installations without any trouble with the same configuration, but only on one dev server it crashes. if you cannot reproduce, its not a big deal that you can get access to our dev server, there are not secrets and no data... ServerAdmin webmas...@ecolint.ch ServerName ecodev.ecolint.ch ServerAlias ecm.ideaweb.de ServerAlias 217.169.129.40 #ErrorDocument 404 / DocumentRoot /var/www/ecolint.ch/dev/ecolint/trunk/admin CustomLog /var/www/ecolint.ch/logs/access_log combined ErrorLog /var/www/ecolint.ch/logs/error_log Options -MultiViews -Indexes -Includes +FollowSymlinks AllowOverride All Order allow,deny Allow from all Alias /mysql/ /v
#48744 [Fbk->Opn]: Segmentation fault with open_basedir enabled
ID: 48744 User updated by: tom at ideaweb dot de Reported By: tom at ideaweb dot de -Status: Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux Debian Etch PHP Version: 5.3.0 Assigned To: fb-req-jani New Comment: Keeps crashing with php5.3-200907101630 =( [Fri Jul 10 20:41:45 2009] [notice] child pid 13862 exit signal Segmentation fault (11) [Fri Jul 10 20:41:47 2009] [notice] child pid 13863 exit signal Segmentation fault (11) Previous Comments: [2009-07-10 18:26:39] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Just in case this is just another side-effect caused by another bug.. [2009-07-10 15:50:01] tom at ideaweb dot de Without php.ini the server keeps crashing, but i think with "wrong configuration parameters" the server should not crash... [2009-07-10 14:00:09] jleg at nrw dot net Hi, i just wanted to confirm this behaviour - we recently upgraded one of our development servers from PHP 5.2.9 to 5.3.0, and experienced similar segfaulting. Test script only contains "phpinfo()". It segfaults one time out of three. System is a CentOS 5.3, standard httpd (prefork). Updating PHP was the only change. Reverting back to 5.2.9 stops segfaulting, as well as removing the "php_admin_value open_basedir" in apache config. To build the PHP 5.3.0, the same configure-script as fpr 5.2.x was used - with the exception of including "mysqlnd". Error msg in log while segfaulting is (note that garbage in "allowed paths"): PHP Warning: Unknown: open_basedir restriction in effect. File(<>/t.php) is not within the allowed path(s): (\³<\³< Àg= ) in Unknown on line 0 PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 regards, Jan [2009-07-07 17:23:23] j...@php.net Obvious thing to check is what are the differences in your working installation and this non-working one's php.ini, configure line, loaded modules, apache settings..etc. ---- [2009-07-01 19:48:11] tom at ideaweb dot de Thread Safety is disabled (shown in phpinfo()), but i did never enabled it on our servers, and we have lot... and i'm using apache2- mpm-prefork... these default configurations ran never in trouble for me, on high traffic sites too, but in this case it crashes on each request. =( ./configure \ "--enable-so" \ "--enable-cgi" \ "--enable-info" \ "--enable-rewrite" \ "--enable-usertrack" \ "--enable-deflate" \ "--enable-dav" \ "--enable-unique-id" \ "--enable-dav-fs" \ "--enable-dav-lock" \ "--enable-mime-magic" \ "--enable-proxy" \ "--enable-ssl" \ "--with-ssl=/usr" \ "--prefix=/www/apache/2.2.11" [...] checking which MPM to use... prefork [...] ./configure \ --prefix=/www/prog/php/5.3.0 \ --with-apxs2=/www/apache/2.2.11/bin/apxs \ --with-config-file-path=/www/etc \ --with-iconv=/usr/local \ --with-iconv-dir=/usr/local \ --with-mysqli=/www/prog/mysql/current/bin/mysql_config \ --with-mysql-sock=/www/share/mysql/current/mysqld.sock \ --with-pdo-mysql=/www/prog/mysql/current/ \ --with-mysql=/www/prog/mysql/current/ \ --enable-safe-mode=no \ --enable-discard \ --enable-magic-quotes \ --enable-track-vars \ --with-zlib \ --with-zlib-dir=/usr \ --enable-trans-sid \ --with-openssl=/usr \ --enable-wddx \ --enable-bcmath \ --enable-shmop \ --enable-mhash \ --enable-ftp \ --enable-calendar \ --with-gd \ --with-freetype \ --with-freetype-dir=/usr \ --with-jpeg \ --with-jpeg-dir=/usr \ --enable-exif \ --with-png \ --with-png-dir=/usr \ --enable-mbstring \ --enable-sockets \ --with-mhash=/usr \ --with-ldap=/usr \ --with-kerberos=/usr \ --with-libxml-dir=/usr \ --with-gettext \ --with-xsl=/usr \ --enable-soap \ --with-mcrypt \ --enable-debug 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/48744 -- Edit this bug report at http://bugs.php.net/?id=48744&edit=1
#48744 [Fbk->Opn]: Segmentation fault with open_basedir enabled
ID: 48744
User updated by: tom at ideaweb dot de
Reported By: tom at ideaweb dot de
-Status: Feedback
+Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
Assigned To: fb-req-jani
New Comment:
Sorry for the delay, the test server was in use...
Seems to be the same =(
(gdb) run -X -d /www/apache/current/
Starting program: /www/apache/2.2.11/bin/httpd -X -d
/www/apache/current/
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1212967232 (LWP 27684)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212967232 (LWP 27684)]
0xb755848f in OnUpdateBaseDir (entry=0x824fbb8,
new_value=0x83b5070
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7b37e80,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200907101630/main/fopen_wrappers.c:103
103 if (!*p || !**p) {
(gdb)
Previous Comments:
[2009-07-10 22:15:18] j...@php.net
Is the backtrace the same?
[2009-07-10 18:46:07] tom at ideaweb dot de
Keeps crashing with php5.3-200907101630 =(
[Fri Jul 10 20:41:45 2009] [notice] child pid 13862 exit signal
Segmentation fault (11)
[Fri Jul 10 20:41:47 2009] [notice] child pid 13863 exit signal
Segmentation fault (11)
[2009-07-10 18:26:39] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Just in case this is just another side-effect caused by another bug..
[2009-07-10 15:50:01] tom at ideaweb dot de
Without php.ini the server keeps crashing, but i think with "wrong
configuration parameters" the server should not crash...
[2009-07-10 14:00:09] jleg at nrw dot net
Hi,
i just wanted to confirm this behaviour - we recently upgraded one of
our development servers from PHP 5.2.9 to 5.3.0, and experienced similar
segfaulting. Test script only contains "phpinfo()".
It segfaults one time out of three.
System is a CentOS 5.3, standard httpd (prefork). Updating PHP was the
only change. Reverting back to 5.2.9 stops segfaulting, as well as
removing the "php_admin_value open_basedir" in apache config.
To build the PHP 5.3.0, the same configure-script as fpr 5.2.x was used
- with the exception of including "mysqlnd".
Error msg in log while segfaulting is (note that garbage in "allowed
paths"):
PHP Warning: Unknown: open_basedir restriction in effect.
File(<>/t.php) is not within the allowed path(s): (\³<\³<
Àg= ) in Unknown on line 0
PHP Warning: Unknown: failed to open stream: Operation not permitted
in Unknown on line 0
regards, Jan
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/48744
--
Edit this bug report at http://bugs.php.net/?id=48744&edit=1
#49100 [NEW]: Reference Native Function in variable (function pointers)
From: tom at r dot je
Operating system: Windows Vista
PHP version: 5.3.0
PHP Bug Type: Feature/Change Request
Bug description: Reference Native Function in variable (function pointers)
Description:
With the intorduction of closures it would be nice to be able to have some
control over native functions for example:
$foo = function() {
echo 'bar';
}
$foo();
Works fine.
It would be nice to be able to do something like
function foo() {
echo 'bar';
}
$foo = &foo;
$foo();
And ultimately, override the defined function:
function foo() {
echo 'bar';
}
$oldFoo = &foo;
foo = function() use ($oldFoo) {
$oldFoo();
echo 'bar';
}
foo(); // will print 'foobar';
There are several uses for this, just look at the way closures are
commonly used in javascript. It's really useful for debugging, as a
function can be substituted easily.
Though this probably isn't possible due to the clear distinction php makes
between functions and variables.
--
Edit bug report at http://bugs.php.net/?id=49100&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49100&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49100&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49100&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49100&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49100&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49100&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49100&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49100&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49100&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49100&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49100&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49100&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49100&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49100&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49100&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49100&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49100&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49100&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49100&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49100&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49100&r=mysqlcfg
#48744 [NoF->Opn]: Segmentation fault with open_basedir enabled
ID: 48744 User updated by: tom at ideaweb dot de Reported By: tom at ideaweb dot de -Status: No Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux Debian Etch PHP Version: 5.3.0 Assigned To: fb-req-jani New Comment: My problem is, currently its only the first linux server with running php53. Other server needs several modules like ionCube which seems to be not working with, maybe not compatible/supported by the vendor. But i tried it with one server... iconCube will be loaded, but php53 throws a lot of errors if open_basedir is enabled. I got errors that iconcube is not in allowed path. A module in "not allowed path"? For ex. i defined 3 entries for open_basedir like /var/www:/var/tmp:/var/upload and i get 3 errors that /var/www/iconcube.so, /var/tmp/iconcube.so etc. is not in allowed path. Thats why currently i cannot check the issue with the segmentation fault. Otherwise i "found" a simple server with a lot of wordpress blogs and i installed php53. With open_basedir enabled 70% of requests throw an HTTP 500 (not segmentation fault), but without open_basedir the server runs smoothly, realy strange... the same issue but "HTTP 500"?? Or is wordpress/apache/mod_rewrite the troublemaker? I have no idea, how i can debug it. I reversed the installation because the blogs has to run... Thats why i installed a new server in our office and installed one of our running project, with the same configuration and installing procedure like all our other servers (see first post). Without open_basedir enabled it runs but otherwise 20% of the request fails with the following error message: Warning: Unknown: open_basedir restriction in effect. File(/var/www/bebees/trunk/bebees/index.php) is not within the allowed path(s): (MaṀ]) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 Fatal error: Unknown: Failed opening required '/var/www/bebees/trunk/bebees/index.php' (include_path='.:/www/prog/php/5.3.0/lib/php') in Unknown on line 0 If i make an erroron purpose, php throws an message as expected for ex.: Warning: include_once() [function.include-once]: open_basedir restriction in effect. File(/var/www/ideacmf/tags/1_0_4/core/cmf.php) is not within the allowed path(s): (/www/tmp:/var/www/bebees/trunk) in /var/www/bebees/trunk/bebees/index.php on line 16 Than i installed the same project which is installed as in my first post, but same result, no segmentation fault: Warning: Unknown: open_basedir restriction in effect. File(/var/www/ecolint/trunk/admin/index.php) is not within the allowed path(s): (M۸) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 Fatal error: Unknown: Failed opening required '/var/www/ecolint/trunk/admin/index.php' (include_path='.:/www/prog/php/5.3.0/lib/php') in Unknown on line 0 On the test server, which i've reported first, i have no clue what i can do else, because i've never learned/used c/c++ with all its dev tools or how i can provide more information to fixing this issue, maybe something with used adaptec driver in kernel, which returns an "unexpected result" which let apache runs in trouble, no idea... Sorry for the information leak =( ... Previous Comments: [2009-07-30 09:13:51] starcraftmazter at gmail dot com Hello there I can confirm that I have a very similar issue. I have been running PHP with open_basedir for quite some time. I upgraded to php 5.3.0 recently, previously having ran php 5.2.5. Immediately after installing the newly compiled version, the issues began. The problem as I experience it, is that the "open_basedir" setting seems to be composed of random, non latin1 characters (displayed as symbols by the browser). I cannot draw any reasons as to which users are affected by this or why, but it does not happen to everyone - it is seemingly random. I am using CentOS 5.3 with the latest cPanel 11 on CURRENT which manages the open_basedir. I am using Apache 2.2.6. My compile string is as follows; './configure' '--prefix=/usr/local' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-bcmath' '--enable-calendar' '--enable-exif' '--enable-ftp' '--enable-gd-native-ttf' '--enable-libxml' '--enable-mbstring' '--enable-soap' '--enable-sockets' '--enable-zip' '--with-bz2' '--with-curl=/opt/curlssl/' '--with-curlwrappers' '--with-freetype-dir=/usr' '--with-gd' '--with-gettext' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/us
#48744 [Opn]: Segmentation fault with open_basedir enabled
ID: 48744 User updated by: tom at ideaweb dot de Reported By: tom at ideaweb dot de Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux Debian Etch PHP Version: 5.3.0 Assigned To: fb-req-jani New Comment: Maybe i'm wrong, if add the "prefix" path where php is installed to open_basedir directive, the segmentation fault and the strange "unicode" outputs are gone on all my machines (linux+osx) ./configure \ --prefix=/www/prog/php/5.3.0 \ php_admin_value open_basedir /www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol int.ch/mysql:/www/prog/php but... it should be confirmed by others! =) Previous Comments: ---- [2009-07-31 15:54:07] tom at ideaweb dot de My problem is, currently its only the first linux server with running php53. Other server needs several modules like ionCube which seems to be not working with, maybe not compatible/supported by the vendor. But i tried it with one server... iconCube will be loaded, but php53 throws a lot of errors if open_basedir is enabled. I got errors that iconcube is not in allowed path. A module in "not allowed path"? For ex. i defined 3 entries for open_basedir like /var/www:/var/tmp:/var/upload and i get 3 errors that /var/www/iconcube.so, /var/tmp/iconcube.so etc. is not in allowed path. Thats why currently i cannot check the issue with the segmentation fault. Otherwise i "found" a simple server with a lot of wordpress blogs and i installed php53. With open_basedir enabled 70% of requests throw an HTTP 500 (not segmentation fault), but without open_basedir the server runs smoothly, realy strange... the same issue but "HTTP 500"?? Or is wordpress/apache/mod_rewrite the troublemaker? I have no idea, how i can debug it. I reversed the installation because the blogs has to run... Thats why i installed a new server in our office and installed one of our running project, with the same configuration and installing procedure like all our other servers (see first post). Without open_basedir enabled it runs but otherwise 20% of the request fails with the following error message: Warning: Unknown: open_basedir restriction in effect. File(/var/www/bebees/trunk/bebees/index.php) is not within the allowed path(s): (MaṀ]) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 Fatal error: Unknown: Failed opening required '/var/www/bebees/trunk/bebees/index.php' (include_path='.:/www/prog/php/5.3.0/lib/php') in Unknown on line 0 If i make an erroron purpose, php throws an message as expected for ex.: Warning: include_once() [function.include-once]: open_basedir restriction in effect. File(/var/www/ideacmf/tags/1_0_4/core/cmf.php) is not within the allowed path(s): (/www/tmp:/var/www/bebees/trunk) in /var/www/bebees/trunk/bebees/index.php on line 16 Than i installed the same project which is installed as in my first post, but same result, no segmentation fault: Warning: Unknown: open_basedir restriction in effect. File(/var/www/ecolint/trunk/admin/index.php) is not within the allowed path(s): (M۸) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 Fatal error: Unknown: Failed opening required '/var/www/ecolint/trunk/admin/index.php' (include_path='.:/www/prog/php/5.3.0/lib/php') in Unknown on line 0 On the test server, which i've reported first, i have no clue what i can do else, because i've never learned/used c/c++ with all its dev tools or how i can provide more information to fixing this issue, maybe something with used adaptec driver in kernel, which returns an "unexpected result" which let apache runs in trouble, no idea... Sorry for the information leak =( ...) [2009-07-30 09:13:51] starcraftmazter at gmail dot com Hello there I can confirm that I have a very similar issue. I have been running PHP with open_basedir for quite some time. I upgraded to php 5.3.0 recently, previously having ran php 5.2.5. Immediately after installing the newly compiled version, the issues began. The problem as I experience it, is that the "open_basedir" setting seems to be composed of random, non latin1 characters (displayed as symbols by the browser). I cannot draw any reasons as to which users are affected by this or why, but it does not happen to everyone - it is seemingly random. I am using CentOS 5.3 with the latest cPanel 11 on CURRENT which manages the open_basedir. I am using Apache 2.2.6. My compile string is as follows; './configure' '--prefix=/usr/local' '--with-apxs2=/usr/local/apache/bin/apxs' '--en
#48744 [Fbk->Opn]: Segmentation fault with open_basedir enabled
ID: 48744
User updated by: tom at ideaweb dot de
Reported By: tom at ideaweb dot de
-Status: Feedback
+Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
New Comment:
I installed php5.3-200908010830:
with the "prefix" directory
php_admin_value open_basedir
/var/www/ecolint.ch/dev:/var/www/ecolint.ch/tmp:/var/www/ecolint.ch/my
sql:/www/prog/php
everything works as expected, but without it
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql
it crashes again:
(gdb) run -X
Starting program: /www/apache/2.2.11/bin/httpd -X
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1213593920 (LWP 22640)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213593920 (LWP 22640)]
0xb74bf52b in OnUpdateBaseDir (entry=0x824fb10,
new_value=0x84d3ce8
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7a9eee0,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200908010830/main/fopen_wrappers.c:103
103 if (!*p || !**p) {
(gdb) bt
#0 0xb74bf52b in OnUpdateBaseDir (entry=0x824fb10,
new_value=0x84d3ce8
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7a9eee0,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200908010830/main/fopen_wrappers.c:103
#1 0xb753bb45 in zend_alter_ini_entry_ex (name=0x819a7a0
"open_basedir", name_length=13,
new_value=0x81fad60
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4, force_change=0)
at /www/src/php5.3-200908010830/Zend/zend_ini.c:291
#2 0xb753b94b in zend_alter_ini_entry (name=0x819a7a0 "open_basedir",
name_length=13,
new_value=0x81fad60
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4) at /www/src/php5.3-
200908010830/Zend/zend_ini.c:249
#3 0xb75ed4fe in apply_config (dummy=0x81fb3e8)
at /www/src/php5.3-
200908010830/sapi/apache2handler/apache_config.c:197
#4 0xb75ec8bb in php_handler (r=0x8384c18)
at /www/src/php5.3-
200908010830/sapi/apache2handler/sapi_apache2.c:547
#5 0x0807dad7 in ap_run_handler (r=0x8384c18) at config.c:157
#6 0x08080bc7 in ap_invoke_handler (r=0x8384c18) at config.c:372
#7 0x080c84da in ap_internal_redirect (new_uri=0x8384be8
"/index.php/contacts/form_contacts_browse/1?",
r=0x837fee0) at http_request.c:501
#8 0x080f3f41 in handler_redirect (r=0x837fee0) at mod_rewrite.c:4801
#9 0x0807dad7 in ap_run_handler (r=0x837fee0) at config.c:157
#10 0x08080bc7 in ap_invoke_handler (r=0x837fee0) at config.c:372
#11 0x080c8658 in ap_process_request (r=0x837fee0) at
http_request.c:282
#12 0x080c581e in ap_process_http_connection (c=0x836fdf0) at
http_core.c:190
#13 0x08084a87 in ap_run_process_connection (c=0x836fdf0) at
connection.c:43
#14 0x080f846d in child_main (child_num_arg=) at
prefork.c:650
#15 0x080f86a5 in make_child (s=0x813d648, slot=0) at prefork.c:690
#16 0x080f944c in ap_mpm_run (_pconf=0x81380a8, plog=0x8188328,
s=0x813d648) at prefork.c:966
#17 0x0806b44f in main (argc=135487648, argv=0x836dc10) at main.c:740
the strange output (bug #48880) i will check later
Previous Comments:
[2009-07-31 23:05:06] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
This is most likely fixed now. See also bug #48880
----
[2009-07-31 16:52:49] tom at ideaweb dot de
Maybe i'm wrong, if add the "prefix" path where php is installed to
open_basedir directive, the segmentation fault and the strange
"unicode"
outputs are gone on all my machines (linux+osx)
./configure \
--prefix=/www/prog/php/5.3.0 \
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql:/www/prog/php
but... it should be confirmed by others! =))
[2009-07-31 15:54:07] tom at ideaweb dot de
My problem is, currently its only the first linux server with running
php53. Other server needs several modules like ionCube which seems to be
not working with, maybe not compatible/supported by the vendor.
But i tried it with one server... iconCube will be loaded, but php53
throws a lot of errors if open_basedir is enabled. I got errors that
iconcube is not in allowed path. A module in &
#48744 [Opn]: Segmentation fault with open_basedir enabled
ID: 48744
User updated by: tom at ideaweb dot de
Reported By: tom at ideaweb dot de
Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
New Comment:
i forgot to write:
/var/www/ecolint.ch/dev:/var/www/ecolint.ch/tmp:/var/www/ecolint.ch/mysql
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecolint.ch/mysql
are the same, and will crash too if there is no /www/prog/php..
sorry for confusion =)
Previous Comments:
[2009-08-01 09:57:06] tom at ideaweb dot de
I installed php5.3-200908010830:
with the "prefix" directory
php_admin_value open_basedir
/var/www/ecolint.ch/dev:/var/www/ecolint.ch/tmp:/var/www/ecolint.ch/my
sql:/www/prog/php
everything works as expected, but without it
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql
it crashes again:
(gdb) run -X
Starting program: /www/apache/2.2.11/bin/httpd -X
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1213593920 (LWP 22640)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213593920 (LWP 22640)]
0xb74bf52b in OnUpdateBaseDir (entry=0x824fb10,
new_value=0x84d3ce8
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7a9eee0,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200908010830/main/fopen_wrappers.c:103
103 if (!*p || !**p) {
(gdb) bt
#0 0xb74bf52b in OnUpdateBaseDir (entry=0x824fb10,
new_value=0x84d3ce8
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7a9eee0,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200908010830/main/fopen_wrappers.c:103
#1 0xb753bb45 in zend_alter_ini_entry_ex (name=0x819a7a0
"open_basedir", name_length=13,
new_value=0x81fad60
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4, force_change=0)
at /www/src/php5.3-200908010830/Zend/zend_ini.c:291
#2 0xb753b94b in zend_alter_ini_entry (name=0x819a7a0 "open_basedir",
name_length=13,
new_value=0x81fad60
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4) at /www/src/php5.3-
200908010830/Zend/zend_ini.c:249
#3 0xb75ed4fe in apply_config (dummy=0x81fb3e8)
at /www/src/php5.3-
200908010830/sapi/apache2handler/apache_config.c:197
#4 0xb75ec8bb in php_handler (r=0x8384c18)
at /www/src/php5.3-
200908010830/sapi/apache2handler/sapi_apache2.c:547
#5 0x0807dad7 in ap_run_handler (r=0x8384c18) at config.c:157
#6 0x08080bc7 in ap_invoke_handler (r=0x8384c18) at config.c:372
#7 0x080c84da in ap_internal_redirect (new_uri=0x8384be8
"/index.php/contacts/form_contacts_browse/1?",
r=0x837fee0) at http_request.c:501
#8 0x080f3f41 in handler_redirect (r=0x837fee0) at mod_rewrite.c:4801
#9 0x0807dad7 in ap_run_handler (r=0x837fee0) at config.c:157
#10 0x08080bc7 in ap_invoke_handler (r=0x837fee0) at config.c:372
#11 0x080c8658 in ap_process_request (r=0x837fee0) at
http_request.c:282
#12 0x080c581e in ap_process_http_connection (c=0x836fdf0) at
http_core.c:190
#13 0x08084a87 in ap_run_process_connection (c=0x836fdf0) at
connection.c:43
#14 0x080f846d in child_main (child_num_arg=) at
prefork.c:650
#15 0x080f86a5 in make_child (s=0x813d648, slot=0) at prefork.c:690
#16 0x080f944c in ap_mpm_run (_pconf=0x81380a8, plog=0x8188328,
s=0x813d648) at prefork.c:966
#17 0x0806b44f in main (argc=135487648, argv=0x836dc10) at main.c:740
the strange output (bug #48880) i will check later)
[2009-07-31 23:05:06] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
This is most likely fixed now. See also bug #48880
----
[2009-07-31 16:52:49] tom at ideaweb dot de
Maybe i'm wrong, if add the "prefix" path where php is installed to
open_basedir directive, the segmentation fault and the strange
"unicode"
outputs are gone on all my machines (linux+osx)
./configure \
--prefix=/www/prog/php/5.3.0 \
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql:/www/prog/php
but... it should be confirmed by others! =))
[2009-07-31 15:54:07] tom at ideaweb dot de
My problem is, currently its on
#48744 [Fbk->Csd]: Segmentation fault with open_basedir enabled
ID: 48744
User updated by: tom at ideaweb dot de
Reported By: tom at ideaweb dot de
-Status: Feedback
+Status: Closed
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
New Comment:
Perfect... it works! Segmentation fault is gone with modified
fopen_wrappers.c. Thx!
Previous Comments:
[2009-08-01 15:15:15] ras...@php.net
Aha, I just checked that snapshot you said you used. It does not have
my fix yet. Mystery solved, I hope.
You can make this one-line change manually in your code to check it:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/fopen_wrappers.c?r1=282359&r2=286602&pathrev=286602
[2009-08-01 14:56:35] ras...@php.net
There is something very fishy going on. Your backtrace shows that
OnUpdateBaseDir was called with stage=4 and then it shows the segfault
at the line that has:
if (!*p || !**p) {
But that was exactly what I fixed when I fixed bug #48880
stage 4 is PHP_INI_STAGE_ACTIVATE and the current code has:
if (stage == PHP_INI_STAGE_STARTUP || stage ==
PHP_INI_STAGE_SHUTDOWN || stage == PHP_INI_STAGE_ACTIVATE || stage ==
PHP_INI_STAGE_DEACTIVATE) {
/* We're in a PHP_INI_SYSTEM context, no restrictions */
*p = new_value;
return SUCCESS;
}
/* Otherwise we're in runtime */
if (!*p || !**p) {
/* open_basedir not set yet, go ahead and give it a value */
*p = new_value;
return SUCCESS;
}
So I don't see how a call to OnUpdateBaseDir with stage=4 could have
gotten to that condition if you are indeed running the latest code.
Please check main/fopen_wrappers.c line 96 and make sure it has the
check for PHP_INI_STAGE_ACTIVATE there.
[2009-08-01 10:00:43] tom at ideaweb dot de
i forgot to write:
/var/www/ecolint.ch/dev:/var/www/ecolint.ch/tmp:/var/www/ecolint.ch/mysql
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecolint.ch/mysql
are the same, and will crash too if there is no /www/prog/php..
sorry for confusion =))
[2009-08-01 09:57:06] tom at ideaweb dot de
I installed php5.3-200908010830:
with the "prefix" directory
php_admin_value open_basedir
/var/www/ecolint.ch/dev:/var/www/ecolint.ch/tmp:/var/www/ecolint.ch/my
sql:/www/prog/php
everything works as expected, but without it
php_admin_value open_basedir
/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol
int.ch/mysql
it crashes again:
(gdb) run -X
Starting program: /www/apache/2.2.11/bin/httpd -X
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1213593920 (LWP 22640)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213593920 (LWP 22640)]
0xb74bf52b in OnUpdateBaseDir (entry=0x824fb10,
new_value=0x84d3ce8
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7a9eee0,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200908010830/main/fopen_wrappers.c:103
103 if (!*p || !**p) {
(gdb) bt
#0 0xb74bf52b in OnUpdateBaseDir (entry=0x824fb10,
new_value=0x84d3ce8
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7a9eee0,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200908010830/main/fopen_wrappers.c:103
#1 0xb753bb45 in zend_alter_ini_entry_ex (name=0x819a7a0
"open_basedir", name_length=13,
new_value=0x81fad60
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4, force_change=0)
at /www/src/php5.3-200908010830/Zend/zend_ini.c:291
#2 0xb753b94b in zend_alter_ini_entry (name=0x819a7a0 "open_basedir",
name_length=13,
new_value=0x81fad60
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, modify_type=4, stage=4) at /www/src/php5.3-
200908010830/Zend/zend_ini.c:249
#3 0xb75ed4fe in apply_config (dummy=0x81fb3e8)
at /www/src/php5.3-
200908010830/sapi/apache2handler/apache_config.c:197
#4 0xb75ec8bb in php_handler (r=0x8384c18)
at /www/src/php5.3-
200908010830/sapi/apache2handler/sapi_apache2.c:547
#5 0x0807dad7 in ap_run_handler (r=0x8384c18) at config.c:157
#6 0x08080bc7 in ap_invoke_handler (r=0x8384c18) at config.c:372
#7 0x080c84da in ap_internal_redirect (new_uri=0x8384be8
"/index.php/contacts/form_contacts_browse/1?",
r=0x837fee0) at http_request.c:501
#8
#40846 [Com]: pcre.backtrack_limit too restrictive
ID: 40846
Comment by: tom at r dot je
Reported By: crisp at xs4all dot nl
Status: Open
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.2.1
New Comment:
This is still an issue in 5.3.
The low limit causes scripts which hit it to fail without a warning,
notice or error, creating hard to track down bugs For example, something
which works fine for one set of data stops working on another set
because the data is just longer.
This cannot be the expected behaviour, surely?
At minimum there needs to be a warning. Ideally though, the limit needs
to be put to the pcre defaults.
Previous Comments:
[2007-12-10 14:18:11] daan at react dot nl
This issue is still a problem, plus this low setting is also the cause
of segfaults.
(see http://bugs.php.net/bug.php?id=43031)
At the moment even this simple regexp segfaults 5.2.5:
preg_match('/(.)*/', str_repeat('x', 6000));
I hope that is not intended behavior, as is suggested in the reply in
bug report 43031.
[2007-08-16 19:00:13] drnick at physics dot byu dot edu
I just wanted to throw out that I completely agree with crisp. We
recently updated PHP on our webserver to 5.2.3 and had issues with our
template system on input sizes of a certain size (>100K).
The idea of allowing PHP to enforce limits on the PCRE library is fine,
but having the default action (when recursion_limit and backtrack_limit
are commented-out) be PHP overriding PCRE's internal limits is VERY
problematic. Aside from being incredibly anti backwards-compatible, I
believe PHP should not make arbitrary assumptions such as these.
I believe PHP should be changed so that the default action is to make
use of PCRE's internal limits, and if people want to enforce their own,
they can make that decision via the options. Perhaps modify
php.ini-recommended to explain the options and say why having external
limits can be good.
[2007-08-16 15:58:08] brandon at invisionpower dot com
Installations of 5.2 are causing this issue for us with relatively
simple regex. Users can submit an arbitrary amount of data (I work on a
bulletin board software) that is parsed out for bbcode tags. Even
simple expressions are causing problems.
$txt = preg_replace_callback(
"#\[code\](.+?)\[/code\]#is", array(
&$this, 'regex_code_tag' ), $txt );
var_dump( preg_last_error() );
The callback function is not being hit at all and the output is int(2)
(backtrack limit hit). Increasing backtrack limit to 1,000,000
"resolves" the issue, but with shared hosting plans it's unrealistic to
expect hosts to make php.ini changes to allow this.
I agree with crisp - the limit in PHP should bet set to the internal
PCRE options, with the php.ini settings allowing you to reduce them if
you wish. PHP should not arbitrarily reduce them.
[2007-05-20 11:22:00] crisp at xs4all dot nl
PHP 5.2.0 includes an update of the PCRE library (version 6.7), so some
problems may not be totally due to the restrictive limits of the PCRE
settings in PHP but could be a bug/regression in PCRE itself.
PCRE has always been very poor in internal optimisation of expressions
that contain look-aheads or look-behinds, especially when they are
combined with some OR'ed subexpression. It's backtracking mechanism is
quite simplistic and doesn't rule out execution paths that are sure not
to result in a match - in fact, it doesn't have any sort of execution
planner.
[2007-05-20 11:09:08] tigr at mail15 dot com
It is kinda strange: previous versions work pretty nice, swiftly
executing all patterns. And in some situations (as I mentioned before)
increasing recursion and backtrack limits just won't help. I suppose
it's wrong behaviour.
Also, note that examples are pretty short and simple. Increasing both
limits to 1 000 000 does not help - just why?
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/40846
--
Edit this bug report at http://bugs.php.net/?id=40846&edit=1
#50261 [NEW]: Crash When Calling Parent Constructor with call_user_func()
From: tom at tomwardrop dot com
Operating system: Windows 7 x64
PHP version: 5.3.1
PHP Bug Type: Reproducible crash
Bug description: Crash When Calling Parent Constructor with call_user_func()
Description:
If class B, extends Class A, and class B calls Class A's constructor in
its own contructor by using call_user_func("parent", "__construct"), and if
class A's constructor is defined as the class name rather than
"__construct", then PHP seems to crash (which results in Apache 2
crashing). Problem still exists with all extensions disabled.
Reproduce code:
---
Expected result:
The above code should echo out the string 'Output string!'. This code
works correctly when "call_user_func" or "call_user_func_array" are not
used.
Actual result:
--
call_user_func() and call_user_func_array(), cause PHP and as a result,
Apache 2 to crash. When running PHP DBG debugger, the crash happens on the
execution of call_user_func() line. The Windows event log notes that
httpd.exe (apache) had crashed, blaming php5ts.dll for the fault.
--
Edit bug report at http://bugs.php.net/?id=50261&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50261&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50261&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50261&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50261&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50261&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50261&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50261&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50261&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50261&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50261&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50261&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50261&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50261&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50261&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50261&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50261&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50261&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50261&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50261&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50261&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50261&r=mysqlcfg
#50261 [Opn]: Crash When Calling Parent Constructor with call_user_func()
ID: 50261
User updated by: tom at tomwardrop dot com
Reported By: tom at tomwardrop dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Windows 7 x64
PHP Version: 5.3.1
New Comment:
To clarify, replacing...
call_user_func(array('parent', '__construct'));
...with...
parent::__construct();
...works as expected, hence it's definitely a problem with the
"call_user_func" and "call_user_func_array" functions.
Previous Comments:
--------
[2009-11-22 10:05:54] tom at tomwardrop dot com
Description:
If class B, extends Class A, and class B calls Class A's constructor in
its own contructor by using call_user_func("parent", "__construct"), and
if class A's constructor is defined as the class name rather than
"__construct", then PHP seems to crash (which results in Apache 2
crashing). Problem still exists with all extensions disabled.
Reproduce code:
---
Expected result:
The above code should echo out the string 'Output string!'. This code
works correctly when "call_user_func" or "call_user_func_array" are not
used.
Actual result:
--
call_user_func() and call_user_func_array(), cause PHP and as a result,
Apache 2 to crash. When running PHP DBG debugger, the crash happens on
the execution of call_user_func() line. The Windows event log notes that
httpd.exe (apache) had crashed, blaming php5ts.dll for the fault.
--
Edit this bug report at http://bugs.php.net/?id=50261&edit=1
#46439 [NEW]: POST file upload implementation is a security hole
From: tom at punkave dot com
Operating system: MacOS X 10.5
PHP version: 5.2.6
PHP Bug Type: cURL related
Bug description: POST file upload implementation is a security hole
Description:
PHP's cURL wrapper implements HTTP POST file uploads as follows:
curl_setopt($curl_handle, CURLOPT_POST, 1);
$args['file'] = '@/path/to/file';
curl_setopt($curl_handle, CURLOPT_POSTFIELDS, $args);
When ext/curl/interface.c sees that $args is an array and not a
query-encoded string, it switches to a branch that uses CURLOPT_HTTPPOST
rather than CURLOPT_POST. The code then checks for an '@' prefix in the
value of every field. When an '@' is spotted, that particular field is
treated as a file to be uploaded rather than a value to be sent as-is.
This implementation and the associated documentation have the following
problems which are best described together for clarity's sake:
1. The fact that passing an array of arguments will trigger
multipart/form-data is not documented. The documentation implies that you
can use a query-encoded string or an array interchangeably. While most
servers do accept multipart/form-data this is not a given. Also it is
frequently the less efficient of the two encodings when files are not being
uploaded.
2. When passing an array it is impossible to submit a form field value
that does start with @. This is a bug in the implementation.
3. The documentation makes no mention of the '@ prefix means the rest of
the value is a filename to be uploaded' issue. This is a serious security
problem. PHP pages that transship form submissions from one site to another
are being coded in ignorance of the fact that the '@' prefix could be used
by end users to send any readable file on the first host to the second
host. At a minimum, coders must check for and remove any @ prefix from
user-submitted fields.
A recommended solution:
1. The '@ prefix for files, arrays trigger multipart/form-data' behavior
should be controlled by a php.ini backwards compatibility option, hopefully
defaulting off in the future.
2. CURLOPT_HTTPPOST and CURLOPT_HTTPPOSTFIELDS should be explicitly
supported and documented as the correct way to do multipart/form_data, and
3. Instead of an @ prefix in the values of fields,
CURLOPT_HTTPPOSTFILEFIELDS should be implemented to expressly pass an hash
of keys => filenames.
It would work like this:
// I want a file upload with cURL
curl_setopt($curl_handle, CURLOPT_HTTPPOST, 1);
// Pass the non-file fields
curl_setopt($curl_handle, CURLOPT_HTTPPOSTFIELDS,
array("name" => "Joe Smith"));
// Pass the file fields
curl_setopt($curl_handle, CURLOPT_HTTPPOSTFILEFIELDS,
array("file" => "/path/to/file"));
HTTPPOST is a terrible, confusing name for multipart/form_data, but that's
a cURL problem, not a PHP problem. (: With the above implementation at the
PHP level we would at least have a correct wrapper for cURL on which
friendlier classes could be correctly built.
--
Edit bug report at http://bugs.php.net/?id=46439&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46439&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46439&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46439&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46439&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46439&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46439&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46439&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46439&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46439&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46439&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46439&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46439&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46439&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46439&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46439&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46439&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46439&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46439&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46439&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46439&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46439&r=mysqlcfg
#46439 [Opn]: file upload implementation is flawed
ID: 46439
User updated by: tom at punkave dot com
Reported By: tom at punkave dot com
Status: Open
Bug Type: cURL related
Operating System: *
PHP Version: 5.*CVS,6CVS (2009-01-21)
New Comment:
htmlencode() won't escape @. Neither will htmlentities(). it's a
security bug that no amount of reasonable prudence on the part of
programmers who haven't read this particular bug report will address.
And there is no reason why programmers would expect that filtering input
would be necessary when they are passing individual fields to a function
that ought to be ready to escape them (and in fact does, apart from the
leading @ thing).
The documentation needs to be fixed at a minimum. It would be a much
better idea to get rid of the broken behavior. The @ prefix is a bad
idea (what if I want to pass @?) and with the current lack of
documentation it's a security hole.
This needs to be patched or at least documented.
Previous Comments:
[2009-01-21 19:56:56] j...@php.net
It's security hole only if you don't filter the input..
--------
[2008-10-31 19:18:36] tom at punkave dot com
Description:
PHP's cURL wrapper implements HTTP POST file uploads as follows:
curl_setopt($curl_handle, CURLOPT_POST, 1);
$args['file'] = '@/path/to/file';
curl_setopt($curl_handle, CURLOPT_POSTFIELDS, $args);
When ext/curl/interface.c sees that $args is an array and not a
query-encoded string, it switches to a branch that uses CURLOPT_HTTPPOST
rather than CURLOPT_POST. The code then checks for an '@' prefix in the
value of every field. When an '@' is spotted, that particular field is
treated as a file to be uploaded rather than a value to be sent as-is.
This implementation and the associated documentation have the following
problems which are best described together for clarity's sake:
1. The fact that passing an array of arguments will trigger
multipart/form-data is not documented. The documentation implies that
you can use a query-encoded string or an array interchangeably. While
most servers do accept multipart/form-data this is not a given. Also it
is frequently the less efficient of the two encodings when files are not
being uploaded.
2. When passing an array it is impossible to submit a form field value
that does start with @. This is a bug in the implementation.
3. The documentation makes no mention of the '@ prefix means the rest
of the value is a filename to be uploaded' issue. This is a serious
security problem. PHP pages that transship form submissions from one
site to another are being coded in ignorance of the fact that the '@'
prefix could be used by end users to send any readable file on the first
host to the second host. At a minimum, coders must check for and remove
any @ prefix from user-submitted fields.
A recommended solution:
1. The '@ prefix for files, arrays trigger multipart/form-data'
behavior should be controlled by a php.ini backwards compatibility
option, hopefully defaulting off in the future.
2. CURLOPT_HTTPPOST and CURLOPT_HTTPPOSTFIELDS should be explicitly
supported and documented as the correct way to do multipart/form_data,
and
3. Instead of an @ prefix in the values of fields,
CURLOPT_HTTPPOSTFILEFIELDS should be implemented to expressly pass an
hash of keys => filenames.
It would work like this:
// I want a file upload with cURL
curl_setopt($curl_handle, CURLOPT_HTTPPOST, 1);
// Pass the non-file fields
curl_setopt($curl_handle, CURLOPT_HTTPPOSTFIELDS,
array("name" => "Joe Smith"));
// Pass the file fields
curl_setopt($curl_handle, CURLOPT_HTTPPOSTFILEFIELDS,
array("file" => "/path/to/file"));
HTTPPOST is a terrible, confusing name for multipart/form_data, but
that's a cURL problem, not a PHP problem. (: With the above
implementation at the PHP level we would at least have a correct wrapper
for cURL on which friendlier classes could be correctly built.
--
Edit this bug report at http://bugs.php.net/?id=46439&edit=1
#47975 [NEW]: OpenSSL does not load
From: tom at brainscanmedia dot com Operating system: Windows 2003 Server PHP version: 5.2.9 PHP Bug Type: Unknown/Other Function Bug description: OpenSSL does not load Description: Hey not sure if this is a bug or not but none of your documents help my situation. I just installed the latest version of PHP to see if it works but OpenSSL mod does not load even though I uncommented it. Here is a link to a sample script that shows my info http://www.stoneystraps.com/!Admin/1.php Reproduce code: --- SMTP -> ERROR: Failed to connect to server: Unable to find the socket transport "ssl" - did you forget to enable it when you configured PHP? (24) SMTP Error: Could not connect to SMTP host. Expected result: Mail Sent (phpMailer) -- Edit bug report at http://bugs.php.net/?id=47975&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47975&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47975&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47975&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47975&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47975&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47975&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47975&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47975&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47975&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47975&r=support Expected behavior: http://bugs.php.net/fix.php?id=47975&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47975&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47975&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47975&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47975&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47975&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47975&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47975&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47975&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47975&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47975&r=mysqlcfg
#47975 [Fbk->Opn]: OpenSSL does not load
ID: 47975 User updated by: tom at brainscanmedia dot com Reported By: tom at brainscanmedia dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows 2003 Server PHP Version: 5.2.9 New Comment: Yes its in my path and everything is setup correctly. That link has a phpMailer call at the top so you will see the error I get. I even tried to reload the old php version and same thing. Can there maybe be a conflict with any of the other dll's? Previous Comments: [2009-04-15 21:14:30] paj...@php.net phpinfo does not do any connection. Did you enable it in your php.ini? Are the openssl DLL in your path? [2009-04-15 21:09:50] tom at brainscanmedia dot com Description: Hey not sure if this is a bug or not but none of your documents help my situation. I just installed the latest version of PHP to see if it works but OpenSSL mod does not load even though I uncommented it. Here is a link to a sample script that shows my info http://www.stoneystraps.com/!Admin/1.php Reproduce code: --- SMTP -> ERROR: Failed to connect to server: Unable to find the socket transport "ssl" - did you forget to enable it when you configured PHP? (24) SMTP Error: Could not connect to SMTP host. Expected result: Mail Sent (phpMailer) -- Edit this bug report at http://bugs.php.net/?id=47975&edit=1
