Bug #37899 [Com]: [PATCH] php_char_to _OLECHAR copies junk bytes
Edit report at https://bugs.php.net/bug.php?id=37899&edit=1
ID: 37899
Comment by: potyomkine at gmail dot com
Reported by:okumurya at gmail dot com
Summary:[PATCH] php_char_to _OLECHAR copies junk bytes
Status: Assigned
Type: Bug
Package:COM related
Operating System: Windows 2000 Professional
PHP Version:5.2.3
Assigned To:wharmby
Block user comment: N
Private report: N
New Comment:
I also have the same problem with PHP 5.2.17.
Previous Comments:
[2008-10-21 20:20:35] vincent at eal dot com
I also have the same problem with PHP 5.2.3.
[2007-08-24 12:16:11] j...@php.net
Assigned to the maintainer.
[2007-08-12 07:14:23] okumurya at gmail dot com
I tested on PHP-5.2.3, and the problem still occured.
[2007-08-12 07:04:37] okumurya at gmail dot com
I tested following code on PHP-4.4.7, the problem still occured.
http://ml.php.gr.jp/pipermail/php-users/2007-April/032463.html
*/
ini_set('mbstring.language', 'Japanese');
ini_set('mbstring.internal_encoding', 'UTF-8');
class setWord {
var $Word;
var $doc;
function setWord(){
$this->Word = new COM('Word.Application');
$this->Word->Visible = false;
$this->Word->DisplayAlerts = 0;
}
function documentOpen(){
$this->doc = $this->Word->Documents->Add();
$this->doc->Activate;
}
function setParam($param){
$this->Word->Selection->TypeText($param);
}
function SaveAs(){
$this->Word->Documents[1]->SaveAs("C:/TMP/hoge.doc");
}
function unsetObj(){
$this->Word->Documents[1]->Close();
$this->Word->Quit();
$this->Word = null;
}
function returnWord($param){
$this->documentOpen();
$this->setParam($param);
$this->SaveAs();
$this->unsetObj();
}
}
$cls = new setWord();
$cls->returnWord("\x82\xA0\x82\xA2\x82\xA4\x82\xA6\x82\xA8"); // Japanese
Hiragana A I U E O
?>
[2007-07-11 12:49:49] j...@php.net
And does this problem exist in PHP 5.2.3? (see also previous comment by Stas)
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=37899
--
Edit this bug report at https://bugs.php.net/bug.php?id=37899&edit=1
[PHP-BUG] Bug #61649 [NEW]: zend gc should not mark persistent hashtable
From: laruence
Operating system:
PHP version: 5.3.10
Package: Scripting Engine problem
Bug Type: Bug
Bug description:zend gc should not mark persistent hashtable
Description:
zend gc was introducted in 5.3
thinking of a zval which is a Hashtable allocated by a extension in
persistent,
and it also has hashtable children in it,
then , if the extension return this to php script:
array_init(return_value);
zend_hash_copy(Z_ARRVAL_P(return_value),
Z_ARRVAL_P(persitent_zval_hashtable),
***)..
since zval_copy_ctor does shallow copy, so the persistent array return to
the
php
script.
then if it happen to be parsed by zval_ptr_dtor, then the persistent array
will
be
parsed by gc_zval_possible_root,
ZEND_API void gc_zval_possible_root(zval *zv TSRMLS_DC)
{
..
if (GC_ZVAL_GET_COLOR(zv) != GC_PURPLE) {
GC_ZVAL_SET_PURPLE(zv);
..
then the malloc info of the block(not sure before or after) will be
polluted.
then when the extension try to free the block, a warning will be show
like:
munmap_chunk(): invalid pointer 0x***
Test script:
---
none
Expected result:
none
Actual result:
--
none
--
Edit bug report at https://bugs.php.net/bug.php?id=61649&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61649&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61649&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61649&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61649&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61649&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61649&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61649&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61649&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61649&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61649&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61649&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61649&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61649&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61649&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61649&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61649&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61649&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61649&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61649&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61649&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61649&r=mysqlcfg
Bug #61649 [PATCH]: zend gc should not mark persistent hashtable
Edit report at https://bugs.php.net/bug.php?id=61649&edit=1
ID: 61649
Patch added by: larue...@php.net
Reported by:larue...@php.net
Summary:zend gc should not mark persistent hashtable
Status: Open
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61649.patch
Revision: 1333714735
URL:
https://bugs.php.net/patch-display.php?bug=61649&patch=bug61649.patch&revision=1333714735
Previous Comments:
[2012-04-06 12:17:59] larue...@php.net
Description:
zend gc was introducted in 5.3
thinking of a zval which is a Hashtable allocated by a extension in persistent,
and it also has hashtable children in it,
then , if the extension return this to php script:
array_init(return_value);
zend_hash_copy(Z_ARRVAL_P(return_value), Z_ARRVAL_P(persitent_zval_hashtable),
***)..
since zval_copy_ctor does shallow copy, so the persistent array return to the
php
script.
then if it happen to be parsed by zval_ptr_dtor, then the persistent array will
be
parsed by gc_zval_possible_root,
ZEND_API void gc_zval_possible_root(zval *zv TSRMLS_DC)
{
..
if (GC_ZVAL_GET_COLOR(zv) != GC_PURPLE) {
GC_ZVAL_SET_PURPLE(zv);
..
then the malloc info of the block(not sure before or after) will be polluted.
then when the extension try to free the block, a warning will be show like:
munmap_chunk(): invalid pointer 0x***
Test script:
---
none
Expected result:
none
Actual result:
--
none
--
Edit this bug report at https://bugs.php.net/bug.php?id=61649&edit=1
Bug #61649 [Opn]: zend gc should not mark persistent hashtable
Edit report at https://bugs.php.net/bug.php?id=61649&edit=1
ID: 61649
Updated by: larue...@php.net
Reported by:larue...@php.net
Summary:zend gc should not mark persistent hashtable
Status: Open
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.10
-Assigned To:
+Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
dmitry, could you plz look at this, thanks :)
Previous Comments:
[2012-04-06 12:18:55] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61649.patch
Revision: 1333714735
URL:
https://bugs.php.net/patch-display.php?bug=61649&patch=bug61649.patch&revision=1333714735
[2012-04-06 12:17:59] larue...@php.net
Description:
zend gc was introducted in 5.3
thinking of a zval which is a Hashtable allocated by a extension in persistent,
and it also has hashtable children in it,
then , if the extension return this to php script:
array_init(return_value);
zend_hash_copy(Z_ARRVAL_P(return_value), Z_ARRVAL_P(persitent_zval_hashtable),
***)..
since zval_copy_ctor does shallow copy, so the persistent array return to the
php
script.
then if it happen to be parsed by zval_ptr_dtor, then the persistent array will
be
parsed by gc_zval_possible_root,
ZEND_API void gc_zval_possible_root(zval *zv TSRMLS_DC)
{
..
if (GC_ZVAL_GET_COLOR(zv) != GC_PURPLE) {
GC_ZVAL_SET_PURPLE(zv);
..
then the malloc info of the block(not sure before or after) will be polluted.
then when the extension try to free the block, a warning will be show like:
munmap_chunk(): invalid pointer 0x***
Test script:
---
none
Expected result:
none
Actual result:
--
none
--
Edit this bug report at https://bugs.php.net/bug.php?id=61649&edit=1
[PHP-BUG] Bug #61650 [NEW]: ini parser crashes when using ${xxxx} ini variables ( without apache2 )
From:
Operating system: Redhat 5.8
PHP version: 5.3.10
Package: CGI/CLI related
Bug Type: Bug
Bug description:ini parser crashes when using ${} ini variables ( without
apache2 )
Description:
Hello,
PHP-CGI keeps crashing when loading configuration file with variable in
file. Variable are declared as ENV ones.
It doesn't crash if the variable is undefined.
I Think this bug is related to this one already corrected but only for
apache2 thing : https://bugs.php.net/bug.php?id=49677
sapi_getenv (NO apache2) versus php_apache_sapi_getenv (apache2)
Test script:
---
Into php.ini file :
error_log = ${titi}
Expected result:
PHP should not crash.
Actual result:
--
(gdb) backtrace
#0 0x in ?? ()
#1 0x0063ed5a in sapi_getenv (name=0x14fcff10 "toto",
name_len=) at
/usr/src/debug/php-5.3.10/main/SAPI.c:947
#2 0x00664224 in zend_ini_get_var () at
/usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:225
#3 ini_parse () at /usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:1840
#4 0x0066431e in zend_parse_ini_file (fh=0x7fff6b56ab40,
unbuffered_errors=1 '\001', scanner_mode=,
ini_parser_cb=,
arg=) at
/usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:283
#5 0x0063dbe3 in php_init_config () at
/usr/src/debug/php-5.3.10/main/php_ini.c:620
#6 0x006371ca in php_module_startup (sf=,
additional_modules=0xc2ef80, num_additional_modules=1) at
/usr/src/debug/php-5.3.10/main/main.c:2012
#7 0x0070a633 in php_cgi_startup (sapi_module=0x4) at
/usr/src/debug/php-5.3.10/sapi/cgi/cgi_main.c:883
#8 0x0070ada8 in main (argc=3, argv=0x7fff6b56d3d8) at
/usr/src/debug/php-5.3.10/sapi/cgi/cgi_main.c:1623
--
Edit bug report at https://bugs.php.net/bug.php?id=61650&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61650&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61650&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61650&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61650&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61650&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61650&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61650&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61650&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61650&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61650&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61650&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61650&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61650&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61650&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61650&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61650&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61650&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61650&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61650&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61650&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61650&r=mysqlcfg
Bug #61650 [Com]: ini parser crashes when using ${xxxx} ini variables ( without apache2 )
Edit report at https://bugs.php.net/bug.php?id=61650&edit=1
ID: 61650
Comment by: ni...@php.net
Reported by:e dot tirado at meetic-corp dot com
Summary:ini parser crashes when using ${} ini variables
( without apache2 )
Status: Open
Type: Bug
Package:CGI/CLI related
Operating System: Redhat 5.8
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I can't reproduce this:
nikic@pluto:~/dev$ cat php.ini
error_log = ${ERROR_LOG}
nikic@pluto:~/dev$ ERROR_LOG=foo php -c php.ini -i | grep error_log
error_log => foo => foo
Previous Comments:
[2012-04-06 13:02:55] e dot tirado at meetic-corp dot com
Description:
Hello,
PHP-CGI keeps crashing when loading configuration file with variable in
file. Variable are declared as ENV ones.
It doesn't crash if the variable is undefined.
I Think this bug is related to this one already corrected but only for apache2
thing : https://bugs.php.net/bug.php?id=49677
sapi_getenv (NO apache2) versus php_apache_sapi_getenv (apache2)
Test script:
---
Into php.ini file :
error_log = ${titi}
Expected result:
PHP should not crash.
Actual result:
--
(gdb) backtrace
#0 0x in ?? ()
#1 0x0063ed5a in sapi_getenv (name=0x14fcff10 "toto", name_len=) at /usr/src/debug/php-5.3.10/main/SAPI.c:947
#2 0x00664224 in zend_ini_get_var () at
/usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:225
#3 ini_parse () at /usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:1840
#4 0x0066431e in zend_parse_ini_file (fh=0x7fff6b56ab40,
unbuffered_errors=1 '\001', scanner_mode=,
ini_parser_cb=,
arg=) at
/usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:283
#5 0x0063dbe3 in php_init_config () at
/usr/src/debug/php-5.3.10/main/php_ini.c:620
#6 0x006371ca in php_module_startup (sf=,
additional_modules=0xc2ef80, num_additional_modules=1) at
/usr/src/debug/php-5.3.10/main/main.c:2012
#7 0x0070a633 in php_cgi_startup (sapi_module=0x4) at
/usr/src/debug/php-5.3.10/sapi/cgi/cgi_main.c:883
#8 0x0070ada8 in main (argc=3, argv=0x7fff6b56d3d8) at
/usr/src/debug/php-5.3.10/sapi/cgi/cgi_main.c:1623
--
Edit this bug report at https://bugs.php.net/bug.php?id=61650&edit=1
Bug #61650 [Opn->Csd]: ini parser crashes when using ${xxxx} ini variables ( without apache2 )
Edit report at https://bugs.php.net/bug.php?id=61650&edit=1
ID: 61650
Updated by: larue...@php.net
Reported by:e dot tirado at meetic-corp dot com
Summary:ini parser crashes when using ${} ini variables
( without apache2 )
-Status: Open
+Status: Closed
Type: Bug
Package:CGI/CLI related
Operating System: Redhat 5.8
PHP Version:5.3.10
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
actually, you should use a existed env variable name to trigger this bug.
fixed
Previous Comments:
[2012-04-06 13:43:10] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=9bf8cd4b3437f6335e20843c9e3668b44761feba
Log: Fixed bug #61650 (ini parser crashes when using ${} ini variables
(without apache2))
[2012-04-06 13:37:55] ni...@php.net
I can't reproduce this:
nikic@pluto:~/dev$ cat php.ini
error_log = ${ERROR_LOG}
nikic@pluto:~/dev$ ERROR_LOG=foo php -c php.ini -i | grep error_log
error_log => foo => foo
[2012-04-06 13:02:55] e dot tirado at meetic-corp dot com
Description:
Hello,
PHP-CGI keeps crashing when loading configuration file with variable in
file. Variable are declared as ENV ones.
It doesn't crash if the variable is undefined.
I Think this bug is related to this one already corrected but only for apache2
thing : https://bugs.php.net/bug.php?id=49677
sapi_getenv (NO apache2) versus php_apache_sapi_getenv (apache2)
Test script:
---
Into php.ini file :
error_log = ${titi}
Expected result:
PHP should not crash.
Actual result:
--
(gdb) backtrace
#0 0x in ?? ()
#1 0x0063ed5a in sapi_getenv (name=0x14fcff10 "toto", name_len=) at /usr/src/debug/php-5.3.10/main/SAPI.c:947
#2 0x00664224 in zend_ini_get_var () at
/usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:225
#3 ini_parse () at /usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:1840
#4 0x0066431e in zend_parse_ini_file (fh=0x7fff6b56ab40,
unbuffered_errors=1 '\001', scanner_mode=,
ini_parser_cb=,
arg=) at
/usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:283
#5 0x0063dbe3 in php_init_config () at
/usr/src/debug/php-5.3.10/main/php_ini.c:620
#6 0x006371ca in php_module_startup (sf=,
additional_modules=0xc2ef80, num_additional_modules=1) at
/usr/src/debug/php-5.3.10/main/main.c:2012
#7 0x0070a633 in php_cgi_startup (sapi_module=0x4) at
/usr/src/debug/php-5.3.10/sapi/cgi/cgi_main.c:883
#8 0x0070ada8 in main (argc=3, argv=0x7fff6b56d3d8) at
/usr/src/debug/php-5.3.10/sapi/cgi/cgi_main.c:1623
--
Edit this bug report at https://bugs.php.net/bug.php?id=61650&edit=1
Bug #61644 [Com]: crashes with preg_match
Edit report at https://bugs.php.net/bug.php?id=61644&edit=1 ID: 61644 Comment by: pio at rdl dot pl Reported by:pio at rdl dot pl Summary:crashes with preg_match Status: Open Type: Bug Package:Regexps related Operating System: Debian 6 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: OK,I have uploaded this file on server http://s71.vdl.pl/1.txt Piotr Previous Comments: [2012-04-06 03:37:47] larue...@php.net http://speedy.sh/YGJDR/1.txt 404 for me... [2012-04-05 21:34:05] pio at rdl dot pl The file 1.txt here is http://speedy.sh/YGJDR/1.txt [2012-04-05 21:31:32] pio at rdl dot pl Description: Hello ! We have problem with parse some data and regular expression match. I have attached the file 1.txt # /usr/local/php5.3/bin/php test.php Segmentation fault (gdb) run test.php Starting program: /usr/local/bin/php test.php [Thread debugging using libthread_db enabled] [New Thread 0x7f1659abb710 (LWP 14776)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f1659abb710 (LWP 14776)] 0x004bf9ff in match ( eptr=0x1632378 "nteria.pl;;\nmaciej...@o2.pl;;\nmaciej.len...@lumenpolska.pl;;\nmac...@szerszenowicz.com;;\nmaciej_zi...@op.pl;;\nmaciekprokopow...@gmail.com;;\nmadziam...@tlen.pl;;\nmadzior...@wp.pl;;\nmagda.mackiewicz@o2.p"..., ecode=0x165916a "V", mstart=0x1630b08 "status=OK\nsubscribers-exported=150...@student.pwr.wroc.pl;;\n2t...@gazeta.pl;;\n70...@interia.pl;;\n73piot...@wp.pl;;\na.gale...@zarzadca.wroclaw.pl;;\na.g...@poczta.fm;;\na.gruszew...@gmail.com;;\na.karamon"..., markptr=0x0, offset_top=8, md=0x7fff797e7960, ims=0, eptrb=0x0, flags=0, rdepth=12461) at /usr/local/directadmin/custombuild/php-5.2.17/ext/pcre/pcrelib/pcre_exec.c:1552 1552 /usr/local/directadmin/custombuild/php-5.2.17/ext/pcre/pcrelib/pcre_exec.c: No such file or directory. in /usr/local/directadmin/custombuild/php-5.2.17/ext/pcre/pcrelib/pcre_exec.c (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $1 = 0x89f727 "preg_match" regards, Piotr Test script: --- https://bugs.php.net/bug.php?id=61644&edit=1
Bug #61644 [Opn->Nab]: crashes with preg_match
Edit report at https://bugs.php.net/bug.php?id=61644&edit=1 ID: 61644 Updated by: paj...@php.net Reported by:pio at rdl dot pl Summary:crashes with preg_match -Status: Open +Status: Not a bug Type: Bug Package:Regexps related Operating System: Debian 6 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Increase the recursion limit or your stack size: http://php.net/manual/en/pcre.configuration.php Previous Comments: [2012-04-06 15:44:20] pio at rdl dot pl OK,I have uploaded this file on server http://s71.vdl.pl/1.txt Piotr [2012-04-06 03:37:47] larue...@php.net http://speedy.sh/YGJDR/1.txt 404 for me... [2012-04-05 21:34:05] pio at rdl dot pl The file 1.txt here is http://speedy.sh/YGJDR/1.txt [2012-04-05 21:31:32] pio at rdl dot pl Description: Hello ! We have problem with parse some data and regular expression match. I have attached the file 1.txt # /usr/local/php5.3/bin/php test.php Segmentation fault (gdb) run test.php Starting program: /usr/local/bin/php test.php [Thread debugging using libthread_db enabled] [New Thread 0x7f1659abb710 (LWP 14776)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f1659abb710 (LWP 14776)] 0x004bf9ff in match ( eptr=0x1632378 "nteria.pl;;\nmaciej...@o2.pl;;\nmaciej.len...@lumenpolska.pl;;\nmac...@szerszenowicz.com;;\nmaciej_zi...@op.pl;;\nmaciekprokopow...@gmail.com;;\nmadziam...@tlen.pl;;\nmadzior...@wp.pl;;\nmagda.mackiewicz@o2.p"..., ecode=0x165916a "V", mstart=0x1630b08 "status=OK\nsubscribers-exported=150...@student.pwr.wroc.pl;;\n2t...@gazeta.pl;;\n70...@interia.pl;;\n73piot...@wp.pl;;\na.gale...@zarzadca.wroclaw.pl;;\na.g...@poczta.fm;;\na.gruszew...@gmail.com;;\na.karamon"..., markptr=0x0, offset_top=8, md=0x7fff797e7960, ims=0, eptrb=0x0, flags=0, rdepth=12461) at /usr/local/directadmin/custombuild/php-5.2.17/ext/pcre/pcrelib/pcre_exec.c:1552 1552 /usr/local/directadmin/custombuild/php-5.2.17/ext/pcre/pcrelib/pcre_exec.c: No such file or directory. in /usr/local/directadmin/custombuild/php-5.2.17/ext/pcre/pcrelib/pcre_exec.c (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $1 = 0x89f727 "preg_match" regards, Piotr Test script: --- https://bugs.php.net/bug.php?id=61644&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 #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
[PHP-BUG] Bug #61655 [NEW]: Unable to access key in array cast from object
From:
Operating system: RedHat
PHP version: 5.3.10
Package: Arrays related
Bug Type: Bug
Bug description:Unable to access key in array cast from object
Description:
Casting from an object to an array with numeric key leaves the element
inaccessible.
Given a object with a field whose name is numeric, after a cast to array,
there is no means to access the element.
That is $array['804496778'] yields an undefined error
array_key_exists(804496778, $array); yields false
array_key_exists('804496778', $array); fields false
yet a var_dump($array); shows this element;
and a array_keys($array); returns array(1) { [0] string(9) "804496778" }
Test script:
---
$object = new stdClass();
$key = '804496778';
$object->{$key} = "Hello;
$array = (array)$object;
echo $array[$key], ' ', (int)array_key_exists($key, $array), PHP_EOL;
var_dump($array)
Expected result:
Hello 1
array(1) {
["804496778"]=>
string(5) "Hello"
}
Actual result:
--
PHP Notice: Undefined index: 804496778 in /home/icewolf/bug.php on line 6
0
array(1) {
["804496778"]=>
string(5) "Hello"
}
--
Edit bug report at https://bugs.php.net/bug.php?id=61655&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61655&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61655&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61655&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61655&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61655&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61655&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61655&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61655&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61655&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61655&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61655&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61655&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61655&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61655&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61655&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61655&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61655&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61655&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61655&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61655&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61655&r=mysqlcfg
[PHP-BUG] Bug #61658 [NEW]: Inherited static properties are not overwritten
From:
Operating system: Arch Linux
PHP version: 5.4.0
Package: Class/Object related
Bug Type: Bug
Bug description:Inherited static properties are not overwritten
Description:
I'm not sure if this is a bug or if this is intended, but I didn't find
anything in the documentation:
If a class inherits a static property, but overrides it with its own static
property, the property of the parent is used.
(If the properties are not marked as static, I get the expected result)
Test script:
---
class A{
protected static $hi="Hello";
public function __construct(){
$class=get_class();
echo $class::$hi;
}
}
class B extends A{
protected static $hi="What's up";
}
$a=new A();
$b=new B();
Expected result:
HelloWhat's up
Actual result:
--
HelloHello
--
Edit bug report at https://bugs.php.net/bug.php?id=61658&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61658&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61658&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61658&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61658&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61658&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61658&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61658&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61658&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61658&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61658&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61658&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61658&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61658&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61658&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61658&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61658&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61658&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61658&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61658&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61658&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61658&r=mysqlcfg
Bug #61658 [Opn]: Inherited static properties are not overwritten
Edit report at https://bugs.php.net/bug.php?id=61658&edit=1
ID: 61658
User updated by:thomash dot usa at gmail dot com
Reported by:thomash dot usa at gmail dot com
Summary:Inherited static properties are not overwritten
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Arch Linux
-PHP Version:5.4.0
+PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
PHP Version set to 5.3.8
Previous Comments:
[2012-04-07 06:10:30] thomash dot usa at gmail dot com
Description:
I'm not sure if this is a bug or if this is intended, but I didn't find
anything in the documentation:
If a class inherits a static property, but overrides it with its own static
property, the property of the parent is used.
(If the properties are not marked as static, I get the expected result)
Test script:
---
class A{
protected static $hi="Hello";
public function __construct(){
$class=get_class();
echo $class::$hi;
}
}
class B extends A{
protected static $hi="What's up";
}
$a=new A();
$b=new B();
Expected result:
HelloWhat's up
Actual result:
--
HelloHello
--
Edit this bug report at https://bugs.php.net/bug.php?id=61658&edit=1
Bug #61658 [Opn->Csd]: Inherited static properties are not overwritten
Edit report at https://bugs.php.net/bug.php?id=61658&edit=1
ID: 61658
User updated by:thomash dot usa at gmail dot com
Reported by:thomash dot usa at gmail dot com
Summary:Inherited static properties are not overwritten
-Status: Open
+Status: Closed
Type: Bug
Package:Class/Object related
Operating System: Arch Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Ignore me, It's late
Previous Comments:
[2012-04-07 06:16:39] thomash dot usa at gmail dot com
PHP Version set to 5.3.8
[2012-04-07 06:10:30] thomash dot usa at gmail dot com
Description:
I'm not sure if this is a bug or if this is intended, but I didn't find
anything in the documentation:
If a class inherits a static property, but overrides it with its own static
property, the property of the parent is used.
(If the properties are not marked as static, I get the expected result)
Test script:
---
class A{
protected static $hi="Hello";
public function __construct(){
$class=get_class();
echo $class::$hi;
}
}
class B extends A{
protected static $hi="What's up";
}
$a=new A();
$b=new B();
Expected result:
HelloWhat's up
Actual result:
--
HelloHello
--
Edit this bug report at https://bugs.php.net/bug.php?id=61658&edit=1
