Bug #65990 [Csd]: Test bug
Edit report at https://bugs.php.net/bug.php?id=65990&edit=1 ID: 65990 Updated by: bj...@php.net Reported by:ras...@php.net Summary:Test bug Status: Closed Type: Bug Package:Testing related PHP Version:Irrelevant Assigned To:bjori -Block user comment: No +Block user comment: Yes Private report: N New Comment: blocking comments.. Previous Comments: [2013-10-29 08:01:05] bj...@php.net closing.. [2013-10-29 07:52:09] bj...@php.net nope, it wasn't [2013-10-29 07:46:01] bj...@php.net fixed? [2013-10-29 07:14:40] ras...@php.net Test 10 - grrr! [2013-10-29 07:09:43] ras...@php.net Test 9 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=65990 -- Edit this bug report at https://bugs.php.net/bug.php?id=65990&edit=1
Bug #65990 [Opn]: Test bug
Edit report at https://bugs.php.net/bug.php?id=65990&edit=1 ID: 65990 Updated by: bj...@php.net Reported by:ras...@php.net Summary:Test bug Status: Open Type: Bug Package:Testing related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: nope, it wasn't Previous Comments: [2013-10-29 07:46:01] bj...@php.net fixed? [2013-10-29 07:14:40] ras...@php.net Test 10 - grrr! [2013-10-29 07:09:43] ras...@php.net Test 9 [2013-10-29 07:08:18] ras...@php.net Test 8 [2013-10-29 07:06:45] ras...@php.net Test 7 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=65990 -- Edit this bug report at https://bugs.php.net/bug.php?id=65990&edit=1
Bug #65990 [Opn]: Test bug
Edit report at https://bugs.php.net/bug.php?id=65990&edit=1 ID: 65990 Updated by: bj...@php.net Reported by:ras...@php.net Summary:Test bug Status: Open Type: Bug Package:Testing related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: fixed? Previous Comments: [2013-10-29 07:14:40] ras...@php.net Test 10 - grrr! [2013-10-29 07:09:43] ras...@php.net Test 9 [2013-10-29 07:08:18] ras...@php.net Test 8 [2013-10-29 07:06:45] ras...@php.net Test 7 [2013-10-29 07:04:12] ras...@php.net Test 6 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=65990 -- Edit this bug report at https://bugs.php.net/bug.php?id=65990&edit=1
Bug #30157 [Csd]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157&edit=1 ID: 30157 Updated by: bj...@php.net Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() Status: Closed Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Assigned To:bjori Block user comment: N Private report: N New Comment: It is called from fseek(), not ftell()? That was the documentation fix as far as I understand the ticket? Previous Comments: [2013-04-30 10:50:16] tb at bytecode dot se I must say that if the documentation was updated in august 2011 then your system is really slow. If you look at the online documentation for streamWrapper::stream_tell it still says "This method is called in response to fseek() to determine the current position." [2011-08-30 11:43:56] bj...@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. [2011-08-30 11:43:48] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=315772 Log: Fixed bug#30157, stream_tell() isn't called by ftell(), only when seeking [2011-08-28 22:06:32] paj...@php.net Hm, actually let move it as a to be documented instead [2011-08-28 22:05:36] paj...@php.net . The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157&edit=1
Bug #64229 [Opn->Fbk]: Streams do not recognize SSL contexts
Edit report at https://bugs.php.net/bug.php?id=64229&edit=1 ID: 64229 Updated by: bj...@php.net Reported by:andrew dot heebner at gmail dot com Summary:Streams do not recognize SSL contexts -Status: Open +Status: Feedback Type: Bug Package:Streams related Operating System: Win7, Linux PHP Version:5.4.11 Block user comment: N Private report: N Previous Comments: [2013-03-02 01:42:49] payden at paydensutherland dot com This seems to work fine for me on Ubuntu 12.10 32-bit with php-5.4.11 and php- 5.4.12. payden@arwen:~$ php test.php Running on 5.4.11 Linux arwen 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 payden@arwen:~$ Something wrong with your cert? [2013-02-17 14:49:03] andrew dot heebner at gmail dot com Description: stream_socket_server does not accept nor use SSL contexts properly. The same bug and reproduction has existed since 2008 without any valid workaround or fix Test script: --- Please see this old bug post, as it is relevant and still throws the same warnings and errors. https://bugs.php.net/bug.php?id=46127 Expected result: An actual functioning SSL stream server Actual result: -- See https://bugs.php.net/bug.php?id=46127 for errors thrown -- Edit this bug report at https://bugs.php.net/bug.php?id=64229&edit=1
Bug #53829 [Opn]: Compiling PHP with large file support will replace function gzopen by gzopen64
Edit report at https://bugs.php.net/bug.php?id=53829&edit=1
ID: 53829
Updated by: bj...@php.net
Reported by:rilatonal at hotmail dot de
Summary:Compiling PHP with large file support will replace
function gzopen by gzopen64
Status: Open
Type: Bug
Package:Zlib related
Operating System: Linux
PHP Version:5.3.5
-Assigned To:
+Assigned To:skettler
Block user comment: N
Private report: N
New Comment:
skettler: Any need for that ifdef? Can't we always use the RAW macro?
And what about the other functions he mentioned in this report?
Previous Comments:
[2013-02-08 12:26:10] skett...@php.net
Added patch "zlib-largefile-function-renaming" that fixes the gzopen, gzseek
and
gztell PHP function renaming.
[2013-02-08 12:24:51] skett...@php.net
The following patch has been added/updated:
Patch Name: zlib-largefile-function-renaming
Revision: 1360326291
URL:
https://bugs.php.net/patch-display.php?bug=53829&patch=zlib-largefile-function-renaming&revision=1360326291
[2012-08-26 11:07:08] comments at sentfrom dot com
I encountered the same problem with a 64-bit build of PHP on OpenIndiana
b151.
The symptom I saw was Wordpress automatic updates were failing silently,
because
the class-pclzip.php module tests for the presence of gzopen.
Patching that file is not a viable option since any WP update can overwrite it
again.
The gzopen patch attached fixes this at the PHP level by using lower-level ZEND
macros that are not affected by zlib.h's #define gzopen gzopen64. It
is preferable to using an undocumented zlib compilation flag ZLIB_INTERNAL,
which may go away at some point in the future.
I had to use ZEND_RAW_FENTRY as it does not have a PHP_ equivalent, and we have
to pass the first argument "gzopen" as a string, since cpp would
replace gzopen with gzopen64 if passed as a C identifier.
[2011-09-07 07:09:20] tx-7-12 at tuxad dot com
Hi,
I also got this "bug" with the latest zlib 1.2.5 as system lib and
"-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1".
Dirty solution: Define ZLIB_INTERNAL.
# /usr/local/php/bin/php -r 'var_dump(function_exists("gzopen"));'
bool(false)
# export CFLAGS="... -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1
-DZLIB_INTERNAL=1"
configure && make
# sapi/cli/php -r 'var_dump(function_exists("gzopen"));'
bool(true)
Matching lines in zlib.h:
#if !defined(ZLIB_INTERNAL) && _FILE_OFFSET_BITS-0 == 64 && _LFS64_LARGEFILE-0
# define gzopen gzopen64
# define gzseek gzseek64
# define gztell gztell64
# define gzoffset gzoffset64
# define adler32_combine adler32_combine64
# define crc32_combine crc32_combine64
# ifdef _LARGEFILE64_SOURCE
ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int));
ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile));
ZEXTERN z_off_t ZEXPORT gzoffset64 OF((gzFile));
ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off_t));
ZEXTERN uLong ZEXPORT crc32_combine64 OF((uLong, uLong, z_off_t));
# endif
#else
ZEXTERN gzFile ZEXPORT gzopen OF((const char *, const char *));
ZEXTERN z_off_t ZEXPORT gzseek OF((gzFile, z_off_t, int));
ZEXTERN z_off_t ZEXPORT gztell OF((gzFile));
ZEXTERN z_off_t ZEXPORT gzoffset OF((gzFile));
ZEXTERN uLong ZEXPORT adler32_combine OF((uLong, uLong, z_off_t));
ZEXTERN uLong ZEXPORT crc32_combine OF((uLong, uLong, z_off_t));
#endif
Frank
[2011-05-27 17:06:42] j dot henge-ernst at interexa dot de
I also encountered that problem compiling php on solaris x86_64 with zlib
1.2.5. I used the following configure commmand:
#! /bin/sh
#
# Created by configure
CFLAGS='-xmodel=small -m64 -Kpic -O4' \
CXXFLAGS='-xmodel=small -m64 -Kpic -O4' \
LDFLAGS='-m64' \
CC='cc' \
'./configure' \
'--prefix=/opt/IXAGib64' \
'--with-config-file-path=/opt/IXAGib64/etc' \
'--with-config-file-scan-dir=/opt/IXAGib64/etc/php.ini.d' \
'--disable-debug' \
'--enable-inline-optimization' \
'--disable-all' \
'--enable-ctype' \
'--enable-dom' \
'--enable-libxml' \
'--with-libxml-dir=/opt/IXAGib64' \
'--with-openssl=/opt/IXAGib64' \
'--with-pcre-regex' \
'--enable-session' \
'--enable-simplexml' \
'--enable-wddx' \
'--enable-xml' \
'--enable-hash' \
'--enable-json' \
'--enable-filter' \
'--with-zlib=/opt/IXAGib64' \
'--with-apxs2=/opt/IXAGib64/bin/apxs' \
'--with-pear' \
'--with-layout=GNU' \
"$@"
The remainder of the comments for this report are too long.
Req #63298 [Opn->Nab]: Nothing resolves upwards in PHP
Edit report at https://bugs.php.net/bug.php?id=63298&edit=1 ID: 63298 Updated by: bj...@php.net Reported by:nat at nath dot is Summary:Nothing resolves upwards in PHP -Status: Open +Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: Unix PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2012-10-26 18:51:52] dagguh at gmail dot com your Animal class is not in global namespace, but in MyProject. You gotta import it via: use MyProject\Animal; This request is invalid BTW. Namespaces should be all in lowercase. [2012-10-17 22:25:08] nat at nath dot is Description: --- >From manual page: http://www.php.net/language.namespaces.global --- I would love to use namespaces, but it seems kind of silly that nothing in PHP resolves upwards (be that variables, classes, constants or functions). Test script: --- https://gist.github.com/3908714/c7639b02a8a4fc2c13ebfbcb35e41d17ab1b8d44 Expected result: whoof Actual result: -- Fatal error: Class 'MyProject\Animal\Animal' not found in /Users/Nathaniel/Projects/test/animal/dog.php on line 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=63298&edit=1
Bug #63821 [Opn->Csd]: incorrect pi value
Edit report at https://bugs.php.net/bug.php?id=63821&edit=1
ID: 63821
Updated by: bj...@php.net
Reported by:sandaq at gmail dot com
Summary:incorrect pi value
-Status: Open
+Status: Closed
Type: Bug
Package:Math related
Operating System: linux
PHP Version:5.3.20
-Assigned To:
+Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
You'll need to complain to whatever distribution you are using.
We don't define the value unless math.h doesn't define it for some wacky reason
on your platform, in which case we fallback on 3.14159265358979323846.
Previous Comments:
[2012-12-20 21:43:05] sandaq at gmail dot com
Description:
php doesn't calculate the correct value of pi
Test script:
---
php-cli -r 'ini_set('precision','100'); echo pi();'
or
Expected result:
3.141592653589793238462643383279502884197169399375
Actual result:
--
3.141592653589793115997963468544185161590576171875
^
--
Edit this bug report at https://bugs.php.net/bug.php?id=63821&edit=1
Bug #40479 [Fbk]: zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=40479&edit=1 ID: 40479 Updated by: bj...@php.net Reported by:rrossi at maggioli dot it Summary:zend_mm_heap corrupted Status: Feedback Type: Bug Package:Reproducible crash Operating System: Suse Linux 9.0 PHP Version:5.2.1 -Block user comment: No +Block user comment: Yes Private report: N New Comment: [02:48] <@nikic> I think user comments should be blocked and there should be some big message at the top saying that people should report separate bugs for their issues [02:48] <@nikic> So if someone can edit the report to include a message at the top that would be great [02:48] <@nikic> It doesn't really help a lot if all zend_mm_heap corrupted reports go into one bug ^^ Previous Comments: [2012-04-02 13:41:26] komanek at natur dot cuni dot cz For me it seems the solution is to compile PHP with --disable-zend-multibyte instead of --enable-zend-multibyte But I am not sure if it breaks something else, I didn't find much documentation on these options. [2012-03-30 18:47:46] nathan at gt dot net Also to add, USE_ZEND_ALLOC=0 did not resolve but gc_disable(); did [2012-03-30 18:46:12] nathan at gt dot net I've also confirmed the above testcase triggers it on 5.3.10 via CLI. Can provide full access to any php developer interested in taking a look, just email me. [2012-03-28 11:42:16] komanek at natur dot cuni dot cz Hi, I used the USE_ZEND_ALLOC=0 and got another segfault. But in this case in the apache error log is hopefuly something useful: *** glibc detected *** /usr/local/apache2/bin/httpd: double free or corruption (!prev): 0x051d6e10 *** === Backtrace: = /lib/libc.so.6[0x7f5a8e3709a8] /lib/libc.so.6(cfree+0x76)[0x7f5a8e372ab6] /usr/local/apache2/modules/libphp5.so(zend_multibyte_read_script+0x2e)[0x7f5a887be90e] /usr/local/apache2/modules/libphp5.so(open_file_for_scanning+0x90)[0x7f5a887bed60] /usr/local/apache2/modules/libphp5.so(compile_file+0x9c)[0x7f5a887bf92c] /usr/local/apache2/modules/libphp5.so[0x7f5a8866575a] /usr/local/apache2/modules/libphp5.so[0x7f5a8881c733] /usr/local/apache2/modules/libphp5.so(execute+0x209)[0x7f5a88813c49] /usr/local/apache2/modules/libphp5.so(zend_execute_scripts+0x17b)[0x7f5a887e52db] /usr/local/apache2/modules/libphp5.so(php_execute_script+0x198)[0x7f5a8878e0f8] /usr/local/apache2/modules/libphp5.so[0x7f5a8887348f] /usr/local/apache2/bin/httpd(ap_run_handler+0x4a)[0x443f5a] /usr/local/apache2/bin/httpd(ap_invoke_handler+0xce)[0x44747e] /usr/local/apache2/bin/httpd(ap_process_request+0x18e)[0x465ece] /usr/local/apache2/bin/httpd[0x462d78] /usr/local/apache2/bin/httpd(ap_run_process_connection+0x4a)[0x44b45a] /usr/local/apache2/bin/httpd[0x46abd0] /usr/local/apache2/bin/httpd[0x46aea4] /usr/local/apache2/bin/httpd(ap_mpm_run+0xbde)[0x46baee] /usr/local/apache2/bin/httpd(main+0x99a)[0x43063a] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f5a8e31b1a6] /usr/local/apache2/bin/httpd(apr_os_proc_mutex_put+0x49)[0x42f819] === Memory map: 0040-00493000 r-xp 08:01 442565 /usr/local/apache2/bin/httpd 00692000-00698000 rw-p 00092000 08:01 442565 /usr/local/apache2/bin/httpd 00698000-0069d000 rw-p 00698000 00:00 0 017e-053d4000 rw-p 017e 00:00 0 [heap] 7f5a8000-7f5a80021000 rw-p 7f5a8000 00:00 0 7f5a80021000-7f5a8400 ---p 7f5a80021000 00:00 0 7f5a8497c000-7f5a84992000 r-xp 08:01 835587 /lib/libgcc_s.so.1 7f5a84992000-7f5a84b92000 ---p 00016000 08:01 835587 /lib/libgcc_s.so.1 7f5a84b92000-7f5a84b93000 rw-p 00016000 08:01 835587 /lib/libgcc_s.so.1 7f5a84b9d000-7f5a84b9e000 r--s 08:11 78792612 /home/apache2/htdocs/horde/lib/core.php 7f5a84b9e000-7f5a84bc1000 r--p 08:11 78799575 /home/apache2/htdocs/horde/mnemo/locale/cs_CZ/LC_MESSAGES/mnemo.mo 7f5a84bc1000-7f5a84bc5000 r-xp 08:01 1884172 /lib/libnss_dns-2.7.so 7f5a84bc5000-7f5a84dc4000 ---p 4000 08:01 1884172 /lib/libnss_dns-2.7.so 7f5a84dc4000-7f5a84dc6000 rw-p 3000 08:01 1884172 /lib/libnss_dns-2.7.so 7f5a84dc6000-7f5a84dfd000 r--p 08:11 78790850 /home/apache2/htdocs/horde/imp/locale/cs_CZ/LC_MESSAGES/imp.mo 7f5a84dfd000-7f5a84dff000 r-xp 08:01 1327349 /usr/lib/gconv/ISO8859-2.so 7f5a84dff000-7f5a84ffe000 ---p 2000 08:01 1327349 /usr/lib/
Req #42516 [Asn->Opn]: __FILE__ resolves symlinks
Edit report at https://bugs.php.net/bug.php?id=42516&edit=1 ID: 42516 Updated by: bj...@php.net Reported by:michael at zedeler dot dk Summary:__FILE__ resolves symlinks -Status: Assigned +Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: Linux PHP Version:4.4.7 -Assigned To:bjori +Assigned To: Block user comment: N Private report: N Previous Comments: [2012-04-06 17:28:55] bj...@php.net I don't know why this was assigned to me [2011-08-20 09:56:33] clicky at erebot dot net Also, the DOCUMENT_ROOT workaround only works in case you're dealing with a website. It's completely useless in case you're working from a terminal (eg. some unit tests run through PHPUnit). +1 on having this behaviour changed (maybe as a second magic constant as other proposed, so as not to break backward compatibility for __FILE__). [2011-07-20 05:23:46] mpok at xs4all dot nl @Tyra3l: the problem most people (including myself) are having is that $_SERVER["SCRIPT_FILENAME"] contains the path to the file that was called, not the path to the file that is actually processed. This means you can't use $_SERVER["SCRIPT_FILENAME"] as a replacement for __FILE__; in fact there is no way to get a non-resolved path to the current script. Example: Website calls [DOCUMENT_ROOT]/index.php Cronjob calls [DOCUMENT_ROOT]/lib/cron/maintenance.php Both files include [DOCUMENT_ROOT]/lib/config/startup.php Now the startup.php script has to set path variables/constants to use throughout the framework. If you use __FILE__ for this it will return the path to the settings.php script, regardless of whether it was included/called from the website (index.php) or the cronjob (maintenance.php). This allows you to reliably set paths relative to the location of settings.php. However if you symlink the /lib/ directory __FILE__ will resolve the symlinked path and thus break for setting the framework paths relative to the website. Using $_SERVER["SCRIPT_FILENAME"] in startup.php will result in different paths depending on which file was called. When called from the website it returns " [DOCUMENT_ROOT]/index.php", when called from the cronjob it returns " [DOCUMENT_ROOT]/lib/cron/maintenance.php". This means that if you want to make sure you get a reliable path to the lib inside the website you'd have to write a bunch of additional code with semi-intelligent matching in order to find a specific path, if at all possible. Another option is to set the base path seperately in each file that is an entry point for the framework so that those files define their existence relative to the lib dir. This does create more dependencies though. All in all it would be far better if there was an option in the php.ini to disable symlink resolving for __FILE__ (and subsequently __DIR__). If I want to resolve symlinks I'd use realpath() anyway. [2011-04-13 09:32:46] tyra3l at gmail dot com $_SERVER["SCRIPT_FILENAME"] can be used for getting the non-resolved path, and the documentation at http://php.net/manual/en/language.constants.predefined.php now contains info about __FILE__ is resolved to absolute path with resolved symlinks. so I think that this could be closed. Tyrael [2009-08-17 12:57:30] michael at zedeler dot dk Fixed subject. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=42516 -- Edit this bug report at https://bugs.php.net/bug.php?id=42516&edit=1
Req #42516 [Asn->Opn]: __FILE__ resolves symlinks
Edit report at https://bugs.php.net/bug.php?id=42516&edit=1 ID: 42516 Updated by: bj...@php.net Reported by:michael at zedeler dot dk Summary:__FILE__ resolves symlinks -Status: Assigned +Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: Linux PHP Version:4.4.7 Assigned To:bjori Block user comment: N Private report: N New Comment: I don't know why this was assigned to me Previous Comments: [2011-08-20 09:56:33] clicky at erebot dot net Also, the DOCUMENT_ROOT workaround only works in case you're dealing with a website. It's completely useless in case you're working from a terminal (eg. some unit tests run through PHPUnit). +1 on having this behaviour changed (maybe as a second magic constant as other proposed, so as not to break backward compatibility for __FILE__). [2011-07-20 05:23:46] mpok at xs4all dot nl @Tyra3l: the problem most people (including myself) are having is that $_SERVER["SCRIPT_FILENAME"] contains the path to the file that was called, not the path to the file that is actually processed. This means you can't use $_SERVER["SCRIPT_FILENAME"] as a replacement for __FILE__; in fact there is no way to get a non-resolved path to the current script. Example: Website calls [DOCUMENT_ROOT]/index.php Cronjob calls [DOCUMENT_ROOT]/lib/cron/maintenance.php Both files include [DOCUMENT_ROOT]/lib/config/startup.php Now the startup.php script has to set path variables/constants to use throughout the framework. If you use __FILE__ for this it will return the path to the settings.php script, regardless of whether it was included/called from the website (index.php) or the cronjob (maintenance.php). This allows you to reliably set paths relative to the location of settings.php. However if you symlink the /lib/ directory __FILE__ will resolve the symlinked path and thus break for setting the framework paths relative to the website. Using $_SERVER["SCRIPT_FILENAME"] in startup.php will result in different paths depending on which file was called. When called from the website it returns " [DOCUMENT_ROOT]/index.php", when called from the cronjob it returns " [DOCUMENT_ROOT]/lib/cron/maintenance.php". This means that if you want to make sure you get a reliable path to the lib inside the website you'd have to write a bunch of additional code with semi-intelligent matching in order to find a specific path, if at all possible. Another option is to set the base path seperately in each file that is an entry point for the framework so that those files define their existence relative to the lib dir. This does create more dependencies though. All in all it would be far better if there was an option in the php.ini to disable symlink resolving for __FILE__ (and subsequently __DIR__). If I want to resolve symlinks I'd use realpath() anyway. [2011-04-13 09:32:46] tyra3l at gmail dot com $_SERVER["SCRIPT_FILENAME"] can be used for getting the non-resolved path, and the documentation at http://php.net/manual/en/language.constants.predefined.php now contains info about __FILE__ is resolved to absolute path with resolved symlinks. so I think that this could be closed. Tyrael [2009-08-17 12:57:30] michael at zedeler dot dk Fixed subject. [2009-08-17 12:56:08] michael at zedeler dot dk Moved to Feature/Change request category. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=42516 -- Edit this bug report at https://bugs.php.net/bug.php?id=42516&edit=1
Req #55807 [Asn->Csd]: Wrong value for splFileObject::SKIP_EMPTY
Edit report at https://bugs.php.net/bug.php?id=55807&edit=1
ID: 55807
Updated by: bj...@php.net
Reported by:jgotti at modedemploi dot fr
Summary:Wrong value for splFileObject::SKIP_EMPTY
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
Package:SPL related
Operating System: linux
PHP Version:5.3.8
Assigned To:colder
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-09-30 14:17:20] bj...@php.net
Heh. Excellent point :)
[2011-09-30 14:17:02] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=317501
Log: Fixed bug #55807 (Wrong value for splFileObject::SKIP_EMPTY)
[2011-09-28 15:21:05] jgotti at modedemploi dot fr
Description:
isn't this weird that splFileObject::SKIP_EMPTY=6.
I think this should be 4 and not 6 as setting splFileObject flag to SKIP_EMPTY
will report flag splFileObject::READ_AHEAD to be set even if not intended to be
set
Test script:
---
$fileObj = new SplFileObject('/tmp/test.txt');
$fileObj->setFlags(SplFileObject::SKIP_EMPTY);
if( $fileObj->getFlags() & SplFileObject::READ_AHEAD ){//<-- should not pass
here we didn't set READ_AHEAD flag
echo "READ_AHEAD on";
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=55807&edit=1
Req #55807 [Asn]: Wrong value for splFileObject::SKIP_EMPTY
Edit report at https://bugs.php.net/bug.php?id=55807&edit=1
ID: 55807
Updated by: bj...@php.net
Reported by:jgotti at modedemploi dot fr
Summary:Wrong value for splFileObject::SKIP_EMPTY
Status: Assigned
Type: Feature/Change Request
Package:SPL related
Operating System: linux
PHP Version:5.3.8
Assigned To:colder
Block user comment: N
Private report: N
New Comment:
Heh. Excellent point :)
Previous Comments:
[2011-09-30 14:17:02] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=317501
Log: Fixed bug #55807 (Wrong value for splFileObject::SKIP_EMPTY)
[2011-09-28 15:21:05] jgotti at modedemploi dot fr
Description:
isn't this weird that splFileObject::SKIP_EMPTY=6.
I think this should be 4 and not 6 as setting splFileObject flag to SKIP_EMPTY
will report flag splFileObject::READ_AHEAD to be set even if not intended to be
set
Test script:
---
$fileObj = new SplFileObject('/tmp/test.txt');
$fileObj->setFlags(SplFileObject::SKIP_EMPTY);
if( $fileObj->getFlags() & SplFileObject::READ_AHEAD ){//<-- should not pass
here we didn't set READ_AHEAD flag
echo "READ_AHEAD on";
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=55807&edit=1
Bug #55743 [Opn->Bgs]: date u - Microseconds (added in PHP 5.2.2)
Edit report at https://bugs.php.net/bug.php?id=55743&edit=1 ID: 55743 Updated by: bj...@php.net Reported by:bugzilla33 at gmail dot com Summary:date u - Microseconds (added in PHP 5.2.2) -Status: Open +Status: Bogus Type: Bug Package:Date/time related Operating System: All PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: "Note: Since this function only accepts integer timestamps the u format character is only useful when using the date_format() function with user based timestamps created with date_create()." See http://php.net/date Previous Comments: [2011-09-20 18:42:46] bugzilla33 at gmail dot com Description: http://pl.php.net/manual/en/function.date.php http://pl.php.net/manual/en/function.gmdate.php Specification: u - Microseconds (added in PHP 5.2.2) - Example: 654321 u formater do not works because second parameter (called timestamp) is int type u formater will works if second parameter (called timestamp) is double (compatible with current int) Please remove u formater useless or fix specyfication or a better fix it int -> double (second parameter) Test script: --- Expected result: 13 13 Actual result: -- 00 00 -- Edit this bug report at https://bugs.php.net/bug.php?id=55743&edit=1
Bug #55735 [Opn->Bgs]: problem: date + PHP5.4 SERVER['REQUEST_TIME']
Edit report at https://bugs.php.net/bug.php?id=55735&edit=1 ID: 55735 Updated by: bj...@php.net Reported by:bugzilla33 at gmail dot com Summary:problem: date + PHP5.4 SERVER['REQUEST_TIME'] -Status: Open +Status: Bogus Type: Bug Package:Date/time related Operating System: All PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. date() accepts integers, not floats, as mentioned in the note on http://php.net/date Previous Comments: [2011-09-20 08:37:59] bugzilla33 at gmail dot com Derick (der...@php.net) remember! SERVER['REQUEST_TIME'] includes microseconds in PHP 5.4 news.txt: - Changed $_SERVER['REQUEST_TIME'] to include microsecond precision. (Ilia) [2011-09-20 08:36:09] bugzilla33 at gmail dot com Description: date + PHP5.4 version of SERVER['REQUEST_TIME'] problem Test script: --- Expected result: Example: 423000 Actual result: -- 00 -- Edit this bug report at https://bugs.php.net/bug.php?id=55735&edit=1
Bug #55642 [->Opn]: DateTime doesn't use default timezone
Edit report at https://bugs.php.net/bug.php?id=55642&edit=1
ID: 55642
Updated by: bj...@php.net
Reported by:alex dot whitman at durham dot ac dot uk
Summary:DateTime doesn't use default timezone
-Status: To be documented
+Status: Open
Type: Bug
Package:Date/time related
Operating System: CentOS 5
PHP Version:5.3.8
Block user comment: N
Private report: N
Previous Comments:
[2011-09-08 17:03:14] der...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
@ sets the timezone to "UTC", this should be documented at
http://uk3.php.net/manual/en/datetime.formats.compound.php
[2011-09-08 14:35:30] alex dot whitman at durham dot ac dot uk
Description:
DateTime doesn't appear to use the default timezone (set either in php.ini or
with date_default_timezone_set()).
It's currently BST in the UK and without calling setTimeZone() on a DateTime
object, format() will produce a date/time that is one hour behind.
If setTimeZone() is called on a DateTime object then the date/time produced by
format() is correct.
date() by itself uses the default timezone that has been set. For consistency,
DateTime should do also.
Test script:
---
format()', "\t", $dt1->format('Y-m-d H:i:s T Z e');
echo "\n";
$dt2 = new DateTime('@' . $now);
$dt2->setTimeZone(new DateTimeZone('Europe/London'));
echo 'DateTime->format()', "\t", $dt2->format('Y-m-d H:i:s T Z e');
echo "\n";
echo 'date()', "\t\t\t", date('Y-m-d H:i:s T Z e', $now);
?>
Expected result:
$dt1->format() should use Europe/London as the timezone and show the correct
time for that timezone.
Actual result:
--
$dt1->format() shows +00:00 as the timezone and is an hour behind.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55642&edit=1
Bug #54798 [Asn->Csd]: Segfault when CURLOPT_STDERR file pointer is closed before calling curl_exec
Edit report at https://bugs.php.net/bug.php?id=54798&edit=1
ID: 54798
Updated by: bj...@php.net
Reported by:sh...@php.net
Summary:Segfault when CURLOPT_STDERR file pointer is closed
before calling curl_exec
-Status: Assigned
+Status: Closed
Type: Bug
Package:cURL related
Operating System: Ubuntu Linux 11.04 x86
PHP Version:trunk-SVN-2011-05-17 (SVN)
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
http://svn.php.net/viewvc?view=revision&revision=316511
Previous Comments:
[2011-09-09 11:36:50] sh...@php.net
The fix was wrong, reopening bug, see discussion over here:
http://news.php.net/php.cvs/66389 and here http://news.php.net/php.cvs/66399
[2011-09-08 14:37:37] bj...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-09-08 14:37:05] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=316417
Log: Fixed bug#54798Segfault when CURLOPT_STDERR file pointer is closed
before calling curl_exec
[2011-05-17 16:25:32] sh...@php.net
Description:
Related to http://bugs.php.net/bug.php?id=48203
Curl crashes when CURLOPT_STDERR file pointer is closed before calling
curl_exec(), i.e.
$fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w');
$ch = curl_init();
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_STDERR, $fp);
curl_setopt($ch, CURLOPT_URL, getenv("PHP_CURL_HTTP_REMOTE_SERVER"));
fclose($fp); // <-- premature close of $fp caused a crash!
curl_exec($ch); // segfault
Error is reproduced on latest svn php5.3, php5.4 and trunk
Fix is also attached here.
Test script:
---
Full test script is available here:
http://svn.php.net/viewvc/php/php-src/trunk/ext/curl/tests/bug48203.phpt?view=markup
Expected result:
No segfault, see test script
Actual result:
--
Segfault
--
Edit this bug report at https://bugs.php.net/bug.php?id=54798&edit=1
Bug #52513 [Opn->Bgs]: cURL SSL call with client cert fails if within a class
Edit report at https://bugs.php.net/bug.php?id=52513&edit=1 ID: 52513 Updated by: bj...@php.net Reported by:diego_gullo at bizmate dot biz Summary:cURL SSL call with client cert fails if within a class -Status: Open +Status: Bogus Type: Bug Package:cURL related Operating System: Linux version 2.6.16-xenU PHP Version:5.2.14 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. It works fine. I am guessing your class is in a different dir when you are trying this, hence not actually referecing the correct file. Use full path. Previous Comments: [2010-08-02 11:28:56] diego_gullo at bizmate dot biz Description: When using cURL to send an HTTP post through a SSL connection that required a client certificate it works fine if run straight from the script, outside a class. However when the same code is executed from within a class for some reason I get a private key error that makes no sense since the certificate, private key, password and all the cURL options used to connect are executed exactly the same way with references to the same files. Exact version of PHP is 5.2.11 curl->libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 compile line './configure' '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '-- target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec- prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '-- datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '-- libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '-- mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache- file=../config.cache' '--with-libdir=lib' '--with-config-file-path=/etc' '-- with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable- rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '- -with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '-- without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg- dir=/usr' '--with-openssl' '--with-png' '--with-expat-dir=/usr' '--with-pcre- regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '-- enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '- -enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '-- enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with- unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable- calendar' '--enable-dbx' '--enable-dio' '--without-mime-magic' '--without- sqlite' '--with-libxml-dir=/usr' '--with-xml' '--with-system-tzdata' '--enable- force-cgi-redirect' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '-- enable-mbstring=shared' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with- ncurses=shared' '--with-gd=shared' '--enable-bcmath=shared' '--enable- dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' '-- with-ldap-sasl' '--with-mysql=shared,/usr' '--with- mysqli=shared,/usr/bin/mysql_config' '--enable-dom=shared' '--with-dom- xslt=/usr' '--with-dom-exslt=/usr' '--with-pgsql=shared' '--with- snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' '--enable- xmlreader=shared' '--enable-xmlwriter=shared' '--enable-fastcgi' '--enable- pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo- mysql=shared,/usr' '--with-pdo-pgsql=shared,/usr' '--with-pdo- sqlite=shared,/usr' '--enable-json=shared' '--enable-zip=shared' '--with- readline' '--enable-dbase=shared' '--with-pspell=shared' '--with- mcrypt=shared,/usr' '--with-mhash=shared,/usr' '--with-tidy=shared,/usr' '-- with-mssql=shared,/usr' Test script: --- i have created two short files that show the difference in usage that is the only difference i can see, available at http://bizmatebiz.dreamhosters.com/curl_bug_bizmate.zip Expected result: response from the API whose endpoint is specified in the script Actual result: -- Error: unable to set private key file: '/home/USER/certs/my.pem' type PEM bool(false) -- Edit this bug report at https://bugs.php.net/bug.php?id=52513&edit=1
Bug #48203 [Asn->Csd]: crash when CURLOPT_STDERR is set to regular file
Edit report at https://bugs.php.net/bug.php?id=48203&edit=1 ID: 48203 Updated by: bj...@php.net Reported by:php-bug at paulsohier dot nl Summary:crash when CURLOPT_STDERR is set to regular file -Status: Assigned +Status: Closed Type: Bug Package:cURL related Operating System: * PHP Version:5.*, 6CVS (2009-05-09) Assigned To:bjori Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed with bug#54798 Previous Comments: [2011-06-09 09:31:15] sh...@php.net The following patch has been added/updated: Patch Name: reset_to_default_with_multi.patch.txt Revision: 1307604675 URL: http://bugs.php.net/patch-display.php?bug=48203&patch=reset_to_default_with_multi.patch.txt&revision=1307604675 [2011-06-09 09:30:05] sh...@php.net Added patch for updated tests (tests were commited here http://news.php.net/php.cvs/65161). See also discussion here: http://markmail.org/message/dfjgty27qfhj4ulf [2011-06-09 09:16:16] sh...@php.net Automatic comment from SVN on behalf of shein Revision: http://svn.php.net/viewvc/?view=revision&revision=311959 Log: Updated (currently failing) test for bug48203 with curl_stderr and added also curl_multi_exec variant of this test. [2009-05-26 17:16:53] j...@php.net 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. [2009-05-26 12:34:48] j...@php.net This fixes all the test cases I could come up with: http://pecl.php.net/~jani/patches/bug48203.patch Even the quite insane ones too. It falls back to using STDERR which is the default anyway if the file pointer is closed prematurely. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48203 -- Edit this bug report at https://bugs.php.net/bug.php?id=48203&edit=1
Bug #54798 [Asn->Csd]: Segfault when CURLOPT_STDERR file pointer is closed before calling curl_exec
Edit report at https://bugs.php.net/bug.php?id=54798&edit=1
ID: 54798
Updated by: bj...@php.net
Reported by:sh...@php.net
Summary:Segfault when CURLOPT_STDERR file pointer is closed
before calling curl_exec
-Status: Assigned
+Status: Closed
Type: Bug
Package:cURL related
Operating System: Ubuntu Linux 11.04 x86
PHP Version:trunk-SVN-2011-05-17 (SVN)
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-09-08 14:37:05] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=316417
Log: Fixed bug#54798Segfault when CURLOPT_STDERR file pointer is closed
before calling curl_exec
[2011-05-17 16:25:32] sh...@php.net
Description:
Related to http://bugs.php.net/bug.php?id=48203
Curl crashes when CURLOPT_STDERR file pointer is closed before calling
curl_exec(), i.e.
$fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w');
$ch = curl_init();
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_STDERR, $fp);
curl_setopt($ch, CURLOPT_URL, getenv("PHP_CURL_HTTP_REMOTE_SERVER"));
fclose($fp); // <-- premature close of $fp caused a crash!
curl_exec($ch); // segfault
Error is reproduced on latest svn php5.3, php5.4 and trunk
Fix is also attached here.
Test script:
---
Full test script is available here:
http://svn.php.net/viewvc/php/php-src/trunk/ext/curl/tests/bug48203.phpt?view=markup
Expected result:
No segfault, see test script
Actual result:
--
Segfault
--
Edit this bug report at https://bugs.php.net/bug.php?id=54798&edit=1
Bug #55469 [Asn->Wfx]: phpinfo: Wrong licensetext display
Edit report at https://bugs.php.net/bug.php?id=55469&edit=1 ID: 55469 Updated by: bj...@php.net Reported by:virsacer at web dot de Summary:phpinfo: Wrong licensetext display -Status: Assigned +Status: Wont fix Type: Bug Package:PHP options/info functions PHP Version:trunk-SVN-2011-08-20 (snap) Assigned To:kalle Block user comment: N Private report: N New Comment: Thats fully intentional as it doesn't use bsd style license. Previous Comments: [2011-08-22 13:57:04] ka...@php.net I'll take this one and commit the patches after 5.3.8 have been packaged, so it will be included in 5.3.9. [2011-08-20 20:07:42] virsacer at web dot de Description: mbstring uses a "table header" instead of a "box" (like all others) to display it's license information -- Edit this bug report at https://bugs.php.net/bug.php?id=55469&edit=1
Bug #55479 [Opn]: ext/pcntl/tests failures
Edit report at https://bugs.php.net/bug.php?id=55479&edit=1
ID: 55479
Updated by: bj...@php.net
Reported by:glen at delfi dot ee
Summary:ext/pcntl/tests failures
Status: Open
Type: Bug
Package:PCNTL related
PHP Version:5.4.0alpha3
Block user comment: N
Private report: N
New Comment:
That seems like a bad workaround which would need to be repeated in many places.
run-tests maybe could export an environment variable which contained proper
execute command..?
Previous Comments:
[2011-08-27 14:42:56] glen at delfi dot ee
i.e to be independant of php version installed in system while running tests,
the
following args need to be told when invoking php cli inside each .phpt:
$args = array("-n", "-d$extension_dir", "-c$inipath", ...);
where $extension_dir is ./modules and $inipath ./php-temp.ini, without doing so
it would read /usr/lib/php for $extension_dir and /etc/php/php.ini for $inipath
[2011-08-27 14:37:43] glen at delfi dot ee
err, i know all that
the bug is that "make test" is using modules from to-be-installed path, where
could be installed other version of php
so the patch is to enforce currently built version of php config and modules of
php-cli that is invoked from tests itself
"make test" itself already does the php invocation properly, but invoking
$PHP_TEST_EXECUTABLE from tests should do the same.
i've included patch for two tests i saw failing. i would proceed in other exts
if i see interest in that.
is it clear what i'm saying here? maybe just look at the patch as patch says
more than i'm able to explain.
[2011-08-26 15:22:04] ka...@php.net
>From the trace it looks like you are using some old dynamically linked
>libraries thats compiled to a different version that the one you are using
>(see the APINO).
Packages like PCRE and SPL should be statically compiled anyway, although I
don't reckon we have any issues using dynamically loaded ones.
[2011-08-22 17:05:56] glen at delfi dot ee
proposed patch:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-test-pcntl-
55479.patch
[2011-08-22 17:03:56] glen at delfi dot ee
Description:
there are ext/pcntl/tests failures due it using $TEST_PHP_EXECUTABLE which uses
installed php
config, but tests should be self-contained and use config extensions from BUILT
codebase.
for example if i have installed php 5.3 and i try to run tests on 5.4 i get
errors:
+ /usr/bin/make -j16 test EXTENSION_DIR=modules
PHP_TEST_SHARED_SYSTEM_EXTENSIONS=
RUN_TESTS_SETTINGS=-q ext/pcntl/tests/pcntl_exec_2.phpt --show-out
Build complete.
Don't forget to run 'make test'.
=
PHP :
/home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 5.4.0alpha3
ZEND_VERSION: 2.4.0
PHP_OS : Linux - Linux carme-pld-i686 3.0.0_nogrsecurity-0.3 #1 SMP Wed
Jul
27 21:17:15 CEST
2011 i686
INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/tmp-php.ini
More .INIs :
CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3
Extra dirs :
VALGRIND: Not used
=
Running selected tests.
TEST 1/1 [ext/pcntl/tests/pcntl_exec_2.phpt]
OUT
ok
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/pcre.so'
-
/usr/lib/php/pcre.so: undefined symbol: php_addslashes_ex in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/spl.so'
-
/usr/lib/php/spl.so: undefined symbol: php_pcre_replace_impl in Unknown on line
0
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/session.so' -
/usr/lib/php/session.so: undefined symbol: php_get_output_start_filename in
Unknown on line 0
PHP Warning: PHP Startup: bcmath: Unable to initialize module
Module compiled with module API=20090626
PHPcompiled with module API=20100525
These options need to match
in Unknown on line 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=55479&edit=1
Req #48080 [Opn]: Add support for forcing DOM to validate a DOMDocument with a DTD
Edit report at https://bugs.php.net/bug.php?id=48080&edit=1 ID: 48080 Updated by: bj...@php.net Reported by:jose dot rob dot jr at gmail dot com Summary:Add support for forcing DOM to validate a DOMDocument with a DTD Status: Open Type: Feature/Change Request Package:DOM XML related PHP Version:5.2.9 -Assigned To: +Assigned To:cataphract Block user comment: N Private report: N New Comment: Gustavo; So this is fixed? Previous Comments: [2011-08-29 05:08:32] cataphr...@php.net Added libxml_set_external_entity_loader() in PHP 5.4/trunk, which also solves this problem. [2010-10-31 12:49:50] php at example dot com It should also be noted that this affects any DOMDocuments using the standard XHTML SystemIDs. The W3C decided to block all requests to their URIs. See http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic [2009-04-26 17:17:38] jose dot rob dot jr at gmail dot com Description: I need to validate XML files before loading them, then I created a DTD and hosted it. With python I can distribute the DTD file with the program and validate the XML file locally. A python example: --- from lxml import etree from StringIO import StringIO xmlstart=""" http://example.com/mydtd.dtd'>""" xmlok=xmlstart+"The XML file"; xmlinvalid=xmlstart+"testThe XML file"; dtddata=""; f=StringIO(dtddata); dtd=etree.DTD(f); print "Valid XML:"; xml1=etree.XML(xmlok); validation=dtd.validate(xml1); print validation; print dtd.error_log.filter_from_errors(); print "Invalid XML:"; xml2=etree.XML(xmlinvalid); validation=dtd.validate(xml2); print validation; print dtd.error_log.filter_from_errors(); The only way I find to port this stript is using DOMDocument::validate() but this method will get the DTD from http://example.com/mydtd.dtd and be slower, generate traffic, and fail when example.com is off-line... I suggest adding an attribute like DOMDocument::validate($source) where $source is a string with DTD source to avoid situations like this... Reproduce code: --- http://example.com/mydtd.dtd'> XML; $xmlok=$xmlstart."The XML file"; $xmlinvalid=$xmlstart."testThe XML file"; $dtddata=""; print "Valid XML:"; $xml1=DOMDocument::loadXML($xmlok); $validation=(int)$xml1->validate($dtddata); //Example that would work print "$validation"; print "Invalid XML:"; $xml1=DOMDocument::loadXML($xmlinvalid); $validation=(int)$xml1->validate($dtddata); //Example that would work print "$validation"; ?> Expected result: Valid XML: 1 Invalid XML: Warning: DOMDocument::validate() [function.DOMDocument-validate]: Element example was declared #PCDATA but contains non text nodes in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: No declaration for element a in /script/path/xml.php on line 19 0 Actual result: -- When no argument is passed to validate and DTD server is off-line: Valid XML: Warning: DOMDocument::validate(http://example.com/mydtd.dtd) [function.DOMDocument-validate]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /script/path/xml.php on line 14 Warning: DOMDocument::validate() [function.DOMDocument-validate]: I/O warning : failed to load external entity "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 14 Warning: DOMDocument::validate() [function.DOMDocument-validate]: Could not load the external subset "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 14 0 Invalid XML: Warning: DOMDocument::validate(http://example.com/mydtd.dtd) [function.DOMDocument-validate]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: I/O warning : failed to load external entity "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: Could not load the external subset "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 19 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=48080&edit=1
Bug #55504 [Asn->Csd]: Content-Type header is not parsed correctly on HTTP POST request
Edit report at https://bugs.php.net/bug.php?id=55504&edit=1
ID: 55504
Updated by: bj...@php.net
Reported by:mumu at seznam dot cz
Summary:Content-Type header is not parsed correctly on HTTP
POST request
-Status: Assigned
+Status: Closed
Type: Bug
Package:Unknown/Other Function
Operating System: FreeBSD, Windows Server 2008
PHP Version:5.3.8
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-09-07 16:18:56] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=316373
Log: Fixed bug #55504 (Content-Type header is not parsed correctly on HTTP POST
request
[2011-08-26 07:15:35] mumu at seznam dot cz
The test call in the original comment is not correct. It should state:
Content-Type: multipart/form-data; boundary=BVoyv; charset=iso-8859-1
Accept: */*
Content-Length: 72
Host: example.com
--BVoyv
Content-Disposition: form-data; name="data"
abc
--BVoyv--
[2011-08-25 06:18:07] mumu at seznam dot cz
Description:
HTTP POST is not parsed correctly when the "boundary" parameter of the
Content-Type HTTP header is not the last parameter on the line.
---
Guessing (might be wrong):
In the first case, PHP parses the ";" (and maybe also the rest of the line)
after the boundary still as part of the boundary value. As a result, the POST
DATA are not "understood" correctly. However, the following parts from RFC 1521
states clearly that ";" could not be part of the boundary:
tspecials := "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
boundary := 0*69 bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace :=DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
Test script:
---
Consider the following call to a PHP script running on an Apache server.
Connection: Keep-Alive
Content-Type: multipart/form-data; boundary=BVoyv; charset=iso-8859-1
Accept: */*
Content-Length: 72
Host: example.com
Content-Disposition: form-data; name="data"
abc
--BVoyv--
And a corresponding PHP script:
In this case, the POST data are not seen on the PHP side, as shown on the
output:
Array
(
[Connection] => Keep-Alive
[Content-Type] => multipart/form-data; boundary=BVoyv; charset=iso-8859-1
[Accept] => */*
[Content-Length] => 72
[Host] => example.com
)
Array
(
)
However, after changing order of parameters in the Content-Type header to:
"Content-Type: multipart/form-data; charset=iso-8859-1; boundary=BVoyv"
the script output is as expected (notify appearing of the [data] line):
Array
(
[Connection] => Keep-Alive
[Content-Type] => multipart/form-data; charset=iso-8859-1; boundary=BVoyv
[Accept] => */*
[Content-Length] => 72
[Host] => example.com
)
Array
(
[data] => abc
)
Expected result:
Both cases should be equal to each other.
Actual result:
--
In the first case, the "data" parameter is not available to the script.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55504&edit=1
Req #54450 [Asn->Csd]: Missing functions with libedit
Edit report at https://bugs.php.net/bug.php?id=54450&edit=1
ID: 54450
Updated by: bj...@php.net
Reported by:fedora at famillecollet dot com
Summary:Missing functions with libedit
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
Package:Readline related
Operating System: GNU/Linux (Fedora 14)
PHP Version:5.3.6
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-09-06 15:07:11] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=316265
Log: Fixed bug#54450 (callback function when built against libedit)
[2011-04-02 09:34:40] fedora at famillecollet dot com
Description:
libedit (tested with version 3.0) provides "callback" functions, but php
doesn't detects/provides them.
The attached patched
- add detection for "rl_callback_read_char" when build with "--with-readline"
- add detection for "rl_on_new_line" which is only available when build
"--with-readline"
Exemple from http://www.php.net/readline_callback_handler_install works.
Test script:
---
php -r 'print_r(get_extension_funcs("readline"));'
Expected result:
Array
(
[0] => readline
[1] => readline_info
[2] => readline_add_history
[3] => readline_clear_history
[4] => readline_read_history
[5] => readline_write_history
[6] => readline_completion_function
[7] => readline_callback_handler_install
[8] => readline_callback_read_char
[9] => readline_callback_handler_remove
[10] => readline_redisplay
)
Actual result:
--
Array
(
[0] => readline
[1] => readline_info
[2] => readline_add_history
[3] => readline_clear_history
[4] => readline_read_history
[5] => readline_write_history
[6] => readline_completion_function
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=54450&edit=1
Bug #55555 [Opn]: readlink() behaviour changed
Edit report at https://bugs.php.net/bug.php?id=5&edit=1 ID: 5 Updated by: bj...@php.net Reported by:datib...@php.net Summary:readlink() behaviour changed Status: Open Type: Bug Package:Filesystem function related Operating System: Linux 2.6.39+ PHP Version:5.4SVN-2011-08-31 (SVN) -Assigned To: +Assigned To:datibbaw Block user comment: N Private report: N New Comment: You've got tests karma now, commit it yourself. Previous Comments: [2011-08-31 16:38:40] datib...@php.net Added bug5.v1.phpt.patch to fix ext/standard/tests/file/readlink_variation1.phpt [2011-08-31 16:37:57] datib...@php.net The following patch has been added/updated: Patch Name: bug5.v1.phpt.patch Revision: 1314808677 URL: https://bugs.php.net/patch-display.php?bug=5&patch=bug5.v1.phpt.patch&revision=1314808677 [2011-08-31 16:25:32] datib...@php.net The following patch has been added/updated: Patch Name: bug5.phpt.patch Revision: 1314807932 URL: https://bugs.php.net/patch-display.php?bug=5&patch=bug5.phpt.patch&revision=1314807932 [2011-08-31 16:16:50] datib...@php.net Added a patch that should cleanly apply on PHP_5_4 [2011-08-31 16:16:22] datib...@php.net The following patch has been added/updated: Patch Name: bug5.patch Revision: 1314807382 URL: https://bugs.php.net/patch-display.php?bug=5&patch=bug5.patch&revision=1314807382 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=5 -- Edit this bug report at https://bugs.php.net/bug.php?id=5&edit=1
Bug #55101 [Opn]: Reflection tries to find symlink() and readlink() when they don't exist
Edit report at https://bugs.php.net/bug.php?id=55101&edit=1 ID: 55101 Updated by: bj...@php.net Reported by:vr...@php.net Summary:Reflection tries to find symlink() and readlink() when they don't exist Status: Open Type: Bug Package:Reflection related Operating System: Windows XP PHP Version:5.4.0alpha1 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N New Comment: I don't have a Windows build environment.. but I believe the attached patch fixes this issue, and makes more sense :] Could you verify it for me Pierre? Previous Comments: [2011-08-30 13:13:53] bj...@php.net The following patch has been added/updated: Patch Name: disable-functions.patch Revision: 1314710033 URL: https://bugs.php.net/patch-display.php?bug=55101&patch=disable-functions.patch&revision=1314710033 [2011-07-01 18:43:44] fel...@php.net This specific windows disabling stuff is done at http://lxr.php.net/xref/PHP_5_4/main/main.c#php_win32_disable_functions but I think it might be handled like we treat the disable_functions INI entry at http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#disabled_function [2011-07-01 09:40:48] vr...@php.net I've looked in the source codes but I didn't get a clue how is it achieved that readlink() is disabled on Windows < Vista. I also don't see anything related at http://lxr.php.net/search?project=PHP_5_4&refs=readlink [2011-07-01 09:19:47] paj...@php.net It certainly does something nasty, can you try to figure out where pls? [2011-07-01 09:07:36] vr...@php.net I know, it is even mentioned in the bug report. The problem is that Reflection doesn't know it and produces an Internal error. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55101 -- Edit this bug report at https://bugs.php.net/bug.php?id=55101&edit=1
Bug #51588 [Opn->Fbk]: calling zend_parse_ini_string/file recursively core dump
Edit report at https://bugs.php.net/bug.php?id=51588&edit=1
ID: 51588
Updated by: bj...@php.net
Reported by:f...@php.net
Summary:calling zend_parse_ini_string/file recursively core
dump
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: any
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
Any particular reason you haven't committed this yet?
Previous Comments:
[2010-04-18 12:29:13] f...@php.net
The following patch has been added/updated:
Patch Name: zend_ini_parser.y.patch
Revision: 1271586553
URL:
http://bugs.php.net/patch-display.php?bug=51588&patch=zend_ini_parser.y.patch&revision=1271586553
[2010-04-18 12:28:33] f...@php.net
Description:
when zend_parse_ini_string or zend_parse_ini_file is called recursively, it
crashes. The lexical state variable is global, calling those function
recursively
overwrites previous version and crashes at liberation/destruction.
to prevent this behaviour, the following patch makes zend_parse_ini_string or
zend_parse_ini_file returning an error when called recursively.
Test script:
---
void fpm_conf_ini_load_file(filename);
static void fpm_conf_ini_parser(zval *arg1, zval *arg2, zval *arg3,
int callback_type, void *arg TSRMLS_DC) {
if (!arg1) return;
if (callback_type != ZEND_INI_PARSER_ENTRY) return;
if (!strcmp(Z_STRVAL_P(arg1), "include")) {
fpm_conf_load_ini_file(Z_STRVAL_P(arg1));
}
}
void fpm_conf_ini_load_file(filename) {
zend_file_handle fh;
fh.handle.fp = VCWD_FOPEN(filename, "r");
fh.opened_path = NULL;
fh.free_filename = 0;
fh.filename = filename;
Z_TYPE(fh) = ZEND_HANDLE_FP;
zend_parse_ini_file(&fh, 1, ZEND_INI_SCANNER_RAW,
(zend_ini_parser_cb_t)fpm_conf_ini_parser, NULL TSRMLS_CC);
}
Expected result:
it doesn't crash, it works or returns an error
Actual result:
--
core dump
#0 _zend_mm_free_int (heap=0x8271c000, p=0x8271c000) at /LIBRE/dev/php-
5.3.2/Zend/zend_alloc.c:2018
#1 0x1c23154a in _efree (ptr=0x7d3fe1f8) at /LIBRE/dev/php-
5.3.2/Zend/zend_alloc.c:2351
#2 0x1c245b5b in zend_stack_destroy (stack=0x3c2c2804) at /LIBRE/dev/php-
5.3.2/Zend/zend_stack.c:104
#3 0x1c22bd1c in shutdown_ini_scanner () at zend_ini_scanner.l:201
#4 0x1c22b035 in zend_parse_ini_file (fh=0xcfbd3c70, unbuffered_errors=1
'\001', scanner_mode=0, ini_parser_cb=0x8271c000, arg=0x8271c000) at
/LIBRE/dev/php-5.3.2/Zend/zend_ini_parser.c:322
#5 0x1c2aefa8 in fpm_conf_load_ini_file (filename=0xcfbd602e "/usr/local/php-
5.3.2/etc/fpm.ini") at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm_conf.c:739
#6 0x1c2af002 in fpm_conf_load_ini_file (filename=0xcfbd602e "/usr/local/php-
5.3.2/etc/fpm.ini") at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm_conf.c:751
#7 0x1c2ad489 in fpm_init (argc=-2106474496, argv=0x8271c000,
config=0x8271c000
"\001", base=0x3c2bf81c) at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm.c:32
#8 0x1c2b14ff in main (argc=3, argv=0xcfbd5eac) at /LIBRE/dev/php-
5.3.2/sapi/fpm/fpm/fpm_main.c:1695
--
Edit this bug report at https://bugs.php.net/bug.php?id=51588&edit=1
Bug #54601 [Asn->Csd]: Removing the doctype node segfaults
Edit report at https://bugs.php.net/bug.php?id=54601&edit=1 ID: 54601 Updated by: bj...@php.net Reported by:hannes dot magnusson at gmail dot com Summary:Removing the doctype node segfaults -Status: Assigned +Status: Closed Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.3SVN-2011-04-25 (SVN) Assigned To:rrichards Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. think its safe to close this one now :) Previous Comments: [2011-06-02 20:38:38] hannes dot magnusson at gmail dot com I've already committed the patch, but Richard believed there could maybe be other issues - hence leaving the report open until he can verify the fix properly. [2011-06-02 20:06:16] il...@php.net With latest SVN on Linux I am unable to reproduce the crash. Can you still reproduce it? [2011-05-29 13:39:51] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=311544 Log: Fixed bug #54601 (Removing the doctype node segfaults) [2011-04-25 23:14:37] bj...@php.net The attached patch does seem to fix the issue and makes valgrind stop bleeding.. If it is however proper, I don't know :) [2011-04-25 13:07:40] bj...@php.net Another one from phpdoc :) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54601 -- Edit this bug report at https://bugs.php.net/bug.php?id=54601&edit=1
Bug #48476 [Asn->Csd]: cloning extended DateTime class without calling parent::__constr crashed PHP
Edit report at https://bugs.php.net/bug.php?id=48476&edit=1
ID: 48476
Updated by: bj...@php.net
Reported by:rvanvelzen at expert-shops dot com
Summary:cloning extended DateTime class without calling
parent::__constr crashed PHP
-Status: Assigned
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: CentOS 5.2
PHP Version:5.2.9
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-08-30 13:41:47] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=315779
Log: Fixed bug#48476
[2011-07-19 03:18:18] jasper at nerdsweide dot nl
This bug still exists in PHP 5.3.6:
-
class ExtendedDateTime extends DateTime
{}
$date1 = new ExtendedDateTime();
$date2 = clone $date1; // <= ok!
-
class ExtendedDateTime extends DateTime
{
public function __construct( $time = 'now', DateTimeZone $timezone = null )
{
parent::__construct( $time, $timezone );
}
}
$date1 = new ExtendedDateTime();
$date2 = clone $date1; // <= ok!
-
class ExtendedDateTime extends DateTime
{
public function __construct( $time = 'now', DateTimeZone $timezone = null )
{
}
}
$date1 = new ExtendedDateTime();
$date2 = clone $date1; // <= php crashes
-
In the apache2 error_log I find:
[notice] child pid 63203 exit signal Bus error (10)
Another note, when I implement a __clone method, it is called and run without
problems:
-
class ExtendedDateTime extends DateTime
{
public function __construct( $time = 'now', DateTimeZone $timezone = null )
{
}
public function __clone()
{
var_dump( 'Am I run?' );
exit;
}
}
Outputs:
object(ExtendedDateTime)[345]
string 'Am I run?' (length=9)
-
What's even more unexpected is that the constructor has some effect on the
language construct 'clone'. As far as I know the constructor isn't used when
cloning an object.
The case I'm using is an extend of DateTime which wraps around an original
DateTime. I've worded around this bug by implementing a 'copy' method:
-
class ExtendedDateTime extends DateTime
{
protected $_datetime;
public function __construct( $time = 'now', DateTimeZone $timezone = null )
{
$this->_datetime = new DateTime( $time, $timezone );
}
public function copy()
{
$copy = unserialize( 'O:9:"F500_Date":0:{}' );
$copy->_datetime = clone $this->_datetime;
return $copy;
}
}
This works fine, but I'd like to be able to use the 'clone' language construct
;)
System: Mac OS X 10.5.8 (9L31a)
Kernel: Darwin 9.8.0
Apache: Apache/2.2.19 (Unix)
PHP:5.3.6 (Zend Engine v2.3.0 with Xdebug v2.1.1)
[2009-06-05 09:29:05] rvanvelzen at expert-shops dot com
Description:
When trying to clone an extended class of DateTime of which the constructor
doesn't call parent::__construct, this causes PHP to die.
Reproduce code:
---
Expected result:
object(MyDateTime)#2 (0) {
}
Actual result:
--
Nothing, PHP crashes
--
Edit this bug report at https://bugs.php.net/bug.php?id=48476&edit=1
Bug #53391 [Opn->Bgs]: Scalar type hint reflection method name inconsistency
Edit report at https://bugs.php.net/bug.php?id=53391&edit=1 ID: 53391 Updated by: bj...@php.net Reported by:seva dot lapsha at gmail dot com Summary:Scalar type hint reflection method name inconsistency -Status: Open +Status: Bogus Type: Bug Package:Reflection related PHP Version:trunk-SVN-2010-11-23 (SVN) Block user comment: N Private report: N New Comment: Scalar type hints got removed Previous Comments: [2010-11-23 20:52:05] seva dot lapsha at gmail dot com Description: Scalar type hint implementation introduces inconsistency in type naming. The canonic name for float/double/real is float. But the introduced method for them is ::isDouble(). @see http://php.net/manual/en/language.types.float.php @see http://php.net/manual/en/function.is-float.php @see http://php.net/manual/en/function.is-double.php (alias) @see http://php.net/manual/en/function.is-real.php (alias) @see http://php.net/manual/en/function.floatval.php @see http://php.net/manual/en/function.doubleval.php (alias) @see http://php.net/manual/en/class.splfloat.php -- Edit this bug report at https://bugs.php.net/bug.php?id=53391&edit=1
Bug #49294 [Asn->Csd]: ReflectionExtension::info() returns null
Edit report at https://bugs.php.net/bug.php?id=49294&edit=1
ID: 49294
Updated by: bj...@php.net
Reported by:andreww at uk dot ibm dot com
Summary:ReflectionExtension::info() returns null
-Status: Assigned
+Status: Closed
Type: Bug
Package:Reflection related
Operating System: *
PHP Version:5.*, 6 (2009-08-20)
Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
fixed in the docs.
Previous Comments:
[2011-08-30 12:54:26] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=315777
Log: Fixed bug#49294 (ReflectionExtension::info doesn't return the info)
[2010-05-28 04:43:25] ka...@php.net
Just FYI, my patch only contains the local value, not the master value. But in
the end we can always alter the info() method to return a multi dim. array like:
php.ini:
apc.cache_by_default = 0;
Test script:
ini_set('apc.cache_by_default', '1');
$extension = new ReflectionExtension('apc');
$info = $extension->info();
printf('[local=%s] [master=%s]', $info['ini']['apc.cache_by_default']['local'],
$info['ini']['apc.cache_by_default']['master']);
Would print:
[local=1] [master=0]
[2010-05-28 04:34:13] ka...@php.net
I added a simple patch that alters ReflectionExtension::info() to have a new
optional parameter to return the information as an array. If it even makes
sense, since the information here can already be retrieved by the getName(),
getVersion() and getINIEntries() methods.
Johannes can you please review this and approve or reject it
[2010-05-28 04:31:09] ka...@php.net
The following patch has been added/updated:
Patch Name: bug-49294
Revision: 1275013869
URL:
http://bugs.php.net/patch-display.php?bug=49294&patch=bug-49294&revision=1275013869
[2009-08-20 10:37:05] j...@php.net
Assigned to Johannes who added this method. Seems quite weird that there's one
single method that just outputs stuff instead of returning it. Not very
consistent.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=49294
--
Edit this bug report at https://bugs.php.net/bug.php?id=49294&edit=1
Bug #53328 [Opn->Bgs]: copy() returns false even if closing the destination file fails
Edit report at https://bugs.php.net/bug.php?id=53328&edit=1 ID: 53328 Updated by: bj...@php.net Reported by:mike at silverorange dot com Summary:copy() returns false even if closing the destination file fails -Status: Open +Status: Bogus Type: Bug Package:Streams related Operating System: Linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The php-src internal copy() function discards the flush operation, even using its native wrappers. If you consider it an issue, you should enforce flushing in your wrapper yourself. Previous Comments: [2010-11-18 17:37:12] mike at silverorange dot com fflush does correctly return false, but the point of stream wrappers is to be able to use the stream functions as I normally would. I normally use copy to copy a stream rather than an fopen, fread, fwrite, fflush, fclose loop. Because of this bug, there's no way to properly detect errors when copying to custom streams. In practice, this results in data loss. I'm fine with the fix going in trunk as afaik php 5.2.x is reaching end of life and this is not a security issue. [2010-11-18 07:52:21] cataphr...@php.net The function you should be testing would be fflush, not copy. fflush does actually return false. The flush operation is called for collaterals when closing the file. copy() should probably return false if closing, at least, the destination file fails, but it's a risky move because in PHP, for better or worse, the return value of php_stream_close and friends is almost always ignored. We'd be giving significance to something that's almost always ignored. Maybe for trunk... [2010-11-17 16:36:47] mike at silverorange dot com Till, thanks for making the phpt file. I tested using the phpt and the raw PHP file, and both fail as described in the original bug report. This is using php 5.3.3 as provided by Ubuntu. I don't see the directory error you describe. [2010-11-17 15:43:14] t...@php.net Hey Mike, I wanted to write a test case but I fail to reproduce this on 5.3.2 so far. E.g., I wrapped your code into a phpt, all I get is: Warning: copy(): The second argument to copy() function cannot be a directory in /home/till/test/bug53328.php on line 60 bool(false) [ On a sidenote, I don't get this error message either. 'foo' is not a directory, but maybe this means that we have to implement more in the example wrapper for it to work, or this is another bug in the streamwrapper?] Anyway, aside from the weird error message it seems to work indeed on 5.3.2. Here is your code wrapped in a phpt: http://friendpaste.com/7Id22SbWNEBnwLhi9FnSTu Execute with: pear run-tests bug53328.phpt [2010-11-17 06:48:23] mike at silverorange dot com Description: In a custom stream wrapper if stream_flush() returns false as the documentation says it may, parent copy operations do not return false. Test script: --- http://labs.silverorange.com/files/php-stream-wrapper/test.phps http://labs.silverorange.com/files/php-stream-wrapper/test.txt Expected result: copy should return false. Actual result: -- copy returns true. -- Edit this bug report at https://bugs.php.net/bug.php?id=53328&edit=1
Bug #48280 [Opn->Bgs]: http stream timeout is doubled
Edit report at https://bugs.php.net/bug.php?id=48280&edit=1
ID: 48280
Updated by: bj...@php.net
Reported by:php at bouchery dot fr
Summary:http stream timeout is doubled
-Status: Open
+Status: Bogus
Type: Bug
Package:Streams related
Operating System: Windows XP SP2
PHP Version:5.2SVN-2009-12-22
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
the value is used both for connection timeout, and then again for read timeout.
Previous Comments:
[2011-05-05 15:35:24] james dot mk dot green at gmail dot com
This remains a bug in 5.3.5 on Linux. Setting the timeout to 2 results in a 4s
timeout, setting it to 4 results in an 8s timeout.
[2009-12-22 10:51:29] php at bouchery dot fr
No, result is already :
Code #1: Duration = 4
Code #2: Duration = 6
Code #3: Duration = 8
[2009-05-20 13:29:13] php at bouchery dot fr
I did it on localhost and on a remote machine:
sleep-flush.php
sleep.php
[2009-05-20 12:59:15] j...@php.net
And where are the sources for those server side scripts?
[2009-05-14 11:59:39] php at bouchery dot fr
Description:
When I perform a HTTP timeout using "stream_context_create",
"stream_set_timeout" or "default_socket_timeout", timeout is doubled.
I did it on :
- Windows XP SP2 + PHP-Cli 5.1.6
- Windows XP SP2 + PHP-Cli 5.2.9-2
- Debian 5 + PHP 5.2.0-8+etch13 (cli)
Reproduce code:
---
http://localhost/sleep-flush.php', 'r');
if( $f !== false ) {
stream_set_timeout($f, 2);
$content = stream_get_contents( $f );
fclose($f);
}
echo 'Code #1: Duration = ', (time() - $time), "\n";
$context = stream_context_create(array('http' => array('timeout' => 3)));
$time = time();
// sleep do not flush text before sleeping 20 seconds
$f = @fopen('http://localhost/sleep.php', 'r', false, $context);
if( $f !== false ) {
$content = stream_get_contents( $f );
fclose($f);
}
echo 'Code #2: Duration = ', (time() - $time), "\n";
ini_set('default_socket_timeout', '4');
$time = time();
// sleep do not flush text before sleeping 20 seconds
$f = @fopen('http://localhost/sleep.php', 'r');
if( $f !== false ) {
$content = stream_get_contents( $f );
fclose($f);
}
echo 'Code #3: Duration = ', (time() - $time), "\n";
?>
Expected result:
Code #1: Duration = 2
Code #2: Duration = 3
Code #3: Duration = 4
Actual result:
--
Code #1: Duration = 4
Code #2: Duration = 6
Code #3: Duration = 8
--
Edit this bug report at https://bugs.php.net/bug.php?id=48280&edit=1
Bug #37096 [Opn->Bgs]: referencing bug with return value for stream_seek
Edit report at https://bugs.php.net/bug.php?id=37096&edit=1
ID: 37096
Updated by: bj...@php.net
Reported by:w...@php.net
Summary:referencing bug with return value for stream_seek
-Status: Open
+Status: Bogus
Type: Bug
Package:Streams related
Operating System: *
PHP Version:5CVS-2006-04-16 (CVS)
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
I can't reproduce this.
If you are still able to produce this, please provide a proper full reproduce
script
Previous Comments:
[2006-09-16 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2006-09-08 21:04:46] tony2...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-07-26 09:21:28] tendencies at free dot fr
See this bug : http://bugs.php.net/bug.php?id=30157
[2006-04-16 02:29:02] w...@php.net
Description:
When using user-space streams via stream_wrapper_register(),
if you return the value of a property of the object from stream_seek(), it gets
mangled.
Sounds like a problem with the way that the retval from call_user_function_ex()
is disposed.
The workaround is to create a temporary value using a trick like this:
function stream_seek($offset, $whence) {
...
$retval = $this->pos + 0;
return $retval;
}
presumably the rest of the user wrapper code has the same flaw.
Reproduce code:
---
Abbreviated example; my actual test case is too large.
Valgrind does not indicate any memory errors, so the problem is likely logical
rather than sloppy memory handling.
class MyStream {
var $this->pos = 0;
function stream_tell() {
return $this->pos;
}
function stream_seek($offset, $whence) {
return $this->pos;
}
}
Actual result:
--
Problem manifested for me by converting $this->pos to bool(true), which was
then interpreted by the user space wrapper as an invalid return value from
stream_tell(), which simply returns $this->pos.
--
Edit this bug report at https://bugs.php.net/bug.php?id=37096&edit=1
Bug #30157 [Tbd->Csd]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157&edit=1 ID: 30157 Updated by: bj...@php.net Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() -Status: To be documented +Status: Closed Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) -Assigned To: +Assigned To:bjori Block user comment: N Private report: N New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2011-08-30 11:43:48] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=315772 Log: Fixed bug#30157, stream_tell() isn't called by ftell(), only when seeking [2011-08-28 22:06:32] paj...@php.net Hm, actually let move it as a to be documented instead [2011-08-28 22:05:36] paj...@php.net . [2011-08-28 22:01:39] bugs dot php at mohiva dot com I think this bug can be closed. As described by Gustavo(http://news.php.net/php.internals/54999), this is by design. And the wrong results, described in the last comments, are errors in my stream wrapper implementation. [2011-08-28 10:53:37] bugs dot php at mohiva dot com >> Do you have further analyzes to provide? Please look at the code at https://gist.github.com/1176512 In this scenario stream_tell gets only be executed internally, after calling stream_fseek. This is the correct behaviour and documented at http://www.php.net/manual/en/streamwrapper.stream-seek.php. As you can see, the first both ftell calls returns a wrong result. Only the last ftell call returns the correct result. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157&edit=1
Bug #55430 [Asn->Csd]: New session.upload_progress.* values are not in php.ini-*
Edit report at https://bugs.php.net/bug.php?id=55430&edit=1 ID: 55430 Updated by: bj...@php.net Reported by:s...@php.net Summary:New session.upload_progress.* values are not in php.ini-* -Status: Assigned +Status: Closed Type: Bug Package:*Configuration Issues Operating System: all PHP Version:5.4SVN-2011-08-15 (SVN) Assigned To:bjori Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-08-30 11:13:11] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=315770 Log: Fixed bug#55430, introduce the session.upload_progress family to the world [2011-08-15 23:59:02] s...@php.net Description: The new PHP 5.4 session.upload_progress.* directives should be added to php.ini- development and php.ini-production. -- Edit this bug report at https://bugs.php.net/bug.php?id=55430&edit=1
Bug #55267 [Opn->Csd]: session_regenerate_id fails after header sent even if session.use_cookies = 0
Edit report at https://bugs.php.net/bug.php?id=55267&edit=1
ID: 55267
Updated by: bj...@php.net
Reported by:jesse dot hallam at gmail dot com
Summary:session_regenerate_id fails after header sent even
if session.use_cookies = 0
-Status: Open
+Status: Closed
Type: Bug
Package:Session related
Operating System: Linux
PHP Version:5.3.6
-Assigned To:
+Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-07-22 12:01:49] jesse dot hallam at gmail dot com
Correcting summary so as not to suggest an invalid ini setting is being used.
[2011-07-22 12:00:53] jesse dot hallam at gmail dot com
Description:
When unit testing session-related code in a CLI environment, appropriate PHP
ini settings combined with passing false to session_cache_limiter can allow
sessions to be started even if output has been already sent.
Unfortunately, session_regenerate_id() fails unconditionally even when no
cookie headers would have been sent:
// session.c, session_regenerate_id
if (SG(headers_sent)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot regenerate session id -
headers already sent");
RETURN_FALSE;
}
// session.c, php_session_reset_id
if (PS(use_cookies) && PS(send_cookie)) {
php_session_send_cookie(TSRMLS_C);
PS(send_cookie) = 0;
}
Is this just an oversight? Or intentional?
Test script:
---
Expected result:
No warnings or errors.
Output:
test
Actual result:
--
testPHP Warning: session_regenerate_id(): Cannot regenerate session id -
headers already sent in /home/jesse.hallam/tmp/session_test.php on line 15
PHP Stack trace:
PHP 1. {main}() /home/jesse.hallam/tmp/session_test.php:0
PHP 2. session_regenerate_id() /home/jesse.hallam/tmp/session_test.php:15
--
Edit this bug report at https://bugs.php.net/bug.php?id=55267&edit=1
Bug #55384 [Opn->Bgs]: AMQP::consume()
Edit report at https://bugs.php.net/bug.php?id=55384&edit=1
ID: 55384
Updated by: bj...@php.net
Reported by:peter dot colclough at toolstation dot com
Summary:AMQP::consume()
-Status: Open
+Status: Bogus
Type: Bug
Package:Unknown/Other Function
Operating System: Ubuntu 10 , 64Bit
PHP Version:5.3.7RC4
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Please file pecl extension issues in their own bug tracker,
http://pecl.php.net/bugs/report.php?package=amqp
Previous Comments:
[2011-08-09 11:03:07] peter dot colclough at toolstation dot com
Description:
---
>From manual page: http://www.php.net/amqpqueue.consume
---
Using this against a RabbitMQ server...
This is a very small snippet of very simple code. If you use the consume on a
durable message on a durable queue, this just eats up memory, and kills teh
machine, when it hits around 7k messages.
Using get() all is Ok. It looks like a memory leak somewhere in teh AMQP
code
Test script:
---
include_once('../config/config.php');
$nMessNum = 4000;
$nCount = 0;
$nTimeLimit = 600;
$nI = 0;
$sMessRoute = '';
while($nI++ < 1){
$sMessRoute .= 'a';
}
$nstart = microtime_float();
$amp = new AMQPConnection($RABBIT_SERVERS);
if($amp->connect()){
echo('Connected to Host'."\n");
// Declare a new exchange
$options = AMQP_DURABLE;
$ex = new AMQPExchange($amp,'stone_warren');
$ex->declare('stone_warren', AMQP_EX_TYPE_FANOUT, AMQP_DURABLE);
// Create a new queue
$q = new AMQPQueue($amp);
$q->declare('queue1',AMQP_DURABLE);
// Bind it on the exchange to routing.key
$ex->bind('queue1', 'routing.key');
// consume a message to the exchange with a routing key...and ack it.
$options = array(
'min'=>1,
'max'=>10,
'ack'=>true
);
$nMsgCount = 0;
$tsStart = time();
while(1){ // Forever
$nCount++;
// This dies soon... after about 7k messages
$msg = $q->consume($options);
//$msg = $q->get(0);
echo(print_r($msg, true)."\n");
usleep(1);
if((file_exists('consumer'.$nType.'.stop')) ||
((time() - $tsStart) > $nTimeLimit)){
break;
}
}
}else{
echo("Failed to connect \n");
}
// END OF CODE
Expected result:
Should run forever, consuming messages placed on the queue by a similar
process. Using get() I was able to process 23m messages over a 3 day period.
Using consume(), I die in a matter of minutes.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55384&edit=1
Bug #53385 [Opn->Fbk]: Phar stream wrapper can't handle escaped paths
Edit report at https://bugs.php.net/bug.php?id=53385&edit=1 ID: 53385 Updated by: bj...@php.net Reported by:michel dot hartmann at mayflower dot de Summary:Phar stream wrapper can't handle escaped paths -Status: Open +Status: Feedback Type: Bug Package:PHAR related Operating System: debian PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Why do you expect be able to access files within a .phar using urlencoded spaces? I can't do that on my normal filesystem either.. Previous Comments: [2010-11-23 14:31:20] michel dot hartmann at mayflower dot de Description: If you have a .phar in a directory that contains spaces (e.g. "/some/path with spaces/example.phar") it is not possible to read files in that phar using their full and escaped path (e.g. "phar:///some/path%20with%20spaces/example.phar/README"). This got to my attention since simplexml_load_file always escapes the provided paths. Test script: --- https://bugs.php.net/bug.php?id=53385&edit=1
Req #51918 [Opn]: Phar::webPhar() does not handle requests sent through PUT and DELETE method
Edit report at https://bugs.php.net/bug.php?id=51918&edit=1 ID: 51918 Updated by: bj...@php.net Reported by:max dot romanovsky at gmail dot com Summary:Phar::webPhar() does not handle requests sent through PUT and DELETE method Status: Open Type: Feature/Change Request Package:PHAR related Operating System: FreeBSD PHP Version:5.3.2 Block user comment: N Private report: N New Comment: It seems quite intentional. It only supports GET and POST, not PUT, DELETE, HEAD, ... Previous Comments: [2010-05-26 10:40:16] max dot romanovsky at gmail dot com Description: Phar::webPhar() does not handle requests sent through PUT and DELETE request method. Test script: --- PUT /REST/foo HTTP/1.1 host: example.com Content-Length: 2 12 HTTP/1.1 200 OK Server: nginx/0.8.36 Date: Tue, 25 May 2010 14:01:42 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.3.2 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=51918&edit=1
Bug #53220 [Opn->Fbk]: 'make install' fails in a phar install phase
Edit report at https://bugs.php.net/bug.php?id=53220&edit=1 ID: 53220 Updated by: bj...@php.net Reported by:viriketo at gmail dot com Summary:'make install' fails in a phar install phase -Status: Open +Status: Feedback Type: Bug -Package:PHAR related +Package:*General Issues Operating System: armv5tel-linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-11-01 22:15:03] viriketo at gmail dot com Description: php 5.3.3 fails to install the pear phar archive in the default installation, so the "make install" phase fails. Here is an excerpt of the log: building install-pear-installer phar "/tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar" does not have a signature Warning: require_once(phar://install-pear-nozlib.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar "phar://install-pear-nozlib.phar/index.php" in /tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar on line 1236 make[1]: *** [install-pear-installer] Error 255 The same build and install script works in x86_64-linux and mips-linux, but on armv5tel-linux it fails. If I run manually the line as specified in the Makefile.frag, I get the same error: # ../sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0 install-pear-nozlib.phar -d /tmp/pear phar "/tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar" does not have a signature If I run the same line calling php 5.2.13 (which I had around) instead of the just compiled 5.3.3, the complain does not appear. I'm using gcc 4.5.1, glibc 2.12.1, linux 2.6.35.3, in a native build on NixOS. Test script: --- ../sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0 install-pear-nozlib.phar -d /tmp/pear Expected result: In other systems, I see that the install-pear-nozlib.phar file gets installed normally. Actual result: -- phar "/tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar" does not have a signature Warning: require_once(phar://install-pear-nozlib.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar "phar://install-pear-nozlib.phar/index.php" in /tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar on line 1236 -- Edit this bug report at https://bugs.php.net/bug.php?id=53220&edit=1
Req #52310 [Opn->Csd]: Phar is statically inside php, but is refered as external module in .ini
Edit report at https://bugs.php.net/bug.php?id=52310&edit=1 ID: 52310 Updated by: bj...@php.net Reported by:kindaian at gmail dot com Summary:Phar is statically inside php, but is refered as external module in .ini -Status: Open +Status: Closed Type: Feature/Change Request Package:PHAR related Operating System: Windows PHP Version:5.3.2 -Assigned To: +Assigned To:bjori Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2010-07-12 01:29:03] kindaian at gmail dot com Description: The php.ini has the following line: ;extension=php_phar.dll As the php_phar.dll is statically compiled in php.exe, the line, if on the ini file should state something like: ;extension=php_phar.dll ;statically in php.exe Expected result: Either the reference for that extension should be removed, or, commented as proposed or similar. Actual result: -- As the php_phar.dll is inside php.exe, any try to uncomment it will result on an error on php, because it will be unable to find the dll. -- Edit this bug report at https://bugs.php.net/bug.php?id=52310&edit=1
Bug #53872 [Opn->Csd]: internal corruption of phar
Edit report at https://bugs.php.net/bug.php?id=53872&edit=1 ID: 53872 Updated by: bj...@php.net Reported by:bugzilla33 at gmail dot com Summary:internal corruption of phar -Status: Open +Status: Closed Type: Bug Package:PHAR related Operating System: Windows 7 32-bit PHP Version:5.3.5 -Assigned To: +Assigned To:bjori Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-08-29 16:05:35] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=315713 Log: Fixed bug#53872 (internal corruption of phar) [2011-01-28 22:17:43] bugzilla33 at gmail dot com Description: internal corruption of phar, when reading file from phar archive has size equal to zero Test script: --- http://host0001.webd.pl/bugs/php/internal_corruption_of_phar.zip Expected result: testcase.php from internal_corruption_of_phar.zip should prints OK Actual result: -- testcase.php from internal_corruption_of_phar.zip prints OK internal corruption of phar -- Edit this bug report at https://bugs.php.net/bug.php?id=53872&edit=1
Bug #55441 [Opn->Bgs]: \Phar::createDefaultStub() does not handle its arguments
Edit report at https://bugs.php.net/bug.php?id=55441&edit=1
ID: 55441
Updated by: bj...@php.net
Reported by:frederic dot hardy at mageekbox dot net
Summary:\Phar::createDefaultStub() does not handle its
arguments
-Status: Open
+Status: Bogus
Type: Bug
Package:PHAR related
Operating System: MacOS X 10.6.8
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
You are looking for $phar->setDefaultStub() or $phar->setStub($phar-
>createDefaultStub());
Previous Comments:
[2011-08-22 19:44:34] frederic dot hardy at mageekbox dot net
';
$phar['web.php'] = '';
$phar->createDefaultStub('cli.php', 'web.php');
?>
# php createDefaultStub.phar
PHP Warning: include(phar:///path/to/createDefaultStub.phar/index.php): failed
to open stream: phar error: "index.php" is not a file in phar
"/path/to/createDefaultStub.phar" in /path/to/createDefaultStub.phar on line 9
[2011-08-22 14:13:29] ka...@php.net
By quickly skimming over the source it seems that in order for this function to
work both parameters must have a value. Have you tried that?
[2011-08-17 13:43:16] frederic dot hardy at mageekbox dot net
Description:
\Phar::createDefaultStub() takes two optional arguments.
With these arguments, the user can defined file in phar archive which will be
used
in stub.
However, these arguments seems to be not used by \Phar::createDefaultStub().
Test script:
---
';
$phar->createDefaultStub('stub.php');
Expected result:
This is the stub !
Actual result:
--
PHP Warning: include(phar:///path/to/my.phar/index.php): failed to open
stream:
phar error: "index.php" is not a file in phar "/path/to/my.phar" in
/path/to/my.phar on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=55441&edit=1
Bug #52013 [Asn->Csd]: Unable to decompress files in a compressed phar.
Edit report at https://bugs.php.net/bug.php?id=52013&edit=1
ID: 52013
Updated by: bj...@php.net
Reported by:frederic dot hardy at mageekbox dot net
Summary:Unable to decompress files in a compressed phar.
-Status: Assigned
+Status: Closed
Type: Bug
Package:PHAR related
Operating System: FreeBSD
PHP Version:5.3.2
-Assigned To:cellog
+Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-08-29 14:19:44] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=315703
Log: Fixed bug#52013 (Unable to decompress files in a compressed phar)
[2010-07-02 04:46:45] ericstew...@php.net
Automatic comment from SVN on behalf of ericstewart
Revision: http://svn.php.net/viewvc/?view=revision&revision=300928
Log: Added test for bug 52013 to PHP_5_3.
[2010-07-02 04:45:58] ericstew...@php.net
Automatic comment from SVN on behalf of ericstewart
Revision: http://svn.php.net/viewvc/?view=revision&revision=300927
Log: Added test for bug 52013 to trunk.
[2010-06-07 11:55:42] frederic dot hardy at mageekbox dot net
Description:
Use Phar::decompressFiles() to decompress files in a phar where files was
compressed with Phar::compressFiles(Phar::GZ) throw an exception.
Configure Command => './configure' '--with-layout=GNU'
'--with-config-file-scan-dir=/usr/local/etc/php' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--enable-libxml' '--with-libxml-dir=/usr/local'
'--with-pcre-regex=/usr/local' '--program-prefix=' '--disable-cgi'
'--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL'
'--disable-ipv6' '--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/info/' '--build=i386-portbld-freebsd8.0'
Phar API version : 1.1.1
df -h output : /dev/ad0s1e 66G7.6G 53G13%/usr
Test script:
---
');
}
$phar = new \Phar(__DIR__ . '/compressed.phar');
$phar->buildFromDirectory(__DIR__ . '/files', '/\.php$/');
$phar->setSignatureAlgorithm(\Phar::SHA1);
$phar->compressFiles(\Phar::GZ);
for ($file = 1; $file < 50; $file++)
{
unlink(__DIR__ . '/files/' . $file . '.php');
}
rmdir(__DIR__ . '/files');
$phar = new \Phar(__DIR__ . '/compressed.phar');
$phar->decompressFiles();
foreach ($phar as $file)
{
var_dump(file_get_contents($file->getFilename()));
}
?>
Expected result:
No output and phar was decompressed.
Actual result:
--
fch@witchblade:~/tmp/phar
362> php -d phar.readonly=0 generator.php
PHP Fatal error: Uncaught exception 'BadMethodCallException' with message
'unable to write contents of file "1.php" to new phar
"/usr/home/fch/tmp/phar/compressed.phar"' in
/usr/home/fch/tmp/phar/generator.php:25
Stack trace:
#0 /usr/home/fch/tmp/phar/generator.php(25): Phar->decompressFiles()
#1 {main}
thrown in /usr/home/fch/tmp/phar/generator.php on line 25
--
Edit this bug report at https://bugs.php.net/bug.php?id=52013&edit=1
Bug #55477 [Opn->Bgs]: crypt() returns inconsistent hashes for non-ASCII characters
Edit report at https://bugs.php.net/bug.php?id=55477&edit=1
ID: 55477
Updated by: bj...@php.net
Reported by:christian at pingdom dot com
Summary:crypt() returns inconsistent hashes for non-ASCII
characters
-Status: Open
+Status: Bogus
Type: Bug
Package:*Encryption and hash functions
Operating System: Linux
PHP Version:5.3.7
Block user comment: N
Private report: N
New Comment:
This is expected, see http://www.openwall.com/lists/announce/2011/06/21/1
You need to use $2x$ for non-ascii, sorry :(
Previous Comments:
[2011-08-22 12:47:41] christian at pingdom dot com
Description:
Hashes generated with crypt() (using Blowfish) on PHP 5.3.5 or 5.3.3 cannot be
validated on 5.3.7, if the hashed strings contain non-ASCII characters. The
reverse is also true, if the hashes were generated on 5.3.7, they cannot be
validated on 5.3.3 or 5.3.5.
Test script:
---
$passwords = array(
// these hashes were generated on PHP 5.3.5-1ubuntu7.2 with Suhosin-Patch
(cli) (built: May 2 2011 23:00:17)
'brownfox' =>
'$2a$07$usesomesillystringforeD/hyr5e1bWX2PzwckMuCRNQMTrQNr72',
'Boxkämpfer' =>
'$2a$07$usesomesillystringfore36pVDWFz65CbxoLgSgVURqHWU4yEqye',
'ÑаÑÑлива' =>
'$2a$07$usesomesillystringforeoM7K1pyDjeAG1F42k34MP.tbiMnNcy.',
'Põdur' => '$2a$07$usesomesillystringfore1iPxMN9wh4Cr2oVR6nmdILWylX9D0iO',
);
foreach ($passwords as $password => $hash)
{
$computedHash = crypt($password, $hash);
if ($computedHash == $hash)
{
echo "hash OK\n";
}
else
{
echo "hash FAIL ($hash != $computedHash)\n";
}
}
Expected result:
hash OK
hash OK
hash OK
hash OK
Actual result:
--
hash OK
hash FAIL ($2a$07$usesomesillystringfore36pVDWFz65CbxoLgSgVURqHWU4yEqye !=
$2a$07$usesomesillystringforeelZZJE6VQ2/DIcx1J.D.htZuAQIV43S)
hash FAIL ($2a$07$usesomesillystringforeoM7K1pyDjeAG1F42k34MP.tbiMnNcy. !=
$2a$07$usesomesillystringforevg24bYcXKv2WUiCZvAH627ba6aubiNC)
hash FAIL ($2a$07$usesomesillystringfore1iPxMN9wh4Cr2oVR6nmdILWylX9D0iO !=
$2a$07$usesomesillystringforeuqJNc6ZnvGzLGss/.ZcwQdygkbYamRq)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55477&edit=1
Bug #55459 [Opn->Wfx]: Unable to differentiate between end of file or read error
Edit report at https://bugs.php.net/bug.php?id=55459&edit=1
ID: 55459
Updated by: bj...@php.net
Reported by:scope at planetavent dot de
Summary:Unable to differentiate between end of file or read
error
-Status: Open
+Status: Wont fix
Type: Bug
Package:XML Reader
Operating System: Ubuntu 10.04 LTS
PHP Version:5.3.7
Block user comment: N
Private report: N
New Comment:
If an error occurred libxml_get_errors() will be populated with details on the
error.
Previous Comments:
[2011-08-19 09:56:22] scope at planetavent dot de
Description:
We were forced into using xmlreader the other day due to xml file sizes.
Usually we use DOM to check for well-formedness and schema validity.
It seems, that it is currently not possible to differentiate between a reading
error (e.g. not well formed) and "end of file" using xmlreader.
Unfortunately it is not possible to call XMLReader::isValid() after an
unsuccessful read when using a schema. Of course, if the document is not
well-formed it can't be valid. But isValid() just calls onto
xmlTextReaderIsValid() which seems to work only, if the node pointer was able
to advance correctly (which is not the case for that kind of error). So this is
not an option.
>From ext/xmlreader/php_xmlreader.c:806
retval = xmlTextReaderRead(intern->ptr);
if (retval == -1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "An Error Occured while
reading");
RETURN_FALSE;
} else {
RETURN_BOOL(retval);
}
and
>From ext/xmlreader/php_xmlreader.c:849
if (retval == -1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "An Error Occured while
reading");
RETURN_FALSE;
} else {
RETURN_BOOL(retval);
}
According to libxml, the result of xmlTextReaderRead() is
"1 if the node was read successfully, 0 if there is no more nodes to read, or
-1 in case of error".
Therefor PHP should return true, int(0) or false to be able to check for
reading errors.
I'm not quite sure if this can be considered a bug. To my mind it is, because
it prevents me from using xmlreader in a proper way and as a result, renders it
very difficult to work on huge xml files.
libxml is able to distinguish between both conditions, so should php.
Test script:
---
open( $file );
while ( true )
{
$success = $xr->read();
if ( !$success )
{
# end of file or error?
var_dump( $success );
echo "no success\n";
break;
}
else
{
echo "read success\n";
}
}
Expected result:
Ability to check for int(0) = no elements to read and false = error during read.
Actual result:
--
[...]
read success
read success
read success
Warning: XMLReader::read(): An Error Occured while reading in X:\xmlreader.php
on line 12
bool(false)
no success
--
Edit this bug report at https://bugs.php.net/bug.php?id=55459&edit=1
Bug #55286 [Opn->Bgs]: error in the assigning integer values for the variables
Edit report at https://bugs.php.net/bug.php?id=55286&edit=1
ID: 55286
Updated by: bj...@php.net
Reported by:balezin at yandex dot ru
Summary:error in the assigning integer values for the
variables
-Status: Open
+Status: Bogus
Type: Bug
Package:*General Issues
Operating System: FreeBSD 8.2
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
See the error on http://no2.php.net/types.integer
Previous Comments:
[2011-07-26 14:02:33] balezin at yandex dot ru
I am sorry for my mistake: it is not a "Documentation problem" - it is a Bug.
[2011-07-26 13:53:31] balezin at yandex dot ru
Description:
# php --version
PHP 5.3.6 with Suhosin-Patch (cli) (built: Jul 21 2011 10:37:27)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
Hi! I found PHP error in the process assigning for integer variables.
Test script:
---
$a1=02;
$a2=2;
$a3=09;
$a4=9;
print("$a1, $a2, $a3, $a4");
Expected result:
2, 2, 9, 9
Actual result:
--
2, 2, 0, 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=55286&edit=1
Bug #55084 [Opn->Csd]: Function registered by header_register_callback is called only once per process
Edit report at https://bugs.php.net/bug.php?id=55084&edit=1 ID: 55084 Updated by: bj...@php.net Reported by:vr...@php.net Summary:Function registered by header_register_callback is called only once per process -Status: Open +Status: Closed Type: Bug Package:HTTP related Operating System: Windows PHP Version:5.4.0alpha1 -Assigned To: +Assigned To:bjori Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-07-06 16:38:57] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=313026 Log: Fixed bug#55084 (Function registered by header_register_callback is called only once per process). (Hannes) also fixed an issue when header()s are sent from the callback function [2011-06-30 07:32:54] vr...@php.net Description: I use Apache 2.2.19. Function registered by header_register_callback() is called only after the server restart. Test script: --- Expected result: "OK" each time the script is run. Actual result: -- "OK" only for the first time, nothing in the next runs. -- Edit this bug report at https://bugs.php.net/bug.php?id=55084&edit=1
Bug #55084 [Opn->Asn]: Function registered by header_register_callback is called only once per process
Edit report at https://bugs.php.net/bug.php?id=55084&edit=1 ID: 55084 Updated by: bj...@php.net Reported by:vr...@php.net Summary:Function registered by header_register_callback is called only once per process -Status: Open +Status: Assigned Type: Bug Package:HTTP related Operating System: Windows PHP Version:5.4.0alpha1 Block user comment: N Private report: N Previous Comments: [2011-06-30 07:32:54] vr...@php.net Description: I use Apache 2.2.19. Function registered by header_register_callback() is called only after the server restart. Test script: --- Expected result: "OK" each time the script is run. Actual result: -- "OK" only for the first time, nothing in the next runs. -- Edit this bug report at https://bugs.php.net/bug.php?id=55084&edit=1
Bug #54998 [Asn->Fbk]: DOMElement::setAttribute fails if the value is : "0"
Edit report at http://bugs.php.net/bug.php?id=54998&edit=1
ID: 54998
Updated by: bj...@php.net
Reported by:ealexs at gmail dot com
Summary:DOMElement::setAttribute fails if the value is : "0"
-Status: Assigned
+Status: Feedback
Type: Bug
Package:DOM XML related
Operating System: Debian squeeze1
PHP Version:5.3.6
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
No it doesn't:
bjori@foobar:~$ php -derror_reporting=-1
createElement("para");
$newnode = $doc->appendChild($node);
$n = $newnode->setAttribute("align", 0);
$x = $newnode->setAttribute("align2", "0");
var_dump($n, $x);
print $doc->saveXML();
object(DOMAttr)#3 (0) {
}
object(DOMAttr)#4 (0) {
}
bjori@foobar:~$
Previous Comments:
[2011-06-06 10:01:17] ealexs at gmail dot com
Description:
---
>From manual page: http://www.php.net/domelement.setattribute#Description
---
DOMElement::setAttribute fails if the value is : "0" (or 0 as numeric)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54998&edit=1
Bug #51819 [Asn->Csd]: Case discrepancy in timezone names cause Uncaught exception and fatal error
Edit report at http://bugs.php.net/bug.php?id=51819&edit=1 ID: 51819 Updated by: bj...@php.net Reported by:shumisha at gmail dot com Summary:Case discrepancy in timezone names cause Uncaught exception and fatal error -Status: Assigned +Status: Closed Type: Bug Package:Date/time related Operating System: linux/windows PHP Version:5.2.13 -Assigned To:derick +Assigned To:bjori Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fixed in 5.3 & 5.4 Previous Comments: [2011-06-05 15:30:05] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=311831 Log: Fixed bug#51819 (Case discrepancy in timezone names cause Uncaught exception and fatal error) [2010-07-18 01:20:27] k.schroe...@php.net Automatic comment from SVN on behalf of k.schroeder Revision: http://svn.php.net/viewvc/?view=revision&revision=301360 Log: Test for #51819 [2010-05-14 10:10:07] shumisha at gmail dot com Description: Hi There seem to be a discrepency for timezones names as reported by timezone_abbreviations_list() and the DateTime object parser. We have found a (small) numbre of timezones for which this happens: Been reported and reproduced with PHP 5.1.41 adn PHP 5.2.13 Test script: --- 1 - Get identifiers list: $all = timezone_abbreviations_list(); The resulting array contains, for instance: [54] => Array ( [dst] => [offset] => 36000 [timezone_id] => Australia/NSW ) 2 - Use this timezone_id to create a DateTimeObject $dateString = "2010-05-15 00:00:00 Australia/NSW"; $date = new DateTime( $dateString); Expected result: A DateTime object created The above code runs without problem if timezone identifier (Australia/NSW) is replaced by Australia/Nsw. I have found the following timezones to have the same issue: Australia/ACT NZ-CHAT America/Know_IN Australia/LHI Chile/EasterIsland Europe/Isle_of_Man In others, all timezones names that do not follow camelcase strictly. There are probably others. Actual result: -- Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct() [datetime.--construct]: Failed to parse time string (2010-05-15 00:00:00 Australia/NSW) at position 20 (A): The timezone could not be found in the database' in //test.php on line 4 -- Edit this bug report at http://bugs.php.net/bug.php?id=51819&edit=1
Bug #54898 [Opn->Bgs]: HTTP context option "ignore_errors" does not work as expected
Edit report at http://bugs.php.net/bug.php?id=54898&edit=1
ID: 54898
Updated by: bj...@php.net
Reported by:simast at gmail dot com
Summary:HTTP context option "ignore_errors" does not work as
expected
-Status: Open
+Status: Bogus
Type: Bug
Package:Streams related
Operating System: Linux/Ubuntu
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
You are doing something wrong.
/errors.php:
And executing:
1,
);
$context = stream_context_create(array("http" => $opts));
foreach(range(200, 404) as $errorcode) {
$content = file_get_contents("http://localhost/errors.php?
errorcode=$errorcode", false, $context);
echo $http_response_header[0], " - ", $content, "\n";
}
?>
Gives me:
HTTP/1.0 200 foobar - This is the content of 200
HTTP/1.0 201 foobar - This is the content of 201
HTTP/1.0 202 foobar - This is the content of 202
HTTP/1.0 203 foobar - This is the content of 203
HTTP/1.0 204 foobar - This is the content of 204
HTTP/1.0 205 foobar - This is the content of 205
HTTP/1.0 206 foobar - This is the content of 206
HTTP/1.0 207 foobar - This is the content of 207
HTTP/1.0 208 foobar - This is the content of 208
HTTP/1.0 209 foobar - This is the content of 209
HTTP/1.0 210 foobar - This is the content of 210
HTTP/1.0 211 foobar - This is the content of 211
HTTP/1.0 212 foobar - This is the content of 212
HTTP/1.0 213 foobar - This is the content of 213
HTTP/1.0 214 foobar - This is the content of 214
HTTP/1.0 215 foobar - This is the content of 215
HTTP/1.0 216 foobar - This is the content of 216
HTTP/1.0 217 foobar - This is the content of 217
HTTP/1.0 218 foobar - This is the content of 218
HTTP/1.0 219 foobar - This is the content of 219
HTTP/1.0 220 foobar - This is the content of 220
HTTP/1.0 221 foobar - This is the content of 221
HTTP/1.0 222 foobar - This is the content of 222
HTTP/1.0 223 foobar - This is the content of 223
HTTP/1.0 224 foobar - This is the content of 224
HTTP/1.0 225 foobar - This is the content of 225
HTTP/1.0 226 foobar - This is the content of 226
HTTP/1.0 227 foobar - This is the content of 227
HTTP/1.0 228 foobar - This is the content of 228
HTTP/1.0 229 foobar - This is the content of 229
HTTP/1.0 230 foobar - This is the content of 230
HTTP/1.0 231 foobar - This is the content of 231
HTTP/1.0 232 foobar - This is the content of 232
HTTP/1.0 233 foobar - This is the content of 233
HTTP/1.0 234 foobar - This is the content of 234
HTTP/1.0 235 foobar - This is the content of 235
HTTP/1.0 236 foobar - This is the content of 236
HTTP/1.0 237 foobar - This is the content of 237
HTTP/1.0 238 foobar - This is the content of 238
HTTP/1.0 239 foobar - This is the content of 239
HTTP/1.0 240 foobar - This is the content of 240
HTTP/1.0 241 foobar - This is the content of 241
HTTP/1.0 242 foobar - This is the content of 242
HTTP/1.0 243 foobar - This is the content of 243
HTTP/1.0 244 foobar - This is the content of 244
HTTP/1.0 245 foobar - This is the content of 245
HTTP/1.0 246 foobar - This is the content of 246
HTTP/1.0 247 foobar - This is the content of 247
HTTP/1.0 248 foobar - This is the content of 248
HTTP/1.0 249 foobar - This is the content of 249
HTTP/1.0 250 foobar - This is the content of 250
HTTP/1.0 251 foobar - This is the content of 251
HTTP/1.0 252 foobar - This is the content of 252
HTTP/1.0 253 foobar - This is the content of 253
HTTP/1.0 254 foobar - This is the content of 254
HTTP/1.0 255 foobar - This is the content of 255
HTTP/1.0 256 foobar - This is the content of 256
HTTP/1.0 257 foobar - This is the content of 257
HTTP/1.0 258 foobar - This is the content of 258
HTTP/1.0 259 foobar - This is the content of 259
HTTP/1.0 260 foobar - This is the content of 260
HTTP/1.0 261 foobar - This is the content of 261
HTTP/1.0 262 foobar - This is the content of 262
HTTP/1.0 263 foobar - This is the content of 263
HTTP/1.0 264 foobar - This is the content of 264
HTTP/1.0 265 foobar - This is the content of 265
HTTP/1.0 266 foobar - This is the content of 266
HTTP/1.0 267 foobar - This is the content of 267
HTTP/1.0 268 foobar - This is the content of 268
HTTP/1.0 269 foobar - This is the content of 269
HTTP/1.0 270 foobar - This is the content of 270
HTTP/1.0 271 foobar - This is the content of 271
HTTP/1.0 272 foobar - This is the content of 272
HTTP/1.0 273 foobar
Bug #54917 [Opn->Bgs]: Incorrect behavior of the sockets functions when using HTTP-connections
Edit report at http://bugs.php.net/bug.php?id=54917&edit=1 ID: 54917 Updated by: bj...@php.net Reported by:euxomen at mail dot ru Summary:Incorrect behavior of the sockets functions when using HTTP-connections -Status: Open +Status: Bogus Type: Bug Package:Sockets related Operating System: Windows 7, Ubuntu 10.10 PHP Version:5.3SVN-2011-05-24 (snap) Block user comment: N Private report: N New Comment: Your script is wrong. feof() will not return true until the connection has timedout, which means your second request never gets written. If you change the while loop to read the content-length data after the headers it will work fine. Previous Comments: [2011-05-24 15:46:14] euxomen at mail dot ru Description: When I try to make HTTP keep-alive connection, script behaves ununderstood. When I am making two request per one connection, using header "Connection:keep- alive", script processes only one. Second request, although it was written into socket, it returns an empty result, due to the fact that the pointer is EOF. Test script: --- http://bugs.php.net/bug.php?id=54917&edit=1
Bug #54906 [Opn->Bgs]: Custom HTTP ErrorDocument cannot be shown with a test php script
Edit report at http://bugs.php.net/bug.php?id=54906&edit=1 ID: 54906 Updated by: bj...@php.net Reported by:stephon at gmail dot com Summary:Custom HTTP ErrorDocument cannot be shown with a test php script -Status: Open +Status: Bogus Type: Bug Package:Apache2 related Operating System: FreeBSD 8.2 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2011-05-23 10:10:20] stephon at gmail dot com Description: I found that a test script below won't cause Apache showing custom pages, but browser's error page, The same result in 403, 404 Is this a bug? and how to fix this problem? Thanks a lot -- stephon Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=54906&edit=1
Bug #54945 [Opn->Bgs]: Function declarations inside if/else statements don't work correctly
Edit report at http://bugs.php.net/bug.php?id=54945&edit=1 ID: 54945 Updated by: bj...@php.net Reported by:charlie at charliesomerville dot com Summary:Function declarations inside if/else statements don't work correctly -Status: Open +Status: Bogus Type: Bug Package:Scripting Engine problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Disable the zend extensions you are using and try again. Previous Comments: [2011-05-28 12:38:37] charlie at charliesomerville dot com Description: When declaring a function inside an if/else statement, the latter declaration is honoured regardless of which branch the if/else statement took. Test script: --- http://bugs.php.net/bug.php?id=54945&edit=1
Req #54948 [Opn->Fbk]: provide functions to handle gracefully requests error
Edit report at http://bugs.php.net/bug.php?id=54948&edit=1 ID: 54948 Updated by: bj...@php.net Reported by:giorgio dot liscio at email dot it Summary:provide functions to handle gracefully requests error -Status: Open +Status: Feedback Type: Feature/Change Request Package:*Web Server problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: You can register your own custom error handler to deal with those (see set_error_handler()). Unsure what else you are asking for.. A specific callback function when ini settings cause errors? Doesn't make sense to me.. Previous Comments: [2011-05-28 20:21:52] giorgio dot liscio at email dot it Description: hi, it is needed [a function|| a set of functions] that allows to execute code when http request errors are thrown during the "startup" time for example if a post request breaks the post_max_size directive, in the user space i can't handle it, unless using error_get_last() that i will need parse to identify the problem ( and i can parse only the last one ) affected directives are, probably: max_file_uploads post_max_size max_input_time [?] thank you in advance -- Edit this bug report at http://bugs.php.net/bug.php?id=54948&edit=1
Req #54946 [Opn->Csd]: stream_get_contents infinite loop
Edit report at http://bugs.php.net/bug.php?id=54946&edit=1 ID: 54946 Updated by: bj...@php.net Reported by:max at cxib dot net Summary:stream_get_contents infinite loop -Status: Open +Status: Closed Type: Feature/Change Request Package:Streams related Operating System: NetBSD PHP Version:5.3.6 -Assigned To: +Assigned To:bjori Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-05-29 14:29:21] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=311545 Log: Fixed bug #54946 (stream_get_contents infinite loop) [2011-05-28 13:13:37] max at cxib dot net Description: #0 0xbb80eb77 in read () from /usr/lib/libc.so.12 #1 0xbb8e0efd in read () from /usr/lib/libpthread.so.0 #2 0x083e7e81 in _php_stream_fopen_from_pipe () #3 0x083dff2f in _php_stream_free () #4 0x083e00ec in _php_stream_read () #5 0x083e1684 in _php_stream_copy_to_mem () php_stream_copy_to_mem() generate infinite loop Test script: --- Expected result: string or null Actual result: -- infinite loop -- Edit this bug report at http://bugs.php.net/bug.php?id=54946&edit=1
Bug #54570 [Opn->Bgs]: SPLFileObject returns the content of a file after it was deleted
Edit report at http://bugs.php.net/bug.php?id=54570&edit=1
ID: 54570
Updated by: bj...@php.net
Reported by:bugs dot php at mohiva dot com
Summary:SPLFileObject returns the content of a file after it
was deleted
-Status: Open
+Status: Bogus
Type: Bug
Package:SPL related
Operating System: Gentoo Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Expected behavior.
Previous Comments:
[2011-04-29 00:20:33] tyra3l at gmail dot com
shorter url:
http://bit.ly/kdhzpQ
it is normal that you can access a deleted file if you have an open file
descriptor for that file.
and this is exactly what happens here
Tyrael
[2011-04-29 00:17:49] tyra3l at gmail dot com
http://stackoverflow.com/questions/196897/locking-executing-files-windows-does-
linux-doesnt-why/196908#196908
Tyrael
[2011-04-19 22:46:01] bugs dot php at mohiva dot com
Description:
With SPLFileObject it is possible to return the content of a file, after
the file was deleted.
Test script:
---
file_put_contents('/tmp/file.txt', 'test');
$file = new SplFileObject('/tmp/file.txt');
unlink('/tmp/file.txt');
var_dump(file_exists('/tmp/file.txt'));
while (!$file->eof()) {
echo $file->fgets();
}
Expected result:
bool(false)
Actual result:
--
bool(false)
test
--
Edit this bug report at http://bugs.php.net/bug.php?id=54570&edit=1
Req #34570 [Opn->Csd]: Implement some sort of setproctitle() in cli version
Edit report at http://bugs.php.net/bug.php?id=34570&edit=1
ID: 34570
Updated by: bj...@php.net
Reported by:steve-php-dev at spwiz dot com
Summary:Implement some sort of setproctitle() in cli version
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux 2.4 kernel
PHP Version:5.0.5
-Assigned To:
+Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
Already exists in pecl. See also http://php.net/setproctitle
closing
Previous Comments:
[2011-01-23 12:59:41] matt at mralston dot co dot uk
Fantastic!
In the dictionary, there's an entry for "short and sweet", and next to
it is your post!
Thank you very much. And thank you PECL. And thank you Wikipedia!
I've never given PECL much attention before; I now see the error of my
ways.
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME
COMMAND
daemon7269 0.0 0.0 124696 3500 ?Ss 11:59 0:00
[CAIMan]
I'm a happy bunny! Thank you.
[2011-01-23 08:03:31] dtajchre...@php.net
http://pecl.php.net/package/proctitle
[2011-01-23 01:48:45] matt at mralston dot co dot uk
I can't stress how much I'd like to see this feature implemented.
I'm not a C programmer and I haven't got a clue how PHP is structured
behind the
scenes, but I can't
imagine that this feature would be difficult to implement.
I've been through a quite a journey with this conundrum today. I started
out
coding a new daemon
this morning. Began to wish I could change the "/usr/bin/php
./caiman.php start"
entry in the "ps
auxw" listing this afternoon. I then spent some time researching how to
do it
(which was fustrating
because I didn't even know how to phrase the question for Google when I
started). I eventually found
some C++ forums talking about modifying argv[0] and was excited and then
disappointed when I found it
didn't work in PHP. I drafted out a long e-mail I intended to send to
the PHP
developers, then figured
I'd better properly RTFM and check out the bug tracker first. That's
when I came
across this feature request
(and an older one from 2002). Unfortunately both appear to have
stalled.
So here I am, adding my voice to this request. I can grovel if you
like!
Please, please, please would somebody have a go at adding this feature
when
they've got some spare
time? Even if the feature is ultimately rejected for inclusion into the
trunk, a
little patch that I
could apply to my own servers would be appreciated so much.
In the meantime, I'm just about to start poking around the PHP sources
on my
development box and see
if I can implement something myself. As I said, I'm not a C programmer
so I
expect to struggle, but
it's worth a shot. I'm thinking of something like:
void pcntl_setproctitle(char *new_title)
{
sprintf(argv[0], new_title);
}
Thanks for listening to me ramble.
- Matt
[2005-09-20 23:39:12] steve-php-dev at spwiz dot com
Description:
I'm using the pcntl module in the CLI SAPI to fork off several
processes. I'd like the processes to be able to identify themselves in
ps. In Linux, you can do this by editing argv[0]. On BSD, you use the
setproctitle() function. Other higher level languages support this
feature. A simple perl script to do this on Linux would be:
$0 = "bogus";
sleep 10;
I tried modifying $argv[0], but that only modified the PHP scripts copy
of argv, not the real argv. It'd be nice if there was a way to modify
the process title directly. Ideally, it would be cross-platform (for
Unix variants, at least).
This was originally requested in 2002
(http://bugs.php.net/bug.php?id=18400), but was rejected. When using
the pcntl functions in the CLI version, it really would be a useful
feature.
--
Edit this bug report at http://bugs.php.net/bug.php?id=34570&edit=1
Bug #54601 [Asn]: Removing the doctype node segfaults
Edit report at http://bugs.php.net/bug.php?id=54601&edit=1
ID: 54601
Updated by: bj...@php.net
Reported by:hannes dot magnusson at gmail dot com
Summary:Removing the doctype node segfaults
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.3SVN-2011-04-25 (SVN)
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
The attached patch does seem to fix the issue and makes valgrind stop
bleeding..
If it is however proper, I don't know :)
Previous Comments:
[2011-04-25 13:07:40] bj...@php.net
Another one from phpdoc :)
[2011-04-25 13:06:08] hannes dot magnusson at gmail dot com
Description:
ext/dom segfaults during shutdown when removing the doctype node :]
The resulting document appears fine.
Test script:
---
--TEST--
Segfault when removing the Doctype node
--SKIPIF--
--FILE--
http://www.docbook.org/xml/5.0/dtd/docbook.dtd"; [
footext'>
bartext'>
]>
&foo;&bar;
XML;
$doc = new DOMDocument();
$doc->loadXML($xml, LIBXML_NOENT);
$n = $doc->doctype;
$doc->removeChild($n);
var_dump($n);
?>
===DONE===
--EXPECTF--
object(DOMDocumentType)#%d (0) {
}
===DONE===
Actual result:
--
0x00481cbf in php_libxml_decrement_node_ptr (object=0x14a1750)
at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:956
956 ret_refcount = --obj_node->refcount;
(gdb) bt
#0 0x00481cbf in php_libxml_decrement_node_ptr
(object=0x14a1750)
at /home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:956
#1 0x0047fae5 in php_libxml_clear_object (object=0x14a1750) at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:150
#2 0x0047fb30 in php_libxml_unregister_node (nodep=0x14a1b90)
at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:163
#3 0x0047fda0 in php_libxml_node_free_list (node=0x14a1b90) at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:248
#4 0x0047fd57 in php_libxml_node_free_list (node=0x149e190) at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:239
#5 0x00481f7c in php_libxml_node_free_resource (node=0x149df90)
at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:1024
#6 0x00482060 in php_libxml_node_decrement_resource
(object=0x147fb90)
at /home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:1059
#7 0x00599b02 in dom_objects_free_storage (object=0x147fb90) at
/home/bjori/Work/OSS/php/php5.3/ext/dom/php_dom.c:1017
#8 0x009c5c92 in zend_objects_store_del_ref_by_handle_ex
(handle=2,
handlers=0x1233100)
at /home/bjori/Work/OSS/php/php5.3/Zend/zend_objects_API.c:220
#9 0x009c598b in zend_objects_store_del_ref (zobject=0x147d5a0)
at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_objects_API.c:172
#10 0x009931ef in _zval_dtor_func (zvalue=0x147d5a0,
__zend_filename=0xf09128
"/home/bjori/Work/OSS/php/php5.3/Zend/zend_execute_API.c",
__zend_lineno=445) at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_variables.c:52
#11 0x00981fe9 in _zval_dtor (zvalue=0x147d5a0,
__zend_filename=0xf09128
"/home/bjori/Work/OSS/php/php5.3/Zend/zend_execute_API.c",
__zend_lineno=445)
at /home/bjori/Work/OSS/php/php5.3/Zend/zend_variables.h:35
#12 0x0098341a in _zval_ptr_dtor (zval_ptr=0x147fde0,
__zend_filename=0xf0a230
"/home/bjori/Work/OSS/php/php5.3/Zend/zend_variables.c",
__zend_lineno=189) at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_execute_API.c:445
#13 0x00993668 in _zval_ptr_dtor_wrapper (zval_ptr=0x147fde0) at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_variables.c:189
#14 0x009a6ad7 in zend_hash_apply_deleter (ht=0x12395c8,
p=0x147fdc8) at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_hash.c:612
#15 0x009a717e in zend_hash_reverse_apply (ht=0x12395c8,
apply_func=0x9829e0 )
at /home/bjori/Work/OSS/php/php5.3/Zend/zend_hash.c:761
#16 0x00982a94 in shutdown_destructors () at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_execute_API.c:226
#17 0x0099521b in zend_call_destructors () at
/home/bjori/Work/OSS/php/php5.3/Zend/zend.c:874
#18 0x0091414a in php_request_shutdown (dummy=0x0) at
/home/bjori/Work/OSS/php/php5.3/main/main.c:1591
#19 0x00a84304 in main (argc=2, argv=0x7fffe198) at
/home/bjori/Work/OSS/php/php5.3/sapi/cli/php_cli.c:1374
(gdb)
---
Bug #54601 [Opn->Asn]: Removing the doctype node segfaults
Edit report at http://bugs.php.net/bug.php?id=54601&edit=1
ID: 54601
Updated by: bj...@php.net
Reported by:hannes dot magnusson at gmail dot com
Summary:Removing the doctype node segfaults
-Status: Open
+Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.3SVN-2011-04-25 (SVN)
-Assigned To:
+Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
Another one from phpdoc :)
Previous Comments:
[2011-04-25 13:06:08] hannes dot magnusson at gmail dot com
Description:
ext/dom segfaults during shutdown when removing the doctype node :]
The resulting document appears fine.
Test script:
---
--TEST--
Segfault when removing the Doctype node
--SKIPIF--
--FILE--
http://www.docbook.org/xml/5.0/dtd/docbook.dtd"; [
footext'>
bartext'>
]>
&foo;&bar;
XML;
$doc = new DOMDocument();
$doc->loadXML($xml, LIBXML_NOENT);
$n = $doc->doctype;
$doc->removeChild($n);
var_dump($n);
?>
===DONE===
--EXPECTF--
object(DOMDocumentType)#%d (0) {
}
===DONE===
Actual result:
--
0x00481cbf in php_libxml_decrement_node_ptr (object=0x14a1750)
at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:956
956 ret_refcount = --obj_node->refcount;
(gdb) bt
#0 0x00481cbf in php_libxml_decrement_node_ptr
(object=0x14a1750)
at /home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:956
#1 0x0047fae5 in php_libxml_clear_object (object=0x14a1750) at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:150
#2 0x0047fb30 in php_libxml_unregister_node (nodep=0x14a1b90)
at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:163
#3 0x0047fda0 in php_libxml_node_free_list (node=0x14a1b90) at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:248
#4 0x0047fd57 in php_libxml_node_free_list (node=0x149e190) at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:239
#5 0x00481f7c in php_libxml_node_free_resource (node=0x149df90)
at
/home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:1024
#6 0x00482060 in php_libxml_node_decrement_resource
(object=0x147fb90)
at /home/bjori/Work/OSS/svn-php/php/php-
src/branches/PHP_5_3/ext/libxml/libxml.c:1059
#7 0x00599b02 in dom_objects_free_storage (object=0x147fb90) at
/home/bjori/Work/OSS/php/php5.3/ext/dom/php_dom.c:1017
#8 0x009c5c92 in zend_objects_store_del_ref_by_handle_ex
(handle=2,
handlers=0x1233100)
at /home/bjori/Work/OSS/php/php5.3/Zend/zend_objects_API.c:220
#9 0x009c598b in zend_objects_store_del_ref (zobject=0x147d5a0)
at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_objects_API.c:172
#10 0x009931ef in _zval_dtor_func (zvalue=0x147d5a0,
__zend_filename=0xf09128
"/home/bjori/Work/OSS/php/php5.3/Zend/zend_execute_API.c",
__zend_lineno=445) at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_variables.c:52
#11 0x00981fe9 in _zval_dtor (zvalue=0x147d5a0,
__zend_filename=0xf09128
"/home/bjori/Work/OSS/php/php5.3/Zend/zend_execute_API.c",
__zend_lineno=445)
at /home/bjori/Work/OSS/php/php5.3/Zend/zend_variables.h:35
#12 0x0098341a in _zval_ptr_dtor (zval_ptr=0x147fde0,
__zend_filename=0xf0a230
"/home/bjori/Work/OSS/php/php5.3/Zend/zend_variables.c",
__zend_lineno=189) at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_execute_API.c:445
#13 0x00993668 in _zval_ptr_dtor_wrapper (zval_ptr=0x147fde0) at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_variables.c:189
#14 0x0000009a6ad7 in zend_hash_apply_deleter (ht=0x12395c8,
p=0x147fdc8) at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_hash.c:612
#15 0x009a717e in zend_hash_reverse_apply (ht=0x12395c8,
apply_func=0x9829e0 )
at /home/bjori/Work/OSS/php/php5.3/Zend/zend_hash.c:761
#16 0x00982a94 in shutdown_destructors () at
/home/bjori/Work/OSS/php/php5.3/Zend/zend_execute_API.c:226
#17 0x0099521b in zend_call_destructors () at
/home/bjori/Work/OSS/php/php5.3/Zend/zend.c:874
#18 0x0091414a in php_request_shutdown (dummy=0x0) at
/home/bjori/Work/OSS/php/php5.3/main/main.c:1591
#19 0x00a84304 in main (argc=2, argv=0x7fffe198) at
/home/bjori/Work/OSS/php/php5.3/sapi/cli/php_cli.c:1374
(gdb)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54601&edit=1
Bug #53870 [Opn->Bgs]: Problem with passing array elements as references in foreach
Edit report at http://bugs.php.net/bug.php?id=53870&edit=1
ID: 53870
Updated by: bj...@php.net
Reported by:lolbummer at gmail dot com
Summary:Problem with passing array elements as references in
foreach
-Status: Open
+Status: Bogus
Type: Bug
Package:Arrays related
Operating System: Mac OS X Snow Leopard
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
See the warnings and examples on http://no.php.net/manual/en/control-
structures.foreach.php
Previous Comments:
[2011-04-17 08:59:09] c...@php.net
Further testing reveals that an unset($foo); between the two seems to
fix the problem.
[2011-04-17 08:57:21] c...@php.net
I have a much simpler reproduction script for, I think the same error.
$array = array('foo', 'bar');
foreach ($array as &$foo) {
}
foreach ($array as $foo) {
echo "$foo\n";
}
Expected result:
foo
bar
Actual result:
--
foo
foo
Note that simply making $foo a reference is not enough. It is the double
foreach on the same array, with the same variable that causes the
reference to be "stuck".
[2011-04-07 20:32:46] akhrulev at mail dot ru
I propose simplest testcase. It is reproduced on all my computers:
PHP 5.3.6 on Windows 7
PHP 5.3.5 on Windows XP
PHP 5.2.6 on Linux version 2.6.18-128.1.6.el5.centos.plus
Expected result:
Array
(
[0] => AAA
[1] => BB
[2] => C
)
Actual result:
Array
(
[0] => AAA
[1] => BB
[2] => BB
)
[2011-02-04 16:04:38] uldericofilho at gmail dot com
On PHP 5.3.5 on CentOS 5.5 - same result. Proof of concept below:
echo "Result\n";
$arr = array(1,2,3,4,5);
foreach($arr as &$a){
$a*=2;
}
foreach($arr as $a){
echo $a."\n";
}
echo str_repeat('-', 10)."\nExpected\n";
$arr = array(1,2,3,4,5);
$arr = array_map(function($v){
return $v*2;
}, $arr);
foreach($arr as $a){
echo $a."\n";
}
[2011-01-28 18:15:45] lolbummer at gmail dot com
Description:
I created an array of strings that would be typecast to integers, and
cast them using a foreach loop, passing each element by reference.
After dumping the resulting array, it gave (somewhat) expected results,
though after dumping each element individually, it gave an unexpected
result on the last element.
This happened with PHP 5.3.5 on Mac OS X Snow Leopard, but did not
happen on a Debian system with PHP 5.2.6.
Test script:
---
$element){
var_dump($key);
var_dump($element);
echo "\n";
}
?>
Expected result:
array(6) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
[3]=>
int(5324)
[4]=>
int(435)
[5]=>
int(51)
}
int(0)
int(1)
int(1)
int(2)
int(2)
int(3)
int(3)
int(5324)
int(4)
int(435)
int(5)
int(51)
Actual result:
--
array(6) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
[3]=>
int(5324)
[4]=>
int(435)
[5]=>
&int(51)
}
int(0)
int(1)
int(1)
int(2)
int(2)
int(3)
int(3)
int(5324)
int(4)
int(435)
int(5)
int(435)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53870&edit=1
Bug #54016 [Asn->Csd]: finfo_file: Cannot determine filetype in archives
Edit report at http://bugs.php.net/bug.php?id=54016&edit=1 ID: 54016 Updated by: bj...@php.net Reported by:bj...@php.net Summary:finfo_file: Cannot determine filetype in archives -Status: Assigned +Status: Closed Type: Bug Package:Filesystem function related Operating System: Linux PHP Version:5.3.5 Assigned To:bjori Block user comment: N Private report: N New Comment: Forgot to close this report.. already fixed in the 5.3.6 Previous Comments: [2011-02-14 16:34:06] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=308328 Log: bfn for #54016 [2011-02-14 16:32:05] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=308327 Log: Bug#54016 (finfo_file() Cannot determine filetype in archives) [2011-02-14 16:21:14] bj...@php.net The following patch has been added/updated: Patch Name: finfo.patch Revision: 1297696874 URL: http://bugs.php.net/patch-display.php?bug=54016&patch=finfo.patch&revision=1297696874 [2011-02-14 16:20:55] bj...@php.net Description: finfo_file() does not support stream wrappers, such as zip://, even though it has stream context option :( Test script: --- http://bugs.php.net/bug.php?id=54016&edit=1
Bug #53579 [Asn->Csd]: stream_get_contents() segfaults on ziparchive streams
Edit report at http://bugs.php.net/bug.php?id=53579&edit=1
ID: 53579
Updated by: bj...@php.net
Reported by:paulgao at yeah dot net
-Summary:stream_get_contents failed
+Summary:stream_get_contents() segfaults on ziparchive
streams
-Status: Assigned
+Status: Closed
Type: Bug
Package:Zip Related
Operating System: irrelevant
PHP Version:5.3.4
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-12-20 12:00:29] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=306493
Log: Fixed bug#53579 (stream_get_contents() segfaults on ziparchive
streams)
Also added the filename being access to the stream_get_meta_data() array
[2010-12-20 07:05:57] paulgao at yeah dot net
trunk code is same.
[2010-12-20 06:58:22] paulgao at yeah dot net
Description:
Segmentation fault
backtrace:
(gdb) bt
#0 0x003510e79320 in strchr () from /lib64/libc.so.6
#1 0x0065a23c in php_zip_ops_stat (stream=, ssb=0x7fff6bb223e0) at /root/php-5.3.4/ext/zip/zip_stream.c:111
#2 0x006c22c5 in _php_stream_copy_to_mem (src=0xd2d6038,
buf=0x7fff6bb224c8, maxlen=35, persistent=0) at
/root/php-5.3.4/main/streams/streams.c:1275
#3 0x0063019e in zif_stream_get_contents (ht=, return_value=0xd2d5f08, return_value_ptr=,
this_ptr=, return_value_used=)
at /root/php-5.3.4/ext/standard/streamsfuncs.c:443
#4 0x0064506c in suhosin_execute_internal
(execute_data_ptr=0x2ac667a0b050, return_value_used=1) at
/root/php-5.3.4/ext/suhosin/execute.c:1673
#5 0x00746475 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2ac667a0b050) at
/root/php-5.3.4/Zend/zend_vm_execute.h:318
#6 0x0071e15c in execute (op_array=0xd2d43c8) at
/root/php-5.3.4/Zend/zend_vm_execute.h:107
#7 0x006455b9 in suhosin_execute_ex (op_array=0xd2d43c8, zo=0,
dummy=0) at /root/php-5.3.4/ext/suhosin/execute.c:585
#8 0x006fb95d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.4/Zend/zend.c:1194
#9 0x006ab9cd in php_execute_script
(primary_file=0x7fff6bb24d70) at /root/php-5.3.4/main/main.c:2265
#10 0x007803ac in main (argc=2, argv=0x7fff6bb24fe8) at
/root/php-5.3.4/sapi/cli/php_cli.c:1193
Test script:
---
open('test.jar') !== TRUE)
{
return FALSE;
}
if ($za->statName($target_file) !== FALSE)
{
$fd = $za->getStream($target_file);
}
else
{
$fd = FALSE;
}
$za->close();
if (is_resource($fd))
{
echo strlen(stream_get_contents($fd));
}
?>
Expected result:
273
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=53579&edit=1
Bug #53579 [Opn->Asn]: stream_get_contents failed
Edit report at http://bugs.php.net/bug.php?id=53579&edit=1
ID: 53579
Updated by: bj...@php.net
Reported by:paulgao at yeah dot net
Summary:stream_get_contents failed
-Status: Open
+Status: Assigned
Type: Bug
Package:Zip Related
Operating System: irrelevant
PHP Version:5.3.4
-Assigned To:
+Assigned To:bjori
Block user comment: N
Private report: N
Previous Comments:
[2010-12-20 07:05:57] paulgao at yeah dot net
trunk code is same.
[2010-12-20 06:58:22] paulgao at yeah dot net
Description:
Segmentation fault
backtrace:
(gdb) bt
#0 0x003510e79320 in strchr () from /lib64/libc.so.6
#1 0x0065a23c in php_zip_ops_stat (stream=, ssb=0x7fff6bb223e0) at /root/php-5.3.4/ext/zip/zip_stream.c:111
#2 0x006c22c5 in _php_stream_copy_to_mem (src=0xd2d6038,
buf=0x7fff6bb224c8, maxlen=35, persistent=0) at
/root/php-5.3.4/main/streams/streams.c:1275
#3 0x0063019e in zif_stream_get_contents (ht=, return_value=0xd2d5f08, return_value_ptr=,
this_ptr=, return_value_used=)
at /root/php-5.3.4/ext/standard/streamsfuncs.c:443
#4 0x0064506c in suhosin_execute_internal
(execute_data_ptr=0x2ac667a0b050, return_value_used=1) at
/root/php-5.3.4/ext/suhosin/execute.c:1673
#5 0x00746475 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2ac667a0b050) at
/root/php-5.3.4/Zend/zend_vm_execute.h:318
#6 0x0071e15c in execute (op_array=0xd2d43c8) at
/root/php-5.3.4/Zend/zend_vm_execute.h:107
#7 0x006455b9 in suhosin_execute_ex (op_array=0xd2d43c8, zo=0,
dummy=0) at /root/php-5.3.4/ext/suhosin/execute.c:585
#8 0x006fb95d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.4/Zend/zend.c:1194
#9 0x006ab9cd in php_execute_script
(primary_file=0x7fff6bb24d70) at /root/php-5.3.4/main/main.c:2265
#10 0x007803ac in main (argc=2, argv=0x7fff6bb24fe8) at
/root/php-5.3.4/sapi/cli/php_cli.c:1193
Test script:
---
open('test.jar') !== TRUE)
{
return FALSE;
}
if ($za->statName($target_file) !== FALSE)
{
$fd = $za->getStream($target_file);
}
else
{
$fd = FALSE;
}
$za->close();
if (is_resource($fd))
{
echo strlen(stream_get_contents($fd));
}
?>
Expected result:
273
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=53579&edit=1
Req #38052 [Opn->Csd]: parse_ini_file() - escaping double quotes is impossible
Edit report at http://bugs.php.net/bug.php?id=38052&edit=1
ID: 38052
Updated by: bj...@php.net
Reported by:alex at thresholdstate dot com
Summary:parse_ini_file() - escaping double quotes is
impossible
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
PHP Version:4.4.2
-Assigned To:
+Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
This was fixed in 5.3
Previous Comments:
[2006-07-10 04:27:06] alex at thresholdstate dot com
Not sure I'd describe it as "much better", since it clashes with windows
paths. Consider:
path = "\"C:\Program Files\blah\""
5.2 would presumably render this as '\C:\Program Files\blah\\', which
loses the distinction between "escaped" quotes and plain backslashes.
[2006-07-10 04:09:13] judas dot iscariote at gmail dot com
Well..with current 5_2 version I get:
array(2) {
["title"]=>
string(23) "Best Scripting Language"
["desc"]=>
string(42) "See http://www.php.net/\>PHP!"
}
although this not what you expect, is much better, since you can use
str_replace() to replace backslashes with double quotes if you want.
[2006-07-10 01:59:53] alex at thresholdstate dot com
The latest PHP5 I have access to is 5.0.4, and it fails there.
[2006-07-10 01:43:14] judas dot iscariote at gmail dot com
IT works perfectly fine with a current version of PHP ( in my case 5_2
CVS), so you better try PHP5, you should be using PHP4 anyway..
ps: it is reproducible in current PHP 4_4 CVS, but Im not sure if this
is gonna be fixed (if a bug), wait for official answer.
[2006-07-10 01:12:36] alex at thresholdstate dot com
Description:
It appears there's no way a value in a .INI file can contain a double
quote character.
Backslash escaping is unsupported. If some other escaping method is
available, the doc page doesn't mention it.
Example is taken from
http://www.php.net/manual/en/function.parse-ini-file.php#18216, posted
in January 2002.
C-style backslash escaping probably can't be supported due to Windows
paths. Other escaping methods might be feasible: SQL-style doubled
quote characters, for example.
Reproduce code:
---
var_dump(parse_ini_file("example.ini"));
;
; Example Configuration File
;
[category]
title = "Best Scripting Language"
desc = "See http://www.php.net/\";>PHP!"
Expected result:
array(2) {
["title"]=>
string(23) "Best Scripting Language"
["desc"]=>
string(13) "See http://www.php.net/";>PHP!"
}
Actual result:
--
PHP Warning: Error parsing a.ini on line 6
in Command line code on line 1
array(2) {
["title"]=>
string(23) "Best Scripting Language"
["desc"]=>
string(13) "See http://bugs.php.net/bug.php?id=38052&edit=1
Doc->Bug #53409 [Csd->ReO]: sleep() return NULL
Edit report at http://bugs.php.net/bug.php?id=53409&edit=1 ID: 53409 Updated by: bj...@php.net Reported by:webmaster at skarmflyg dot org Summary:sleep() return NULL -Status: Closed +Status: Re-Opened -Type: Documentation Problem +Type: Bug -Package:Documentation problem +Package:Unknown/Other Function -Operating System: Windows XP +Operating System: pajoye PHP Version:5.3.3 -Assigned To:aharvey +Assigned To:pajoye Block user comment: N Private report: N New Comment: After quick discussion on IRC; Windows does actually have a way to provide the same functionality as, f.e., Linux by using SleepEx(). Re-classifying as php-src bug & assign to Pierre. Previous Comments: [2010-11-26 10:19:25] ahar...@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. [2010-11-26 10:19:18] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=305764 Log: Fix doc bug #53409 (sleep() return NULL). [2010-11-25 23:57:52] paj...@php.net Sleep on windows returns nothing as well as some other platforms. The result of sleep is actually platform dependent (NULL/FALSE or 0/FALSE). [2010-11-25 22:45:15] webmaster at skarmflyg dot org Description: --- >From manual page: http://www.php.net/function.sleep#Return Values --- Sleep should return int or possibly boolean false but returns NULL. Using PHP 5.3.3 Apache 2.2.6 Windows XP SP3 Test script: --- $x=sleep(1); var_dump($x); // Outputs NULL. Expected int 0. Expected result: According to documentation $x should be integer 0 or possibly false. Actual result: -- Variable $x becomes NULL. -- Edit this bug report at http://bugs.php.net/bug.php?id=53409&edit=1
Bug #51791 [Opn->Ver]: constant() failed to check undefined constant and php interpreter stoped
Edit report at http://bugs.php.net/bug.php?id=51791&edit=1
ID: 51791
Updated by: bj...@php.net
Reported by: iliavlad at mail dot ru
Summary: constant() failed to check undefined constant and php
interpreter stoped
-Status: Open
+Status: Verified
Type: Bug
-Package: Reproducible crash
+Package: Scripting Engine problem
Operating System: Windows, Linux
PHP Version: 5.3.2
New Comment:
This is definitely a bug.
Previous Comments:
[2010-05-13 01:02:35] phi...@php.net
I don't see this change mentioned at any of the following locations:
- http://php.net/php5news
- http://php.net/migration53
- http://php.net/function.constant
Therefore, it can't be completely bogus. Please explain if this BC break
in 5_3
is intentional. constant('IDONOTEXIST') still returns NULL however, with
E_WARNING instead of E_FATAL.
[2010-05-13 00:09:29] iliavlad at mail dot ru
Hi Mike,
according to manual http://php.net/manual/en/function.constant.php
constant() eturns the value of the constant, or NULL if the constant is
not defined. And this happens with php 5.2 version. With php 5.3 there
is a fatal error and php interpreter stops. There are no words about
fatal error in manual.
[2010-05-12 08:16:15] m...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2010-05-11 12:12:45] iliavlad at mail dot ru
Description:
constant() failed to check undefined constant and php interpreter
stoped, but constant() should return NULL and php interpreter should
continue to work.
Test script:
---
class A
{
const B = 1;
}
var_dump(constant('A::B1'));
echo 5;
Expected result:
Warning: constant(): Couldn't find constant A::B1
NULL
5
Actual result:
--
>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
>php -r "class A { const B = 1;} var_dump(@constant('A::B1')); echo 5;"
>php -r "class A { const B = 1;} var_dump(constant('A::B1')); echo 5;"
Fatal error: Undefined class constant 'A::B1' in Command line code on
line 1
Call Stack:
0.0003 317608 1. {main}() Command line code:0
0.0003 317688 2. constant() Command line code:1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51791&edit=1
Bug #51741 [Bgs]: preg_match returns zero if it hits backtracking limit
Edit report at http://bugs.php.net/bug.php?id=51741&edit=1 ID: 51741 Updated by: bj...@php.net Reported by: jordi dot salvat dot i dot alabart at gmail dot com Summary: preg_match returns zero if it hits backtracking limit Status: Bogus Type: Bug Package: PCRE related Operating System: Ubuntu PHP Version: 5.3SVN-2010-05-04 (SVN) New Comment: docs.php.net is a development mirror, not an official mirror. See http://php.net/mirrors That bug has however been fixed, thanks for the report. Previous Comments: [2010-05-12 11:15:43] jordi dot salvat dot i dot alabart at gmail dot com So this is a documentation error. I've tried to add a comment to http://docs.php.net/manual/en/function.preg-match.php, but I got this: << Warning: include(/home/local/Web/sites/docs.php.net/manual/include/spam-func.php) [function.include]: failed to open stream: No such file or directory in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 9 Warning: include() [function.include]: Failed opening '/home/local/Web/sites/docs.php.net/manual/include/spam-func.php' for inclusion (include_path='.:/local/php/lib/php') in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 9 Fatal error: Call to undefined function kill_spammer() in /home/local/Web/sites/docs.php.net/manual/add-note.php on line 10 >> I should have stuck to Java. [2010-05-12 09:52:45] m...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. > Note that pcretest does report an error in this same case As can be queried with preg_last_error(). [2010-05-04 20:32:41] jordi dot salvat dot i dot alabart at gmail dot com Description: According to the documentation, pcre_match should return FALSE on error: >From http://docs.php.net/manual/en/function.preg-match.php : << Return Values preg_match() returns the number of times pattern matches. That will be either 0 times (no match) or 1 time because preg_match() will stop searching after the first match. preg_match_all() on the contrary will continue until it reaches the end of subject. preg_match() returns FALSE if an error occurred. >> Instead, it returns 0 (integer zero) -- see Felipe's comment on http://bugs.php.net/bug.php?id=51663&edit=2 for a check. Note that pcretest does report an error in this same case: $ pcretest PCRE version 7.8 2008-09-05 re> /(.+)+:/ data> \q10a:bbb Error -8 data> Test script: --- http://bugs.php.net/bug.php?id=51741&edit=1
Bug #49192 [ReO->Csd]: PHP crashes when GC invoked on COM object
Edit report at http://bugs.php.net/bug.php?id=49192&edit=1 ID: 49192 Updated by: bj...@php.net Reported by: circus2 at freenet dot de Summary: PHP crashes when GC invoked on COM object -Status: Re-Opened +Status: Closed Type: Bug Package: Reproducible crash Operating System: Win XP SP3 (german) PHP Version: 5.3SVN-2009-08-07 (snap) Assigned To: stas Previous Comments: [2010-04-02 00:54:29] s...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-04-02 00:54:04] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revision&revision=297307 Log: fix #49192 - crash in GC when get_properties handler returns null [2009-08-28 15:44:43] FelixStrauss at gmx dot de In addition: My system is Windows 7 PR Build 7100 [2009-08-28 15:38:19] FelixStrauss at gmx dot de I can reproduce the problem with the following two lines: My system: Zend Extension Build API220090626,TS,VC9 PHP Extension Build API20090626,TS,VC9 [2009-08-15 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49192 -- Edit this bug report at http://bugs.php.net/bug.php?id=49192&edit=1
#50703 [Bgs->Csd]: Call parent::__construct in MySQL with call_user_func* segfault php
ID: 50703 Updated by: bj...@php.net Reported By: gmblar+php at gmail dot com -Status: Bogus +Status: Closed Bug Type: MySQLi related Operating System: * PHP Version: 5.3.1 New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. This actually was a bug in 5.3.1, which is fixed in 5.3.3-dev. Please try the latest 5.3 RC: http://qa.php.net/ Previous Comments: [2010-01-09 00:36:56] bj...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is an endless recursion to the Database_MySQLi constructor. [2010-01-08 23:19:39] gmblar+php at gmail dot com Description: Call parent::__construct in MySQL with call_user_func* segfault php Reproduce code: --- Expected result: No Segmentation fault Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=50703&edit=1
#50703 [Opn->Bgs]: Call parent::__construct in MySQL with call_user_func* segfault php
ID: 50703 Updated by: bj...@php.net Reported By: gmblar+php at gmail dot com -Status: Open +Status: Bogus Bug Type: MySQLi related Operating System: * PHP Version: 5.3.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is an endless recursion to the Database_MySQLi constructor. Previous Comments: [2010-01-08 23:19:39] gmblar+php at gmail dot com Description: Call parent::__construct in MySQL with call_user_func* segfault php Reproduce code: --- Expected result: No Segmentation fault Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=50703&edit=1
#50700 [Opn->Bgs]: ANGOSSO_ROOT
ID: 50700 Updated by: bj...@php.net Reported By: rombiama at gmail dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: installation PHP Version: 5.3.1 New Comment: Huh? You are not making any sense. angosso.com';index.html ?> Thats not gonna work. Move "index.html" away from the block, or into the echo statement. Previous Comments: [2010-01-08 22:29:39] rombiama at gmail dot com Description: Les Diasporas Plurielles:: angosso.com angosso.com';index.html ?> Reproduce code: --- --- >From manual page: function.strstr#Description --- http://localhost/angosso.php or http://79.170.40.162/angossocom/index.php Expected result: Les Diasporas Plurielles:: angosso.com angosso.com/index3.php Actual result: -- Les Diasporas Plurielles:: angosso.com angosso.com/index.html -- Edit this bug report at http://bugs.php.net/?id=50700&edit=1
#50696 [WFx]: number_format when passed a 0 as first function argument, returns null
ID: 50696 Updated by: bj...@php.net Reported By: endosquid at endosquid dot com Status: Wont fix Bug Type: Math related Operating System: Linux 32 bit PHP Version: 5.3.1 New Comment: Sir. This issue was recently brought to my attention. On behalf of PHP I would like to apologize. I see that now that you have been treated unfairly. After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue. I would therefore like to remind you that ras...@php.net is http://en.wikipedia.org/wiki/Rasmus_lerdorf Again, I sincerely apologize. We will try to stop fixing bugs in PHP. Previous Comments: [2010-01-08 23:22:52] endosquid at endosquid dot com Just look in the mirror, pal. You need classes on how to listen to others. [2010-01-08 23:20:13] ras...@php.net Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure. [2010-01-08 23:05:43] endosquid at endosquid dot com I get it. Yours is bigger, you've worked better, you are at the cutting edge of everything, and you have infinite resources to test every new version of every piece of software in your stack. Got it. I'm shamed and have no options. So, you're going to give a cover-all answer to make sure that you don't have to do anything. Ok, I get it. I hope no one ever does this to you, because it makes you lose faith in the product. We will push forwrd with patching the source. It would appear that the 1194th line in math.c is the one that needs changing. returning 0 as opposed to returning nothing? I'll edit and compile. [2010-01-08 22:47:04] ras...@php.net I have worked in such environments. Much bigger ones, in fact. Part of your responsibility in your position is to keep track of your tools and the changes coming down the pipeline. 5.3 was available to you as a release candidate in March of last year, and even earlier directly from our revision control system. Many things have changed and there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a change like this that others in your situation have now accounted for, tested and deployed in production for many months simply because it is inconvenient for you. [2010-01-08 22:38:23] endosquid at endosquid dot com Dramatic? You've obviously never worked in a change-request-release environment. We have number_format in literally thousands of places across 50 or 60 separate products. Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning. So, before you go belittling the developers and users depending on PHP, perhaps you should stop and think about the massive effect this change has had on us and not act so dismissive. 5.3.x was not available on our last platform, which is why we are moving to a supported, fairly-recent platform. Why you have so much anger towards this bug is not a proper way to triage or respond to user requests. We have done nothing but explain how this change will massively affect our calculations. Our only feasible option is to patch php back to the old behavior, but my C is fairly rusty and we ran into issues with time testing the ins and outs from buffers in the number_format function in math.c 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/50696 -- Edit this bug report at http://bugs.php.net/?id=50696&edit=1
#50699 [Opn->Bgs]: Cannot throw Exceptions in __toString()
ID: 50699 Updated by: bj...@php.net Reported By: gmblar+php at gmail dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: * PHP Version: 5.3.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php __toString() must not throw exceptions Previous Comments: [2010-01-08 22:22:35] gmblar+php at gmail dot com Description: Cannot throw Exceptions in __toString(). Instead it produces a Fatal error. Reproduce code: --- Expected result: Fatal error: Uncaught exception 'Exception' with message 'Incomplete Data' in /-:6 Actual result: -- Fatal error: Method bar::__toString() must not throw an exception in /- on line 0 -- Edit this bug report at http://bugs.php.net/?id=50699&edit=1
#50641 [Opn->Bgs]: Extension directory
ID: 50641 Updated by: bj...@php.net Reported By: twallis at mts dot net -Status: Open +Status: Bogus Bug Type: Performance problem Operating System: Windows PHP Version: 5.2.12 New Comment: http://www.php.net/manual/en/install.windows.extensions.php Previous Comments: [2010-01-03 03:20:28] twallis at mts dot net Description: In the php.ini files included in the download the extensions directly is set as: extension_dir = "./" This prevents php from working. It took me four hours of searching until I tripped over documentation about extension_dir. Once I chenged the line to read: extension_dir = "c:/php/ext" the problem was fixed. Nowhere was it stated as part of the installation procedure to change this line. Reproduce code: --- extension_dir = "./" Expected result: php preprocessing does not occur Actual result: -- php preprocessing does not occur -- Edit this bug report at http://bugs.php.net/?id=50641&edit=1
#50638 [Opn->Bgs]: User Stream $context is Not Populated
ID: 50638
Updated by: bj...@php.net
Reported By: cullin dot wible at cullinwible dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: CentOS 5.4 x86_64
PHP Version: 5.3.1
New Comment:
bj...@jessica:~$ php foobar.php
Open Context: resource(5) of type (stream-context)
Fix your parse error and change $context to $this->context
Previous Comments:
[2010-01-02 23:10:26] cullin dot wible at cullinwible dot com
Description:
When creating a user stream using the streamWrapper format, the
$context variable is NOT set during the stream_open method call.
Reproduce code:
---
class TestStream {
public $context;
public function __construct() {
/* do nothing */
}
public function stream_open($path, $mode, $options, &$opened_path) {
echo "Open Context: ";
var_dump($context);
return(true);
}
}
stream_wrapper_register('test, 'TestStream', 0);
$options = array(
'test' => array(
'option1' => 'option1_value'));
$myContext = stream_context_create($options);
fopen('test://test', 'r', false, $myContext);
Expected result:
the $this->context variable should equal $myContext.
Actual result:
--
The $this->context variable is NULL.
Please NOTE the following:
1. The $context is set on an fread, however, it should be set during
the fopen call.
2. If you look at the PHP-c-code, it appears that the userstream.c
class is attempting to set the $context property just after class
construction and prior to calling stream_open. Also, after modifying the
C-code it appears that the context in the C-code is defined and calls
the Zend add_property_resource function. However, there is clearly a bug
somewhere as the property is still NULL.
--
Edit this bug report at http://bugs.php.net/?id=50638&edit=1
#50173 [Tbd->Csd]: Alternative Syntax Else Issue
ID: 50173
Updated by: bj...@php.net
Reported By: kevinarcher15 at hotmail dot com
-Status: To be documented
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: CentOS 5
PHP Version: 5.3.0
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2009-11-23 21:11:37] s...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=291231
Log: Fixed bug#50173 (Alternative Syntax Else Issue)
[2009-11-14 21:23:24] j...@php.net
Do not mix the syntax. You're not only confusing the engine, you're
confusing yourself as well. Needs a note in the manual page here:
http://www.php.net/manual/en/control-structures.alternative-syntax.php
[2009-11-14 02:38:25] kevinarcher15 at hotmail dot com
Description:
PHP is confusing else as part of the nested if statement above it. When
removing the colon and replacing it with a left brace { it says
unexepected '{' expecting ':'... Placing any line of code below the
nested if will stop the problem from occurring, even while(false) { }
prevents it. So it makes sense why its happening, however based on the
syntax and alternative syntax it looks acceptable and PHP even seems to
have an idea that the else is part of the alternative syntax. Test on
stable 5.3.0 and 5.3.1-dev (August 15 2009).
Reproduce code:
---
if(true):
if(true) {
echo 'exepected';
}
else:
echo 'not here';
endif;
Expected result:
expected
Actual result:
--
PHP Parse error: syntax error, unexpected ':' in /home/archer/test.php
on line 5
--
Edit this bug report at http://bugs.php.net/?id=50173&edit=1
#50233 [Bgs]: This is not enought description.
ID: 50233 Updated by: bj...@php.net Reported By: k_radek at yahoo dot pl Status: Bogus Bug Type: Scripting Engine problem Operating System: GNU/Linux PHP Version: 5.2.11 New Comment: Actually, see bug#50184 (which is an open doc issue) Previous Comments: [2009-11-23 20:49:52] bj...@php.net Actually, I cannot reproduce this. You are probably talking about something like this: Note that "fOo" still references the original "bar", while any other variations of "foo" reference the latter, case-insensitive declaration. Thats expected behavior. [2009-11-23 20:44:14] bj...@php.net That makes no sense. Reclassified as an engine problem. [2009-11-19 16:00:14] k_radek at yahoo dot pl Description: Last paremeter defined in a function says that you can define constant with case-insensitive option but says nothing about that it allows you to REDEFINE constant... Reproduce code: --- --- >From manual page: function.define#Parameters --- "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values." Expected result: "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values. It allows you to redefine constant." Actual result: -- "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values." -- Edit this bug report at http://bugs.php.net/?id=50233&edit=1
#50233 [Opn->Bgs]: This is not enought description.
ID: 50233 Updated by: bj...@php.net Reported By: k_radek at yahoo dot pl -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: GNU/Linux PHP Version: 5.2.11 New Comment: Actually, I cannot reproduce this. You are probably talking about something like this: Note that "fOo" still references the original "bar", while any other variations of "foo" reference the latter, case-insensitive declaration. Thats expected behavior. Previous Comments: [2009-11-23 20:44:14] bj...@php.net That makes no sense. Reclassified as an engine problem. [2009-11-19 16:00:14] k_radek at yahoo dot pl Description: Last paremeter defined in a function says that you can define constant with case-insensitive option but says nothing about that it allows you to REDEFINE constant... Reproduce code: --- --- >From manual page: function.define#Parameters --- "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values." Expected result: "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values. It allows you to redefine constant." Actual result: -- "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values." -- Edit this bug report at http://bugs.php.net/?id=50233&edit=1
#50233 [Opn]: This is not enought description.
ID: 50233 Updated by: bj...@php.net Reported By: k_radek at yahoo dot pl Status: Open -Bug Type: Documentation problem +Bug Type: Scripting Engine problem Operating System: GNU/Linux PHP Version: 5.2.11 New Comment: That makes no sense. Reclassified as an engine problem. Previous Comments: [2009-11-19 16:00:14] k_radek at yahoo dot pl Description: Last paremeter defined in a function says that you can define constant with case-insensitive option but says nothing about that it allows you to REDEFINE constant... Reproduce code: --- --- >From manual page: function.define#Parameters --- "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values." Expected result: "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values. It allows you to redefine constant." Actual result: -- "If set to TRUE, the constant will be defined case-insensitive. The default behavior is case-sensitive; i.e. CONSTANT and Constant represent different values." -- Edit this bug report at http://bugs.php.net/?id=50233&edit=1
#50250 [Opn]: Exceptions can be thrown and caught in an autoload function
ID: 50250 Updated by: bj...@php.net Reported By: bran...@php.net Status: Open -Bug Type: SPL related +Bug Type: Scripting Engine problem Operating System: Irrelevent PHP Version: 5.3.1 New Comment: This is also true for __autoload(), not only spl_register_autoload(). Bug or expected behavior as of PHP 5.3.0? Previous Comments: [2009-11-20 19:50:03] bran...@php.net Description: According to the PHP documentation, exceptions cannot be thrown inside __autoload() functions, and prior to PHP 5.3, exceptions thrown resulted in fatal errors. Since PHP 5.3, it has been possible to throw and catch exceptions from __autoload() functions. I'm happy to chalk this up to a documentation bug, and if it is I will gladly fix it myself; however, I want to make sure this is intended functionality and not an accidental inclusion that might be fixed in future versions of PHP. Reproduce code: --- http://bugs.php.net/?id=50250&edit=1
#49267 [Asn]: Linking fails for iconv: "Undefined symbols: _libiconv"
ID: 49267 Updated by: bj...@php.net Reported By: s dot rost at ewerk dot com Status: Assigned Bug Type: Compile Failure Operating System: Mac OSX 10.6 Snow Leopard PHP Version: 5.3, 6 (2009-08-18) Assigned To: scottmac New Comment: This issue looks like the same issue as I fixed on FreeBSD some years ago. If I can access to that OSX platform I'm sure I can fix it while Scott is away.. Previous Comments: [2009-09-23 23:53:35] mattcsl at gmail dot com For php-5.3.0, php-5.3.1RC1, and a snapshot build I have tried adding -lresolv to EXTRA_LIBS and MH_BUNDLE_FLAGS in Makefile I have edited ext/iconv/iconv.c like the thread has said. I even patched iconv.c with the patch that was posted at the end of this thread. Absolutely none of this solves the linking problem! This is seriously ruining my day. Why is this not working Mac OS X 10.6.1 ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/local/mysql --enable-zip --enable-ftp --with-gd --with-jpeg-dir=/usr/local/lib --with-curl --with-iconv-dir=/usr Undefined symbols: "_libiconv_open", referenced from: _do_convert in gdkanji.o __php_iconv_strlen in iconv.o _php_iconv_string in iconv.o __php_iconv_strpos in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_factory_create in iconv.o "_libiconv", referenced from: _do_convert in gdkanji.o __php_iconv_strlen in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strpos in iconv.o __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o "_libiconv_close", referenced from: _do_convert in gdkanji.o __php_iconv_strlen in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strpos in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_substr in iconv.o _php_iconv_stream_filter_dtor in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 [2009-09-15 22:26:59] j dot jeising at gmail dot com Apple already added a path to it's own sources: http://opensource.apple.com/source/apache_mod_php/apache_mod_php- 53/patches/iconv.patch With the parameters provided in the Makefile this works seamless: --with-iconv-dir=/usr [2009-09-15 19:29:50] skovjuice at gmail dot com I had this issue on OSX 10.6: Undefined symbols: "_libiconv_open", referenced from: _do_convert in gdkanji.o "_libiconv", referenced from: _do_convert in gdkanji.o "_libiconv_close", referenced from: _do_convert in gdkanji.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 Managed to solve it by doing as described in the first post on the latest PHP 5.3 snapshot. [2009-09-11 14:20:59] jason at dajaney dot com I am also experiencing this same issue on my new mac, running 10.6. Keep this alive with any updates. Undefined symbols: "_libiconv_open", referenced from: _do_convert in gdkanji.o "_libiconv", referenced from: _do_convert in gdkanji.o "_libiconv_close", referenced from: _do_convert in gdkanji.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 The above was trying my last ditch effort to have --without-iconv in the ./configure statement. Jason [2009-09-09 20:34:20] rickdunn at chez dot com For what it's worth, this is probably the same iconv issue that has already popped up in bug #43189 and bug #48195. The remainder of the comments for this report are too long. To view the rest of the comm
#48856 [Fbk->Asn]: PDO_Statement->bindParam binds multiple parameters of the same name
ID: 48856
Updated by: bj...@php.net
Reported By: dhammari at q90 dot com
-Status: Feedback
+Status: Assigned
Bug Type: PDO related
Operating System: Linux 2.6.27-gentoo-r8
PHP Version: 5.2.10
-Assigned To: bjori
+Assigned To: dbs
New Comment:
No idea. Its been like this for almost 4years..
Dan? Was this originally a limitation in PDO?
Previous Comments:
[2009-09-23 16:17:57] sjo...@php.net
Bjori, do you know why this was in the documentation?
[2009-07-08 20:04:01] dhammari at q90 dot com
Description:
My PDO Statement seems to bind multiple parameters of the same name
even though the PDO->Prepare documentation indicates that this should
fail: "You cannot use a named parameter marker of the same name twice in
a prepared statement." Nevertheless, my SQL statement that is reusing
the same parameter is getting through and returning a valid result set
from a MySQL engine.
PHP Version: 5.2.9-pl2-gentoo
System: Linux 2.6.27-gentoo-r8
Reproduce code:
---
= :myParameter AND
LENGTH(name) > :myParameter AND 1 = :myParameter";
$params = array("myParameter" => 1);
$statement = $pdo->prepare($sql);
foreach($params as $key => $value){
$statement->bindParam(":".$key, $value);
}
$statement->debugDumpParams();
$success = $statement->execute();
if(!$success){
echo("\nSQL FAILED\n");
var_dump($pdo->errorInfo());
var_dump($statement->errorInfo());
}
else{
echo("\nSQL SUCCEEDED\n");
$result = $statement->fetchALL(PDO::FETCH_ASSOC);
var_dump($result);
}
?>
Expected result:
I expect to see the following error:
Invalid parameter number: number of bound variables does not match
number of tokens
SQL FAILED
array
0 => string '0' (length=5)
array
0 => string 'HY093' (length=5)
Actual result:
--
Instead, I get the following:
SQL SUCCEEDED
array
0 =>
array
'id' => string '1' (length=1)
'Name' => string 'Binds Both Parameters' (length=21)
'Description' => string 'Seems to bind both parameters'
(length=29)
1 =>
array
'id' => string '2' (length=1)
'Name' => string 'Binds All Parameters' (length=20)
'Description' => string 'Seems to bind all parameters'
(length=28)
--
Edit this bug report at http://bugs.php.net/?id=48856&edit=1
#49578 [Asn->Csd]: make install-pear fails
ID: 49578 Updated by: bj...@php.net Reported By: mamfelt at gmail dot com -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: AIX 6.1.3 PHP Version: 5.2.10 Assigned To: bjori New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. The make install-pear problem has been fixed. Previous Comments: [2009-09-17 11:36:30] s...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=288404 Log: Fixed bug#49578 (make install-pear fails) # Apparently this script was using 5.3 functionality # Workaround would be to install 'wget' [2009-09-17 11:19:07] mamfelt at gmail dot com I can edit my config file. I have used, updated this command since php 4.4.X - at least on AIX they were needed. For some reason, ./configure does not find the jpeg things unless I give the path. Background info - not releated to the bug I hope - It is quite confusing between different versions of AIX as AIX also has a libssl.a and libcrypt.a (with a .so file in them) while the libraries I am building my self are filled with the .o files. When I compiled on AIX 5.2 and 5.3 (before the libs I just mentioned were in /usr/lib) I did not need to export the LIBPATH before I built any packages. getting curl to load properly as a shared library has forced me to do this - otherwise the libcurl does not load. I suspect it has to do with libtool not being up to date for AIX - that used to be the magic wand for PHP (4.0.X versions). And, I am wondering if I need to check flags for the openssl package I also compile myself. === Closing: if there is a new configure command you would like me to run, just post, or mail, and I'll run it as soon as I can. Just let me know (link please) if you want me to use a new snap, or stay with this one. [2009-09-17 11:11:22] bj...@php.net This is actually my fault. Quick fix: install 'wget'. [2009-09-17 11:05:00] j...@php.net Change the assigned to, according to Pierre, Greg is responsible for this part. [2009-09-17 11:04:59] j...@php.net Change the assigned to, according to Pierre, Greg is responsible for this part. 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/49578 -- Edit this bug report at http://bugs.php.net/?id=49578&edit=1
#49578 [Asn]: make install-pear fails
ID: 49578
Updated by: bj...@php.net
Reported By: mamfelt at gmail dot com
Status: Assigned
Bug Type: Compile Failure
Operating System: AIX 6.1.3
PHP Version: 5.2.10
-Assigned To: cellog
+Assigned To: bjori
New Comment:
This is actually my fault.
Quick fix: install 'wget'.
Previous Comments:
[2009-09-17 11:05:00] j...@php.net
Change the assigned to, according to Pierre, Greg is responsible for
this part.
[2009-09-17 11:04:59] j...@php.net
Change the assigned to, according to Pierre, Greg is responsible for
this part.
[2009-09-17 11:01:32] j...@php.net
Those flags aren't quite right. There isn't any options in the
(--with|--enable) family in PHP configure which expects you to give any
paths to /xxx/lib ( /usr/local/lib should be /usr/local )
But it's not the reason pear install fails, that's more inherent
problem with bad design in how pear is installed from some obscure phar
thing. Assigned to maintainer.
[2009-09-17 10:36:39] mamfelt at gmail dot com
Description:
after getting the flags right for a straight forward configure and
make, make install-pear fails.
code snippet: no fix!
line 64 through 66:
$ctx = stream_context_create($copt, array("notification" =>
"stream_notification_callback"));
$fp = fopen($argv[1], "r", false, $ctx);
AIX 6.1.3, xlC compiler (v7)
Reproduce code:
---
export
LIBPATH=/usr/lib:/usr/local/ssl/lib:/usr/local/lib:/usr/vac/lib:/usr/vacpp/lib
./configure \
--enable-safe-mode --enable-magic-quotes \
--with-openssl=/usr/local/ssl \
--with-zlib-dir=/data/prj/zlib-1.2.3 \
--disable-bcmath \
--enable-dba --enable-ftp \
--with-gd --with-jpeg-dir=/usr/local/lib \
--with-ttf--with-curlwrappers \
--with-curl --with-freetype-dir \
--enable-gd-native-ttf \
--with-mysql=/usr/local/mysql \
--with-pear=/usr/local/bin
make
make install
Expected result:
installed php
Actual result:
--
mich...@x054:[/data/home/michael/prj/php5.2-200909161430]make install
Installing PHP SAPI module: cgi
Installing PHP CGI binary: /usr/local/bin/
Installing PHP CLI binary:/usr/local/bin/
Installing PHP CLI man page: /usr/local/man/man1/
Installing build environment: /usr/local/lib/php/build/
Installing header files: /usr/local/include/php/
Installing helper programs: /usr/local/bin/
program: phpize
program: php-config
Installing man pages: /usr/local/man/man1/
page: phpize.1
page: php-config.1
Installing PEAR environment: /usr/local/bin/
Warning: stream_context_create() expects at most 1 parameter, 2 given
in /data/prj/php5.2-200909161430/pear/fetch.php on line 64
Warning: fopen() expects parameter 4 to be resource, boolean given in
/data/prj/php5.2-200909161430/pear/fetch.php on line 66
Error..
fopen() expects parameter 4 to be resource, boolean given
make: *** [install-pear] Error 1
--
Edit this bug report at http://bugs.php.net/?id=49578&edit=1
#49309 [Opn->Csd]: bjori
ID: 49309 Updated by: bj...@php.net Reported By: hannes dot magnusson at gmail dot com -Status: Open +Status: Closed -Bug Type: a CC:bj...@php.net +Bug Type: *General Issues Operating System: foo PHP Version: 5.3.0 New Comment: should be ok now :) Previous Comments: [2009-08-20 09:25:40] bj...@php.net [2009-08-20 09:24:34] hannes dot magnusson at gmail dot com Description: Last try ;) -- Edit this bug report at http://bugs.php.net/?id=49309&edit=1
#49309 [Opn]: bjori
ID: 49309 Updated by: bj...@php.net Reported By: hannes dot magnusson at gmail dot com Status: Open -Bug Type: *General Issues CC:bj...@php.ne +Bug Type: a CC:bj...@php.net Operating System: foo PHP Version: 5.3.0 New Comment: Previous Comments: [2009-08-20 09:24:34] hannes dot magnusson at gmail dot com Description: Last try ;) -- Edit this bug report at http://bugs.php.net/?id=49309&edit=1
#48835 [Opn->Asn]: all test of 'make test' fail with old local php.ini
ID: 48835 Updated by: bj...@php.net Reported By: andreas dot rieber at 2e-systems dot com -Status: Open +Status: Assigned Bug Type: Unknown/Other Function Operating System: opensuse PHP Version: 5.3.0 -Assigned To: +Assigned To: kalle New Comment: :( Previous Comments: [2009-07-07 13:17:47] andreas dot rieber at 2e-systems dot com Description: 'make test' uses the systems /usr/local/lib/php.ini with 5.2.10 configuration and so all test failed. After i unkommented some lines, the tests passed: > ;magic_quotes_gpc = On > ;magic_quotes_runtime = Off > ;magic_quotes_sybase = Off > ;define_syslog_variables = On -- Edit this bug report at http://bugs.php.net/?id=48835&edit=1
#48736 [Opn->Bgs]: ReflectionMethod::getParemeters() does not return parameters of memcache::set()
ID: 48736
Updated by: bj...@php.net
Reported By: fhardy at noparking dot net
-Status: Open
+Status: Bogus
Bug Type: Reflection related
Operating System: freeBSD 7.1
PHP Version: 5.2.10
New Comment:
memcache does not expose these argument information.
Please refile this as a bug against the extension on pecl.php.net
Previous Comments:
[2009-06-30 12:25:32] fhardy at noparking dot net
Description:
ReflectionMethod::getParemeters() does not return parameters of
memcache::set().
Reproduce code:
---
$method = new reflectionMethod('memcache', 'set');
echo (sizeof($method->getParameters()) ? 'OK' : 'KO');
Expected result:
'OK'
Actual result:
--
'KO'
--
Edit this bug report at http://bugs.php.net/?id=48736&edit=1
#48578 [Opn->Ctl]: Can't build 5.3 on FBSD 4.11
ID: 48578 Updated by: bj...@php.net Reported By: hannes dot magnusson at gmail dot com -Status: Open +Status: Critical Bug Type: Compile Failure Operating System: FreeBSD 4.11 PHP Version: 5.3CVS-2009-06-17 (snap) Previous Comments: [2009-06-17 08:02:22] hannes dot magnusson at gmail dot com Description: /bin/sh /usr/home/bjori/php5.3-200906170630/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic -Iext/fileinfo/ -I/usr/home/bjori/php5.3-200906170630/ext/fileinfo/ -DPHP_ATOM_INC -I/usr/home/bjori/php5.3-200906170630/include -I/usr/home/bjori/php5.3-200906170630/main -I/usr/home/bjori/php5.3-200906170630 -I/usr/home/bjori/php5.3-200906170630/ext/date/lib -I/usr/home/bjori/php5.3-200906170630/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/bjori/php5.3-200906170630/ext/sqlite3/libsqlite -I/usr/home/bjori/php5.3-200906170630/TSRM -I/usr/home/bjori/php5.3-200906170630/Zend-I/usr/local/include -g -O2 -c /usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic/cdf.c -o ext/fileinfo/libmagic/cdf.lo /usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic/cdf.c:35: warning: `__used__' attribute directive ignored /usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic/cdf.c: In function `cdf_read_sat': /usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic/cdf.c:331: `UINT32_MAX' undeclared (first use in this function) /usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic/cdf.c:331: (Each undeclared identifier is reported only once /usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic/cdf.c:331: for each function it appears in.) /usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic/cdf.c: In function `cdf_read_property_info': /usr/home/bjori/php5.3-200906170630/ext/fileinfo/libmagic/cdf.c:700: `UINT32_MAX' undeclared (first use in this function) *** Error code 1 Stop in /usr/home/bjori/php5.3-200906170630. -bash-2.05b$ uname -a FreeBSD pb11.pair.com 4.11-STABLE FreeBSD 4.11-STABLE #1: Tue May 3 13:17:19 EDT 2005 r...@pb11.pair.com:/usr/obj/usr/src/sys/NEWPB11 i386 -bash-2.05b$ gcc -v Using builtin specs. gcc version 2.95.4 20020320 [FreeBSD] Reproduce code: --- ./configure && make -- Edit this bug report at http://bugs.php.net/?id=48578&edit=1
#48540 [Opn->Asn]: server issue at php.net (subdomain ca2)
ID: 48540 Updated by: bj...@php.net Reported By: neuroxik at gmail dot com -Status: Open +Status: Assigned Bug Type: Unknown/Other Function Operating System: Win XP (SP2) PHP Version: 5.2.9 -Assigned To: +Assigned To: danbrown New Comment: Interesting. I can't seem to reproduce the error right now, so I am wondering if someone was messing manually with the server.. Previous Comments: [2009-06-13 05:15:02] neuroxik at gmail dot com Description: http://ca2.php.net/usleep - Canada's 2nd server (tried ca and ca3 subdomains, but only php's/your subdomain "ca2" seems to have issues) Maybe this is just temporary, but anyway, the line that your site returns is: Parse error: syntax error, unexpected T_LNUMBER, expecting T_VARIABLE or '$' in /home/ca2php/public_html/include/mirrors.inc on line 518 -- Edit this bug report at http://bugs.php.net/?id=48540&edit=1
#48298 [Opn->Fbk]: php_gd2.dll doesn not exist
ID: 48298 Updated by: bj...@php.net Reported By: tommad at htmail dot com -Status: Open +Status: Feedback -Bug Type: Doc Build problem +Bug Type: *Configuration Issues Operating System: Solaris 10 -PHP Version: Irrelevant +PHP Version: 5 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. What is "Sun-provided PHP"? And why would a Windows DLL work on Solaris? Previous Comments: [2009-05-15 19:26:04] tommad at htmail dot com Description: Installed latest Sun-provided PHP package. Cannot access G at all since the php_gd2.dll file does not exist anywhere on the sytem. I have removed the semicolon for this extension within the php.ini file. but of course that does no good without the dll itself being present. No error messages are generated, and the PHPINFO display does not mention GD at all. -- Edit this bug report at http://bugs.php.net/?id=48298&edit=1
#48220 [Opn->Bgs]: idn_to_ascii: $errorcode is NULL
ID: 48220
Updated by: bj...@php.net
Reported By: fh-phpbug at fholzhauer dot de
-Status: Open
+Status: Bogus
Bug Type: I18N and L10N related
Operating System: Ubuntu
PHP Version: 5.3.0RC2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Unfortunately the docs are about the pecl/idn extension, not the PHP5.3
ext/intl extension (which includes that function).
Previous Comments:
[2009-05-10 12:08:42] fh-phpbug at fholzhauer dot de
Description:
The optional parameter $errorcode in idn_to_ascii() should return the
IDNA error code, but is NULL after an error.
See the example in the PHP documentation
(http://de.php.net/manual/en/function.idn-to-ascii.php) for a
description of the expected behaviour.
http://pastebin.com/m55d27e3c provides a PHPT testcase.
Reproduce code:
---
http://de.php.net/manual/en/function.idn-to-ascii.php -> example
idn_to_ascii("xn--".chr(0xC3).chr(0xA4),$errorcode);
var_dump($errorcode);
?>
Expected result:
int(8)
Actual result:
--
NULL
--
Edit this bug report at http://bugs.php.net/?id=48220&edit=1
#45280 [Opn->Fbk]: Reflection of instantiated COM classes causes PHP to crash.
ID: 45280
Updated by: bj...@php.net
Reported By: RQuadling at GMail dot com
-Status: Open
+Status: Feedback
Bug Type: COM related
Operating System: Windows XP SP2
PHP Version: 5.3CVS-2008-06-16 (snap)
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Previous Comments:
[2008-06-16 13:37:00] RQuadling at GMail dot com
I forgot to mention that the function com_print_typeinfo() does provide
some of the information I'm expecting to be available via Reflection.
[2008-06-16 13:35:15] RQuadling at GMail dot com
Description:
Hi.
I'm trying to use PHP to find out about the COM interface of Crystal
Reports XI.
I can use ...
php -r "ReflectionClass::export('COM');"
which shows the empty 'COM' class extending the 'variant' class.
But if I try and use ...
php -r "ReflectionObject::export(New
COM('CrystalReports11.ObjectFactory.1'));"
I get a crash and a request to send a report to Microsoft.
Reproduce code:
---
http://bugs.php.net/?id=45280&edit=1
#45092 [Tbd->Csd]: header HTTP context option not being used (--with-curlwrappers)
ID: 45092
Updated by: bj...@php.net
Reported By: nweibley at gmail dot com
-Status: To be documented
+Status: Closed
Bug Type: Streams related
Operating System: Linux (Gentoo)
PHP Version: 5.2.6
New Comment:
Docs updated
Previous Comments:
[2009-05-05 01:05:43] nweibley at gmail dot com
Thanks for the update!
[2009-05-05 00:34:47] j...@php.net
As of PHP 5.9.10 you can pass either string or array (simple array, not
any key => value pairs!) regardless if you used --with-curlwrappers
option or not.
[2008-05-26 15:34:59] nweibley at gmail dot com
Ah, came to the solution.
Line 332 of ext/curl/streams.c:
if (Z_TYPE_PP(header) == IS_STRING) {
Ergo, each element of the array passed as the value of the 'header'
context option *must* be a string, not an associative key=>value pair.
I'd propose this be more clearly documented or an additional conditional
branch be added to ext/curl/streams.c to handle key=>value array pairs
and especially a simple string as the header context option.
This is the behavior when --with-curlwrappers is not used, and it seems
highly logical that it would still stand with curlwrappers enabled.
[2008-05-26 15:27:37] nweibley at gmail dot com
Since line 324 of ext/curl/streams.c reads:
if (SUCCESS == php_stream_context_get_option(context, "http", "header",
&ctx_opt) && Z_TYPE_PP(ctx_opt) == IS_ARRAY) {
I have changed my code to reflect passing an array as the value of
'header' in the context options. The problem still persists, however.
[2008-05-26 15:16:09] nweibley at gmail dot com
Description:
Pretty simple; I'm trying to create a stream context which will send
custom headers along with a simple HTTP GET request. It wasn't working
so I created a second debug script to see what was up and found that PHP
simply isn't including any of my custom headers.
This *is not* a duplicate of bug #41051, I have tried that as well.
Reproduce code:
---
array('method' => 'GET','header' => "Custom:
woot"));
$ctx = stream_context_create($params);
$fp = fopen('http://localhost/recv.php', 'r', false, $ctx);
print_r(stream_context_get_options($ctx));
print_r(stream_get_meta_data($fp));
echo stream_get_contents($fp);
?>
Expected result:
Array
(
[http] => Array
(
[method] => GET
[header] => Custom: woot
)
)
Array
(
[wrapper_data] => Array
(
[headers] => Array
(
)
[readbuf] => Resource id #4
)
[wrapper_type] => cURL
[stream_type] => cURL
[mode] => r
[unread_bytes] => 0
[seekable] =>
[uri] => http://localhost/404.php
[timed_out] =>
[blocked] => 1
[eof] =>
)
Array
(
[User-Agent] => PHP/5.2.6-pl1-gentoo
[Host] => localhost
[Accept] => */*
[Custom] => woot
)
Actual result:
--
Array
(
[http] => Array
(
[method] => GET
[header] => Custom: woot
)
)
Array
(
[wrapper_data] => Array
(
[headers] => Array
(
)
[readbuf] => Resource id #4
)
[wrapper_type] => cURL
[stream_type] => cURL
[mode] => r
[unread_bytes] => 0
[seekable] =>
[uri] => http://localhost/recv.php
[timed_out] =>
[blocked] => 1
[eof] =>
)
Array
(
[User-Agent] => PHP/5.2.6-pl1-gentoo
[Host] => localhost
[Accept] => */*
)
--
Edit this bug report at http://bugs.php.net/?id=45092&edit=1
#48034 [Ver]: PHP crashes when script is 8192 (8KB) bytes long
ID: 48034 Updated by: bj...@php.net Reported By: ninzya at inbox dot lv Status: Verified Bug Type: Reproducible crash Operating System: * -PHP Version: 5.*, 6CVS (2009-04-21) +PHP Version: 5.3CVS, 6CVS (2009-04-21) New Comment: See also bug#48043 Previous Comments: [2009-04-21 17:20:21] ninzya at inbox dot lv I did everything mentioned in http://bugs.php.net/bugs-generating-backtrace-win32.php and got these results: Thread 250 - System ID 5552 Entry point msvcrt!_endthreadex+3a Create time 21.04.2009 15:20:51 Time spent in user mode 0 Days 0:0:0.656 Time spent in kernel mode 0 Days 0:0:0.921 Function Arg 1 Arg 2 Arg 3 Source php5ts!lex_scan+447c 0550fa34 010f54a0 002f php5ts!zend_register_auto_global+11f [2009-04-21 15:31:46] lbarn...@php.net It seems related to http://bugs.php.net/bug.php?id=47596 . Not exactly the same problem, though. It seems php_stream_open_for_zend() does not mmap() enough for ZEND_MMAP_AHEAD (PHP_STREAM_OPTION_MMAP_API in plain_wrapper adjusts the mmap length to the filesize, so ignoring ZEND_MMAP_AHEAD), and this may crash when the parser reads ahead of the mmap()ed region. [2009-04-21 11:50:51] ninzya at inbox dot lv PHP is installed as apache module. No fancy filtering, default php/apache installation. All php modules disabled. Bug hits only if file size is 8KB exactly (8192 bytes). PHP 5.2.9 also is affected. By the way, Apache 2.2 is not affected. Seems this is apache 2.0 specific problem. Don't know where to post this issue, here, or in Apache bugtracker. [2009-04-21 11:40:31] j...@php.net Which apache module? Do you have some fancy filtering going on? Does this happen with PHP 5.2.9 ? Do you have any shared extensions loaded? Any Zend extensions like debugger or cache? (disable those and retry) [2009-04-21 11:27:52] ninzya at inbox dot lv http://www.stepanov.lv/pub/bug48034.txt <-- php file contents PHP as module. It crashes by displaying "Apache.exe - Application error" window, saying "The instruction at 0x0085779c referenced memory at 0x061e2000 (this actually varies). The memory could not be read. Click OK to terminate the program." (BTW, what is your formula for bogusness percentage?) 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/48034 -- Edit this bug report at http://bugs.php.net/?id=48034&edit=1
#47829 [Bgs->Opn]: Segmentation fault on startup with PDO Firebird compiled in
ID: 47829
Updated by: bj...@php.net
Reported By: info at programmiernutte dot net
-Status: Bogus
+Status: Open
Bug Type: Reproducible crash
Operating System: Debian Etch x86_64
PHP Version: 5.3.0RC1
New Comment:
PDO_firebird is not a PECL extension.
Previous Comments:
[2009-03-31 06:58:24] j...@php.net
Please report PECL extension bugs at http://pecl.php.net/bugs/
[2009-03-29 21:51:51] info at programmiernutte dot net
I did some more experimenting, and I figured that the Crash does not
occur when PDO Firebird is compiled as a shared module and loaded as
extension. PDO Extension seems to work.
[2009-03-29 16:11:42] info at programmiernutte dot net
Description:
I am getting Segmentation fault on startup, no matter if SAPI apache 2
or CLI. Same Version of PHP and same Firebird Version (2.1.1.) are
running flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related?
I used gdb to track this down to PDO Firebird Initialisation Startup:
(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce->type & ZEND_INTERNAL_CLASS) {
(gdb) where
#0 zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1 0x005190c2 in zm_startup_pdo_firebird (type=, module_number=)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2 0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3 0x00625f05 in zend_hash_apply (ht=0xc62e80,
apply_func=0x61cec0 )
at /usr/src/php-5.3.0RC1/Zend/zend_hash.c:673
#4 0x0061d89a in zend_startup_modules () at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1642
#5 0x005c827f in php_module_startup (sf=,
additional_modules=0x0, num_additional_modules=0)
at /usr/src/php-5.3.0RC1/main/main.c:1952
#6 0x006a0e5d in php_cli_startup (sapi_module=0x0) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:370
#7 0x006a155f in main (argc=1, argv=0x7fff63c23928) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:742
--
Edit this bug report at http://bugs.php.net/?id=47829&edit=1
