#30981 [NEW]: is_dir reports a directory exists when named one thing but not another
From: andy dot thoreson at verizon dot net
Operating system: Windows 2000
PHP version: 4.3.10RC1
PHP Bug Type: Directory function related
Bug description: is_dir reports a directory exists when named one thing but
not another
Description:
Was trying to write code that recursively scanned files in a directory
tree and Apache was crashing as soon as I added the recursion...but that's
another issue. In the course of debugging that, I found this one simple
bug:
I run the following code (nothing else run in php file):
print "1:[".is_dir("D:\Program Files\Apache
Group\Apache\htdocs\Utils\Old_Ocean_Backup")."]";
print "";
print "2:[".is_dir("D:\Program Files\Apache
Group\Apache\htdocs\Utils\Old_Ocean_Backup\testx")."]";
print "";
The first folder always comes back as existing (returns true/1).
The second one does not. It is just a directory I made from windows
explorer (right-click, new folder).
When I rename it, in explorer, to "abc" and reload the php page (with name
changed from "testx" to "abc" in code as well), is_dir says it *does*
exist. Renaming to "abcx" or "testxx" etc does the same..."abcx" exists,
"textxx" does not.
Renaming it back and forth from explorer reproduces the same results.
File system rights don't seem to be the issue.
Strangely, readdir does see the directory such as:
$handle=opendir("D:\Program Files\Apache
Group\Apache\htdocs\Utils\Old_Ocean_Backup");
while ($file = readdir($handle)) {
...}
Installed a fresh version of PHP and Apache today after first running into
problem (was on apache 2.0 and PHP 4.3 from last week):
PHP 4.3.10RC2-dev.
Apache 1.3
Windows NT 5.0 build 2195 (Windows 2000)
Reproduce code:
---
See description
Expected result:
Expected the code to treat the existance of a directory the same
regardless of its name.
Actual result:
--
Code treats the existance of a directory different based on directory
name.
--
Edit bug report at http://bugs.php.net/?id=30981&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30981&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30981&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30981&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30981&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30981&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30981&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30981&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30981&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30981&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30981&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30981&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30981&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30981&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30981&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30981&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30981&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30981&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30981&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30981&r=mysqlcfg
#30979 [Com]: Cant load COM
ID: 30979
Comment by: eliziane_castro at hotmail dot com
Reported By: jayron_castro at hotmail dot com
Status: Open
Bug Type: COM related
Operating System: Windows 2003
PHP Version: 5.0.2
New Comment:
several times with me that bug already happened
Previous Comments:
[2004-12-04 01:46:56] jayron_castro at hotmail dot com
Description:
when the option below is active error it always happens in the script:
zend.ze1_compatibility_mode = On
ATTENTION:
the only solution is to incapacitate:
zend.ze1_compatibility_mode = Off
Reproduce code:
---
$ocodaut = new COM("JaccGeraCod.cCripCod") or die("objeto não
instanciado");
$vl_codaut = $ocodaut->Autorizacao(7075,12,12,101,50);
echo "codigo: $vl_codaut";
Expected result:
teste: 00280282528
Actual result:
--
PHP has encountered an Access Violation at 0178F6B4
--
Edit this bug report at http://bugs.php.net/?id=30979&edit=1
#30980 [NEW]: fails to compile ext/snmp using net-snmp 5.2
From: nathan at nightsys dot net Operating system: gentoo PHP version: 5.0.2 PHP Bug Type: *Compile Issues Bug description: fails to compile ext/snmp using net-snmp 5.2 Description: php fails to compile, due to errors on ext/snmp. cant tell for sure what it is, but one thing that was done is previously sessions were disabled, now sessions are enabled on this compile. not sure if relevant, maybe new net-snmp version also. this looks similar to bug 25200, but not sure if its the same. Reproduce code: --- use net-snmp v5.2, with php 5.0.2 emerge net-snmp then emerge php OR emerge mod_php Expected result: successful compile. Actual result: -- gcc -Iext/snmp/ -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/ -DPHP_ATOM_INC -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/include -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/main -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2 -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/Zend -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/mbstring/oniguruma -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/mbstring/libmbfl -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/postgresql/pgsql -I/usr/include/pspell -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/TSRM -O2 -march=pentium3 -fomit-frame-pointer -fforce-addr -g -Wall -c /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c -fPIC -DPIC -o ext/snmp/snmp.lo /bin/sh /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/libtool --preserve-dup-deps --mode=compile gcc -Iext/sockets/ -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/sockets/ -DPHP_ATOM_INC -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/include -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/main -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2 -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/Zend -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/mbstring/oniguruma -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/mbstring/libmbfl -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/postgresql/pgsql -I/usr/include/pspell -I/var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/TSRM -O2 -march=pentium3 -fomit-frame-pointer -fforce-addr -g -Wall -prefer-pic -c /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/sockets/sockets.c -o ext/sockets/sockets.lo /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c: In function `netsnmp_session_set_sec_protocol': /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c:795: error: `usmAES192PrivProtocol' undeclared (first use in this function) /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c:795: error: (Each undeclared identifier is reported only once /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c:795: error: for each function it appears in.) /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c:799: error: `usmAES256PrivProtocol' undeclared (first use in this function) /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c: In function `netsnmp_session_gen_auth_key': /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c:822: warning: initialization discards qualifiers from pointer target type /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c: In function `netsnmp_session_gen_sec_key': /var/tmp/portage/mod_php-5.0.2/work/php-5.0.2/ext/snmp/snmp.c:851: warning: initialization discards qualifiers from pointer target type make: *** [ext/snmp/snmp.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=30980&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30980&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30980&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30980&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30980&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30980&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30980&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30980&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30980&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30980&r=support Expected behavior: http://bugs.php.net/fix.php?id=30980&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30980&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30980&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30980&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30980&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30980&r=dst IIS Stability:
#30979 [NEW]: Cant load COM
From: jayron_castro at hotmail dot com
Operating system: Windows 2003
PHP version: 5.0.2
PHP Bug Type: COM related
Bug description: Cant load COM
Description:
when the option below is active error it always happens in the script:
zend.ze1_compatibility_mode = On
ATTENTION:
the only solution is to incapacitate:
zend.ze1_compatibility_mode = Off
Reproduce code:
---
$ocodaut = new COM("JaccGeraCod.cCripCod") or die("objeto não
instanciado");
$vl_codaut = $ocodaut->Autorizacao(7075,12,12,101,50);
echo "codigo: $vl_codaut";
Expected result:
teste: 00280282528
Actual result:
--
PHP has encountered an Access Violation at 0178F6B4
--
Edit bug report at http://bugs.php.net/?id=30979&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30979&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30979&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30979&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30979&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30979&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30979&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30979&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30979&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30979&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30979&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30979&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30979&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30979&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30979&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30979&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30979&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30979&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30979&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30979&r=mysqlcfg
#30839 [Fbk->NoF]: libphp4.la
ID: 30839 Updated by: [EMAIL PROTECTED] Reported By: mtastudillo at delphus-it dot com -Status: Feedback +Status: No Feedback Bug Type: OCI8 related Operating System: Solaris PHP Version: 4.3.8 New Comment: 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". Previous Comments: [2004-11-19 22:21:38] jed at jed dot bz La mayoría de nosotros no puede leer español. Traduciré tu informe en inglés, pero los otros responderán en inglés. Lo ciento que ésta es la situación. No utilizo Oracle o Sun, así no puedo ayudar. :( Rough translation for those don't speak Spanish. Description: When one is compiling PHP with Oracle support and executes the make command it leaves this error: After ./configure , one executes make and it generates an error. The operating system is Solaris 8. The machine is a Sun Fire 280. (Under expected result) One hopes that it does not generate an error and it will compile without problems. [2004-11-19 18:10:23] [EMAIL PROTECTED] Write in English, please. And, please, try CVS version before reporting bugs. This issue should be already solved there. [2004-11-19 17:58:14] mtastudillo at delphus-it dot com Description: Se esta compilando php con soporte Oracle y cuando se ejecuta el make sale el siguiente error: Luego de ./configure , se ejecuta el make y genera un error. El S.O. es Solaris 8 La maquina es una Sun Fire 280. Reproduce code: --- /usr/local/sparc-sun-solaris2.8/bin/ld: skipping incompatible /s/oracle/product/9.2/lib/libclntsh.so when searching for -lclntsh /usr/local/sparc-sun-solaris2.8/bin/ld: cannot find -lclntsh collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libphp4.la' Expected result: Se espera que no genere error y que compile sin problemas. Actual result: -- /usr/local/sparc-sun-solaris2.8/bin/ld: skipping incompatible /s/oracle/product/9.2/lib/libclntsh.so when searching for -lclntsh /usr/local/sparc-sun-solaris2.8/bin/ld: cannot find -lclntsh collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libphp4.la' -- Edit this bug report at http://bugs.php.net/?id=30839&edit=1
#27908 [Com]: xml default_handlers not being called
ID: 27908
Comment by: werner at esmt dot org
Reported By: ahundiak at ingr dot com
Status: Verified
Bug Type: XML related
Operating System: Linux
PHP Version: 5CVS-2004-04-08
New Comment:
...please, can somebody fix this bug?
thanx!
Previous Comments:
[2004-09-16 22:56:07] k at ailis dot de
I'm currently experiencing the same problem. The bug is still present
in PHP 5.0.1.
I'm using libxml2 2.6.11 and libexpat 1.95.6.
[2004-08-06 15:29:13] tom at ideaweb dot de
i have the same problem too. in version 4 there are no
problems, but in php5 this is broken. the bug is not
fixed till 5.0.0. i think it is a very import "core"
function to get "old" applications of version 4
running!!
[2004-04-07 12:34:00] ahundiak at ingr dot com
Description:
As the test case shows, it does not appear that the default handler is
being called under PHP5RC1. The other handlers seem to work but the
default handler is required to get the document type line. PHP4.3.5
works. Using libxml2 2.6.5.
Reproduce code:
---
function x_default_handler($xp,$data)
{
echo "x_default_handler $data\n";
}
$xp = xml_parser_create();
xml_set_default_handler($xp,'x_default_handler');
xml_parse($xp,'',TRUE);
xml_parser_free($xp);
echo "Parse Test " . PHP_VERSION . " Done\n";
Expected result:
x_default_handler
x_default_handler
Parse Test 5.0.0RC1 Done
Actual result:
--
Parse Test 5.0.0RC1
--
Edit this bug report at http://bugs.php.net/?id=27908&edit=1
#30977 [Opn]: Can't connect in specific scenarios.
ID: 30977 User updated by: cross_phil at hotmail dot com Reported By: cross_phil at hotmail dot com Status: Open Bug Type: MSSQL related Operating System: win32 PHP Version: Irrelevant New Comment: BTW: I have tried this on 4.3.8 (my ISP) and on my laptop which is 5.0.2, so I don't think version matters. Previous Comments: [2004-12-03 18:03:33] cross_phil at hotmail dot com Description: I am having trouble connecting to my MS SQL database from an external network address. When I am at work connecting locally this code works fine. When I am outside the building, it fails with the error mentioned in "Actual Result". It does not appear to be a IP or a firewall issue because I can connect with the query analyser and other MS tools just fine. Seems like some sort of network transport issue. I can work around it using the COM example listed on the MS SQL documentation/user comments but I have libraries build around the SQL functions that I would rather use if I can figure this out. I am mainly asking to try to determine why this function would act different in different network scenarios. Reproduce code: --- Expected result: success Actual result: -- Warning: mssql_connect(): Unable to connect to server: 68.111.105.35 in e:\bigdogdealer.net\bigdogmotorcycles.net\php\dealer\test.php on line 10 Error connecting -- Edit this bug report at http://bugs.php.net/?id=30977&edit=1
#30708 [NoF->Opn]: Stream of type 'STDIO' was not closed
ID: 30708 User updated by: guth at fiifo dot u-psud dot fr Reported By: guth at fiifo dot u-psud dot fr -Status: No Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 5.0.2 New Comment: The problem still occurs on my system... Previous Comments: [2004-11-18 01:00:02] 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". [2004-11-09 09:12:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2004-11-07 00:22:58] guth at fiifo dot u-psud dot fr Description: hello, It seems that PHP doesn't close a "Stream of type 'STDIO'" when the PHP code produces a parse error with "throw". Reproduce code: --- Expected result: /www/test2.php(2) : Parse error - parse error, unexpected T_THROW, expecting ')' Actual result: -- /www/test2.php(2) : Parse error - parse error, unexpected T_THROW, expecting ')' /usr/src/php5/main/streams/streams.c(375) : Stream of type 'STDIO' 0x816d83c (path:/www/test2.php) was not closed -- Edit this bug report at http://bugs.php.net/?id=30708&edit=1
#29975 [Fbk->Opn]: memory leaks
ID: 29975 User updated by: guth at fiifo dot u-psud dot fr Reported By: guth at fiifo dot u-psud dot fr -Status: Feedback +Status: Open Bug Type: Performance problem Operating System: Linux (Mandrake 10) PHP Version: 5.0.1 New Comment: hello, it doesn't work fine here :) Previous Comments: [2004-11-28 17:00:19] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Works fine here. [2004-10-12 10:36:00] guth at fiifo dot u-psud dot fr I use a SimpleTest to do unit tests and it seems that it is this library which causes the memory leaks. run(); ?> /usr/src/php5-200410111030/Zend/zend_builtin_functions.c(1058) : Freeing 0x082D0C54 (16 bytes), script=/www/test2.php Last leak repeated times /usr/src/php5-200410111030/Zend/zend_variables.h(45) : Freeing 0x082D0B84 (23 bytes), script=/www/test2.php /usr/src/php5-200410111030/Zend/zend_variables.c(120) : Actual location (location was relayed) Last leak repeated times [2004-09-20 01:00:02] 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". [2004-09-06 08:12:18] [EMAIL PROTECTED] 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 possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-09-03 21:21:15] guth at fiifo dot u-psud dot fr Description: (i'm french, excuse me for my english) I try to develop a CMS and i take more time to debug PHP than code PHP... After 3 segmentation fault, I compiled PHP with --enable-debug, and my tests give the following errors. Reproduce code: --- /usr/src/php-5.0.1/Zend/zend_builtin_functions.c(1023) : Freeing 0x0846F864 (23 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_variables.c(137) : Actual location (location was relayed) Last leak repeated 32 times /usr/src/php-5.0.1/Zend/zend_builtin_functions.c(1013) : Freeing 0x084702C4 (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php Last leak repeated 32 times /usr/src/php-5.0.1/Zend/zend_execute.c(3718) : Freeing 0x0844FA94 (44 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_variables.c(149) : Actual location (location was relayed) Last leak repeated 1 time /usr/src/php-5.0.1/Zend/zend_execute.c(3252) : Freeing 0x0844DCCC (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php Last leak repeated 7 times /usr/src/php-5.0.1/Zend/zend_variables.c(150) : Freeing 0x0843597C (32 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_hash.c(169) : Actual location (location was relayed) /usr/src/php-5.0.1/Zend/zend_execute.c(3389) : Freeing 0x084315DC (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_hash.c(242) : Freeing 0x08233804 (40 bytes), script=/www/haricow/0.4/haricow/test/runTests.php === Total 79 memory leaks detected === Expected result: No memory leaks Actual result: -- About 3 Kb of memory leaks. I tryed to "insulate" them, but i didn't manage, because of the complexity of the script. -- Edit this bug report at http://bugs.php.net/?id=29975&edit=1
#30161 [Fbk->Opn]: Segmentation fault with exceptions
ID: 30161 User updated by: guth at fiifo dot u-psud dot fr Reported By: guth at fiifo dot u-psud dot fr -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Linux (mandrake 10) PHP Version: 5.0.1 New Comment: It still segfaults here... Previous Comments: [2004-11-28 14:48:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce the segfault. It doesn't output anything, but doesn't segfault too. [2004-10-12 10:30:33] guth at fiifo dot u-psud dot fr Same behaviour with the latest cvs (php 5.1.0-dev)... [2004-10-11 07:57:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-10-10 00:29:38] guth at fiifo dot u-psud dot fr In fact, this code segfault if you add : "var_dump($db);" before "echo $db;" Without the var_dump, "echo $db;" prints nothing. [2004-09-20 09:32:51] guth at fiifo dot u-psud dot fr Description: The following code segfaults. Reproduce code: --- Expected result: No segfault but something like that: Rusticus in asino sedet. Actual result: -- FATAL: erealloc(): Unable to allocate 1515872257 bytes [Sat Sep 18 21:18:11 2004] [notice] child pid 3512 exit signal Segmentation fault (11) (gdb) bt #0 0xe410 in ?? () #1 0xbfffcb78 in ?? () #2 0x404354a0 in __JCR_LIST__ () from /usr/local/apache/libexec/libphp5.so #3 0x000b in ?? () #4 0x400c7a76 in kill () from /lib/tls/libc.so.6 #5 0x4038a6ad in _erealloc (ptr=0x81630ec, size=1515872257, allow_failure=0, __zend_filename=0x40402140 "/usr/src/php-5.0.1/main/output.c", __zend_lineno=392, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/php-5.0.1/Zend/zend_alloc.c:350 #6 0x4036e2d4 in php_ob_allocate (text_length=1515870810) at /usr/src/php-5.0.1/main/output.c:392 #7 0x4036e1d4 in php_ob_append (text=0x0, text_length=1515870810) at /usr/src/php-5.0.1/main/output.c:598 #8 0x4036d4b1 in php_b_body_write (str=0x0, str_length=1515870810) at /usr/src/php-5.0.1/main/output.c:670 #9 0x4036c149 in php_body_write (str=0x0, str_length=1515870810) at /usr/src/php-5.0.1/main/output.c:119 #10 0x4035da8c in php_body_write_wrapper (str=0x0, str_length=1515870810) at /usr/src/php-5.0.1/main/main.c:1242 #11 0x403a3d0c in zend_print_zval_ex (write_func=0x4035da6b , expr=0xbfffcc70, indent=0) at /usr/src/php-5.0.1/Zend/zend.c:289 #12 0x403a3c8a in zend_print_zval (expr=0x8164f5c, indent=0) at /usr/src/php-5.0.1/Zend/zend.c:270 #13 0x403a341c in zend_print_variable (var=0x8164f5c) at /usr/src/php-5.0.1/Zend/zend_variables.c:168 #14 0x403ca2bd in zend_echo_handler (execute_data=0xbfffce40, opline=0x8169610, op_array=0x8164e6c) at /usr/src/php-5.0.1/Zend/zend_execute.c:1986 #15 0x403c8c96 in execute (op_array=0x8164e6c) at /usr/src/php-5.0.1/Zend/zend_execute.c:1400 #16 0x403a54f5 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-5.0.1/Zend/zend.c:1061 #17 0x4035e49e in php_execute_script (primary_file=0xb1b0) at /usr/src/php-5.0.1/main/main.c:1627 #18 0x403d4b94 in apache_php_module_main (r=0x815a09c, display_source_mode=0) at /usr/src/php-5.0.1/sapi/apache/sapi_apache.c:54 #19 0x403d5b1f in send_php (r=0x815a09c, display_source_mode=0, filename=0x815aba4 "/www/test.php") at /usr/src/php-5.0.1/sapi/apache/mod_php5.c:622 #20 0x403d5b98 in send_parsed_php (r=0x815a09c) at /usr/src/php-5.0.1/sapi/apache/mod_php5.c:637 #21 0x08071e77 in ap_invoke_handler () #22 0x08086ebd in process_request_internal () #23 0x08086f1c in ap_process_request () #24 0x0807df40 in child_main () #25 0x0807e0e8 in make_child () #26 0x0807e24e in startup_children () #27 0x0807e90e in standalone_main () #28 0x0807f12c in main () -- Edit this bug report at http://bugs.php.net/?id=30161&edit=1
#30085 [Fbk->Csd]: Segmentation fault
ID: 30085
User updated by: guth at fiifo dot u-psud dot fr
Reported By: guth at fiifo dot u-psud dot fr
-Status: Feedback
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Linux (mandrake 10)
PHP Version: 5.0.1
New Comment:
It works fine now.
Thank you.
Previous Comments:
[2004-11-28 15:42:37] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
I cannot reproduce it. Please, try latest CVS snapshot.
[2004-09-14 15:53:48] guth at fiifo dot u-psud dot fr
Description:
(sorry for english...)
here is my fifth segmentation fault in PHP 5...
Reproduce code:
---
test = new test; /* An entire mystery, without this
code, no
segmentation fault */
}
public function __destruct() {
fuck();
/*
If you don't like "fuck()" and if you want a segfault,
you can try
with everything that raise a fatal error. Some examples :
- trigger_error("thamer", E_USER_ERROR);
- unset(self::$thamer);
Warning : no fatal error, no segfault :)
*/
}
}
$test = new thamer;
?>
Expected result:
A fatal error (no segmentation fault...).
Actual result:
--
[Mon Sep 13 22:07:42 2004] [error] PHP Fatal error: Call to undefined
function fuck() in /www/test.php on line 13
/www/test.php(13) : Fatal error - Call to undefined function fuck()
[Mon Sep 13 22:07:43 2004] [notice] child pid 4043 exit signal
Segmentation fault (11)
#0 0x082030bc in zend_objects_destroy_object (object=0x83035dc,
handle=2) at /usr/src/php-5.0.1/Zend/zend_objects.c:37
#1 0x08205be0 in zend_objects_store_del_ref (zobject=0x830359c) at
/usr/src/php-5.0.1/Zend/zend_objects_API.c:144
#2 0x081ed016 in _zval_dtor (zvalue=0x830359c,
__zend_filename=0x8260d40
"/usr/src/php-5.0.1/Zend/zend_execute_API.c",
__zend_lineno=391) at /usr/src/php-5.0.1/Zend/zend_variables.c:61
#3 0x081e1850 in _zval_ptr_dtor (zval_ptr=0x83034f0,
__zend_filename=0x8261c60
"/usr/src/php-5.0.1/Zend/zend_variables.c", __zend_lineno=193)
at /usr/src/php-5.0.1/Zend/zend_execute_API.c:391
#4 0x081ed368 in _zval_ptr_dtor_wrapper (zval_ptr=0x83034f0) at
/usr/src/php-5.0.1/Zend/zend_variables.c:193
#5 0x081f68b8 in zend_hash_destroy (ht=0x830fbc4) at
/usr/src/php-5.0.1/Zend/zend_hash.c:519
#6 0x08203322 in zend_objects_free_object_storage (object=0x831702c)
at /usr/src/php-5.0.1/Zend/zend_objects.c:88
#7 0x0820593d in zend_objects_store_free_object_storage
(objects=0x8285204)
at /usr/src/php-5.0.1/Zend/zend_objects_API.c:72
#8 0x081e137f in shutdown_executor () at
/usr/src/php-5.0.1/Zend/zend_execute_API.c:272
#9 0x081ee9b7 in zend_deactivate () at
/usr/src/php-5.0.1/Zend/zend.c:819
#10 0x081a7648 in php_request_shutdown (dummy=0x0) at
/usr/src/php-5.0.1/main/main.c:1212
#11 0x082204ac in main (argc=2, argv=0xb664) at
/usr/src/php-5.0.1/sapi/cli/php_cli.c:1046
--
Edit this bug report at http://bugs.php.net/?id=30085&edit=1
#29207 [Com]: Wrong script uid with safe_mode
ID: 29207
Comment by: dsmk at bu dot edu
Reported By: ksvee at usit dot uio dot no
Status: Open
Bug Type: *Directory/Filesystem functions
Operating System: Solaris 8
PHP Version: 4.3.8
New Comment:
Just wanted to add that I have reproduced the problem
on Solaris 8 with all the versions above 4.3.8 including
4.3.10RC1 and 5.0.2. My production Apache is a security patched 1.3.26
but I have also seen the problem with a
generic 1.3.31.
Previous Comments:
[2004-07-16 12:53:24] ksvee at usit dot uio dot no
Description:
This is really an old bug that seems to be coming and going, but I
cannot find an open bug on it.
References: bugs #18500, #12683 and #7744
The latest version that this bug is not alive and well is 4.2.3 which
is the one we still use. I've tested (just about) every (release)
version since, and reproduced the bug in all of them. That includes the
latest (4.3.8) tested today, 2004-07-16. I use PHP with Apache 1.3.x
(1.3.31 latest).
Description:
When using SAFE_MODE = ON, php reports uid=1 on the running php-script
as well as its proper uid:
-
[datetag] [error] PHP Warning: Unknown(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not
allowed to access /path/to/script.php owned by uid 26658 in Unknown on
line 0
-
If I chown the script to another user, e.g. root, the report looks like
this:
-
[datetag] [error] PHP Warning: Unknown(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not allowed to access
/path/to/script.php owned by uid 0 in Unknown on line 0
-
If i chown it to uid=1 ('daemon' on my systems) then it seems to work,
except that the file I intend to include also needs to be owned by
daemon. This included file at least seems to have its owner reported
correctly, the full report being:
-
[datetag] [error] PHP Warning: main(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not allowed to access
./filename.inc owned by uid 26658 in /a/b/c/include.php on line 2
[datetag] [error] PHP Warning: main(filename.inc): failed to open
stream: Error 0 in /a/b/c/include.php on line 2
[datetag] [error] PHP Warning: main(): Failed opening 'filename.inc'
for inclusion (include_path='.') in /a/b/c/include.php on line 2
-
We usually use a non-standard config, compiling Apache, PHP, OpenSSL
etc under a specific prefix, but dumbing this to default paths has no
impact.
Using "--with-apxs=/path/to/apxs --prefix=/path/to/installprefix" as
the only config parameters to PHP too has no impact on the results.
As for php.ini, I've tried using a clean copy of both
"php.ini-recommended" and "php.ini-dist" with no other modifications
than setting "safe_mode = On". No significant changes.
Rgds,
Kenneth Svee
Reproduce code:
---
# Content of include.php:
# (filename.inc is in same dir as include.php, and
# contains just an arbitrary string, e.g.:
"I've been included!"
Expected result:
# I expected the string in filename.inc:
"I've been included!"
Actual result:
--
Just the empty page, and the errormessages in Apaches error_log.
--
Edit this bug report at http://bugs.php.net/?id=29207&edit=1
#30971 [Fbk->Opn]: highlight_string chokes bad when parsing strings containing newline escapes
ID: 30971
User updated by: jed at jed dot bz
Reported By: jed at jed dot bz
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: *
-PHP Version: Irrelevant
+PHP Version: 4CVS, 5CVS
New Comment:
This has been there since at least early 2003. And it's reproducable in
both CVSes.
Previous Comments:
[2004-12-03 09:20:48] [EMAIL PROTECTED]
Please fill in your PHP version.
[2004-12-03 00:56:32] jed at jed dot bz
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little more problematic
than it appears at first hand. The reproduce code below is what is
supposed to be highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
---
getFile())) {
$line = file($e->getFile());
$line = trim($line[$e->getLine() - 1]);
}
else $line = "?";
printf("\n\nSTOP. Uncaught exception \"%s\" in %s:%u\n" .
" >> %s\n" .
" Message: (%u) %s\n Backtrace:\n", get_class($e),
$e->getFile(),
$e->GetLine(), $line, $e->getCode(), $e->getMessage());
$i = 0;
foreach($e->getTrace() as $bt)
printf(" (#%u) %s()\n", ++$i, $bt['class'] . $bt['type'] .
$bt['function'],
$bt['file'], $bt['line']);
printf("\n\n");
exit(0xFE);
}
Expected result:
http://labs.jed.bz/phpbug4.png
Actual result:
--
http://labs.jed.bz/phpbug3.png
(Sporadically)
--
Edit this bug report at http://bugs.php.net/?id=30971&edit=1
#30978 [NEW]: Append the Object into array result incorrect
From: btb_tp at yahoo dot com
Operating system: Windows XP SP2
PHP version: 5.0.2
PHP Bug Type: Unknown/Other Function
Bug description: Append the Object into array result incorrect
Description:
Below code work with PHP 4.3.9!!!
Reproduce code:
---
class A{
protected $value = 0;
function A($value){
$this->value = $value;}
function getValue(){
return $this->value;}
function setValue($value){
$this->value = $value;}
}
$b = array();
$a = new A(0);
for($i = 1; $i <= 2; $i++){
$a->setValue($i);
$b[] = $a;}
print_r($b);
Expected result:
Array ( [0] => A Object ( [value:protected] => 1 ) [1] => A Object (
[value:protected] => 2 ) )
Actual result:
--
Array ( [0] => A Object ( [value:protected] => 2 ) [1] => A Object (
[value:protected] => 2 ) )
--
Edit bug report at http://bugs.php.net/?id=30978&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30978&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30978&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30978&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30978&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30978&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30978&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30978&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30978&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30978&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30978&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30978&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30978&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30978&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30978&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30978&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30978&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30978&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30978&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30978&r=mysqlcfg
#30660 [Com]: Using Tidy as shared extension crashes PHP (CLI)
ID: 30660 Comment by: brent at jeneral dot com Reported By: margus at zone dot ee Status: Assigned Bug Type: Reproducible crash Operating System: SuSe Linux 9.0 PHP Version: 5.0.2 Assigned To: john New Comment: I have two systems w/ apparently identical software systems--FreeBSD 5.2.1 with the same ported application versions (PHP 5.0.2). One fails the simple test as identified in the notes below and the other works perfectly. I do not see any software differences between the systems, only hardware differences. Unfortunately, the failing system is the production box. Previous Comments: [2004-11-08 12:34:13] [EMAIL PROTECTED] I'll look into it, hopefully I'll be able to reproduce it in RH [2004-11-02 14:23:54] margus at zone dot ee linux:/home/margus/install/php-5.0.2 # gdb sapi/cli/php GNU gdb 5.3.92 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... (gdb) run -c . tidytest.php Starting program: /home/margus/install/php-5.0.2/sapi/cli/php -c . tidytest.php [New Thread 16384 (LWP 21668)] Exiting... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 21668)] 0x0816a055 in _zval_dtor (zvalue=0x826ad1c) at /home/margus/install/php-5.0.2/Zend/zend_variables.c:61 61 Z_OBJ_HT_P(zvalue)->del_ref(zvalue TSRMLS_CC); (gdb) bt #0 0x0816a055 in _zval_dtor (zvalue=0x826ad1c) at /home/margus/install/php-5.0.2/Zend/zend_variables.c:61 #1 0x08161e89 in _zval_ptr_dtor (zval_ptr=0x826fe48) at /home/margus/install/php-5.0.2/Zend/zend_execute_API.c:394 #2 0x081715e9 in zend_hash_apply_deleter (ht=0x81ea6d0, p=0x826fe3c) at /home/margus/install/php-5.0.2/Zend/zend_hash.c:574 #3 0x08171679 in zend_hash_graceful_reverse_destroy (ht=0x81ea6d0) at /home/margus/install/php-5.0.2/Zend/zend_hash.c:640 #4 0x08161944 in shutdown_executor () at /home/margus/install/php-5.0.2/Zend/zend_execute_API.c:210 #5 0x0816b126 in zend_deactivate () at /home/margus/install/php-5.0.2/Zend/zend.c:818 #6 0x081395c7 in php_request_shutdown (dummy=0x0) at /home/margus/install/php-5.0.2/main/main.c:1212 #7 0x081987d0 in main (argc=4, argv=0xb704) at /home/margus/install/php-5.0.2/sapi/cli/php_cli.c:1046 (gdb) [2004-11-02 13:41:01] [EMAIL PROTECTED] 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 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. Oops, clicked the wrong link before... [2004-11-02 13:34:32] margus at zone dot ee "); echo "Exiting..."; ?> [2004-11-02 13:28:19] [EMAIL PROTECTED] 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 possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. 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/30660 -- Edit this bug report at http://bugs.php.net/?id=30660&edit=1
#30977 [NEW]: Can't connect in specific scenarios.
From: cross_phil at hotmail dot com Operating system: win32 PHP version: Irrelevant PHP Bug Type: MSSQL related Bug description: Can't connect in specific scenarios. Description: I am having trouble connecting to my MS SQL database from an external network address. When I am at work connecting locally this code works fine. When I am outside the building, it fails with the error mentioned in "Actual Result". It does not appear to be a IP or a firewall issue because I can connect with the query analyser and other MS tools just fine. Seems like some sort of network transport issue. I can work around it using the COM example listed on the MS SQL documentation/user comments but I have libraries build around the SQL functions that I would rather use if I can figure this out. I am mainly asking to try to determine why this function would act different in different network scenarios. Reproduce code: --- Expected result: success Actual result: -- Warning: mssql_connect(): Unable to connect to server: 68.111.105.35 in e:\bigdogdealer.net\bigdogmotorcycles.net\php\dealer\test.php on line 10 Error connecting -- Edit bug report at http://bugs.php.net/?id=30977&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30977&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30977&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30977&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30977&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30977&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30977&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30977&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30977&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30977&r=support Expected behavior: http://bugs.php.net/fix.php?id=30977&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30977&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30977&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30977&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30977&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30977&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30977&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30977&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30977&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30977&r=mysqlcfg
#30976 [Opn->Fbk]: Static method call, warning generated, correct output
ID: 30976 Updated by: [EMAIL PROTECTED] Reported By: php at pollensoft dot com -Status: Open +Status: Feedback -Bug Type: Compile Warning +Bug Type: Scripting Engine problem Operating System: Win2k PHP Version: 4.3.9 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2004-12-03 15:57:21] php at pollensoft dot com sorry, actual result should say: Warning: Problem with method call - please report this bug in on line constructor staticMethod [2004-12-03 15:56:24] php at pollensoft dot com Description: Calling a static method, ie: ClassName::staticMethod(); Generates the following error: Warning: Problem with method call - please report this bug in on line The output is correct, the method seems to function normally, but the warning is generated. This happens with any static method call. I think the warning just needs to be removed unless there's something really low level that's going on that not affecting code compilation or runtime. Reproduce code: --- Expected result: constructor staticMethod Actual result: -- constructor staticMethod -- Edit this bug report at http://bugs.php.net/?id=30976&edit=1
#30976 [Opn]: Static method call, warning generated, correct output
ID: 30976 User updated by: php at pollensoft dot com Reported By: php at pollensoft dot com Status: Open Bug Type: Compile Warning Operating System: Win2k PHP Version: 4.3.9 New Comment: sorry, actual result should say: Warning: Problem with method call - please report this bug in on line constructor staticMethod Previous Comments: [2004-12-03 15:56:24] php at pollensoft dot com Description: Calling a static method, ie: ClassName::staticMethod(); Generates the following error: Warning: Problem with method call - please report this bug in on line The output is correct, the method seems to function normally, but the warning is generated. This happens with any static method call. I think the warning just needs to be removed unless there's something really low level that's going on that not affecting code compilation or runtime. Reproduce code: --- Expected result: constructor staticMethod Actual result: -- constructor staticMethod -- Edit this bug report at http://bugs.php.net/?id=30976&edit=1
#30976 [NEW]: Static method call, warning generated, correct output
From: php at pollensoft dot com Operating system: Win2k PHP version: 4.3.9 PHP Bug Type: Compile Warning Bug description: Static method call, warning generated, correct output Description: Calling a static method, ie: ClassName::staticMethod(); Generates the following error: Warning: Problem with method call - please report this bug in on line The output is correct, the method seems to function normally, but the warning is generated. This happens with any static method call. I think the warning just needs to be removed unless there's something really low level that's going on that not affecting code compilation or runtime. Reproduce code: --- Expected result: constructor staticMethod Actual result: -- constructor staticMethod -- Edit bug report at http://bugs.php.net/?id=30976&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30976&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30976&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30976&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30976&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30976&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30976&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30976&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30976&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30976&r=support Expected behavior: http://bugs.php.net/fix.php?id=30976&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30976&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30976&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30976&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30976&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30976&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30976&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30976&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30976&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30976&r=mysqlcfg
#30975 [Opn->Bgs]: PHP DOM functions output UTF-8 encoded regardless of input encoding
ID: 30975
Updated by: [EMAIL PROTECTED]
Reported By: justin at jwd dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: XML related
Operating System: Windows XP
PHP Version: 5.0.2
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is indeed expected, all XML extensions in PHP work internally with
UTF-8 so that's what it returns.
Previous Comments:
[2004-12-03 13:24:16] justin at jwd dot co dot uk
Description:
When retrieving sections of text from an HTML page using the new DOM
functions, the output is encoded using UTF-8 despite the input being
correctly detected as encoded ISO-8859-1. This means extra code in
order to convert back to the original charset of the input text. Surely
the DOM functions should either encode according to the detected input
encoding or at least provide some mechanism for setting the output
encoding? Or am I being stupid here?
Reproduce code:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>
Untitled Document
Test Paragraph
HTML_END;
$in=new DomDocument();
$in->loadHTML($xhtml);
$xin=new DomXpath($in);
$text=$xin->query('//[EMAIL
PROTECTED]"test_paragraph"]/text()')->item(0)->nodeValue;
echo(htmlspecialchars($text)."\n"); // Outputs "Test Paragraph"
$text=iconv("UTF-8", "ISO-8859-1", $text);
echo(htmlspecialchars($text)."\n"); // Outputs "Test Paragraph"
?>
Expected result:
Test Paragraph
Test Paragraph
Actual result:
--
Test Paragraph
Test Paragraph
--
Edit this bug report at http://bugs.php.net/?id=30975&edit=1
#30975 [NEW]: PHP DOM functions output UTF-8 encoded regardless of input encoding
From: justin at jwd dot co dot uk
Operating system: Windows XP
PHP version: 5.0.2
PHP Bug Type: XML related
Bug description: PHP DOM functions output UTF-8 encoded regardless of input
encoding
Description:
When retrieving sections of text from an HTML page using the new DOM
functions, the output is encoded using UTF-8 despite the input being
correctly detected as encoded ISO-8859-1. This means extra code in order
to convert back to the original charset of the input text. Surely the DOM
functions should either encode according to the detected input encoding or
at least provide some mechanism for setting the output encoding? Or am I
being stupid here?
Reproduce code:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>
Untitled Document
Test Paragraph
HTML_END;
$in=new DomDocument();
$in->loadHTML($xhtml);
$xin=new DomXpath($in);
$text=$xin->query('//[EMAIL
PROTECTED]"test_paragraph"]/text()')->item(0)->nodeValue;
echo(htmlspecialchars($text)."\n"); // Outputs "Test Paragraph"
$text=iconv("UTF-8", "ISO-8859-1", $text);
echo(htmlspecialchars($text)."\n"); // Outputs "Test Paragraph"
?>
Expected result:
Test Paragraph
Test Paragraph
Actual result:
--
Test Paragraph
Test Paragraph
--
Edit bug report at http://bugs.php.net/?id=30975&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30975&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30975&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30975&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30975&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30975&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30975&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30975&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30975&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30975&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30975&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30975&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30975&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30975&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30975&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30975&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30975&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30975&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30975&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30975&r=mysqlcfg
#30412 [Com]: Apache Segmentation Fault (11)
ID: 30412 Comment by: rathamahata at ehouse dot ru Reported By: subscription at nazarenko dot net Status: Open Bug Type: OCI8 related Operating System: SuSE Linux 8.2 PHP Version: 5.0.3RC1 New Comment: Sorry, please ignore previous post. That was apache with MPM=prefork + php compiled against apache with mpm=worker. I don't know how did it work. After i recompiled php against current apache problem had disappeared. Previous Comments: [2004-12-03 11:31:54] rathamahata at ehouse dot ru It looks like this happens (the browser would just wait with nothing happening) even with prefork mpm. strace shows Process 27641 attached - interrupt to quit futex(0x83967f0, FUTEX_WAIT, 2, NULL which is strange becouse apache is compiled with mpm=prefork `apache2 -l' Compiled in modules: core.c mod_access.c mod_auth.c mod_include.c mod_deflate.c mod_log_config.c mod_expires.c mod_setenvif.c prefork.c http_core.c mod_mime.c mod_status.c mod_autoindex.c mod_info.c mod_cgi.c mod_dir.c mod_alias.c mod_rewrite.c mod_so.c [2004-12-02 15:17:32] subscription at nazarenko dot net Let me confirm it again after some more testing today that I still do get segfaults, but not that often than before. Also, let me point out that it seems to be exclusively Apache/PHP problem. The same script is run from the shell environment with no problems at all. Now to the example that you have asked for. It is really simple. In fact *any* Oracle query will cause occasional browser "hanging". Here is a bit of code I used today for testing: Most of the times this would work fine returning me an array of data. But sometimes the browser would just wait with nothing happening. And very rarely the page would fail immediately (producing a segfault in apache's error log) Hope this helps. [2004-12-02 01:20:38] [EMAIL PROTECTED] >[Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM I don't think PHP/OCI8 is causing this. I saw this problem many times without OCI8 enabled or even without any module enabled at all. >Some page loads are unsuccessful, but there >is no segfault! The browser just keeps waiting and waiting >and nothing I would be very thankful if you provide tiny reproduce script, that I can use to reproduce your problem. happens. [2004-12-02 01:05:47] subscription at nazarenko dot net Marking it as open... [2004-12-02 01:02:06] subscription at nazarenko dot net Hello again, Today I tried PHP 5.0.3RC1 with Apache 2.0.52 Worker and Oracle 9.2.0.4 Client for Linux. I'd say there has been improvement made! But not perfect. In fact the Bug #28603 which was reported by me some time ago and later marked as "Bogus" has been fixed with this new release!! What I mean is that Apache does not crash on graceful restart anymore. Even the Apache-Worker behaves fine. I am getting debug messages in the error log file, but I guess that will be removed in the release version: [Thu Dec 02 00:42:28 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations [Thu Dec 02 00:43:28 2004] [notice] SIGUSR1 received. Doing graceful restart OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci [Thu Dec 02 00:43:29 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci It is somewhat strange that I get some OCIDebug START and END messages *after* the Apache has started, as shown above. If I do full restart via "/etc/init.d/apache2 restart", then sometimes I get the following: OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci [Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:47 2004] [warn] child process 18259 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:51 2004] [error] child process 18167 still did not exit, sending a SIGKILL [Thu Dec 02 00:57:51 2004] [error] child process 18259 still did not exit, sending a SIGKILL [Thu Dec 02 00:58:08 2004] [notice] SIGHUP received. Attempting to restart [Thu Dec 02 0
#30969 [Bgs]: XSLTProcessor Not Recognizing DOMDocument Root
ID: 30969
User updated by: c dot d at earthlink dot net
Reported By: c dot d at earthlink dot net
Status: Bogus
Bug Type: XSLT related
Operating System: Mac OS X 10.3.6
PHP Version: 5.0.2
New Comment:
Is not a bug
Previous Comments:
[2004-12-03 08:51:08] [EMAIL PROTECTED]
Your XSLT is wrong.. It needs to be
Your approach doesn't even work with xsltproc on the commandline.
and
"If identical xml is loaded from a file via DOMDocument->load the XSLT
processor processes the root element correctly."
Definitively not here on my system
[2004-12-03 00:46:35] c dot d at earthlink dot net
Description:
If xml is created via a DOMDocument and then sent to a XSLTProcessor
with a XSL file, the following xsl code doesn't find the root node:
You have to create a template for the root element (using it's name)
and use an apply-templates tag instead of value-of tag(s) in the root
template (such as above).
If identical xml is loaded from a file via DOMDocument->load the XSLT
processor processes the root element correctly.
Reproduce code:
---
createElement("root");
$root = $temp_DOM->appendChild($root);
$element = $temp_DOM->createElement("fullname");
$element = $root->appendChild($element);
$text = $temp_DOM->createTextNode("John Doe");
$text = $element->appendChild($text);
$xsl_DOM = new DOMDocument;
$xsl_DOM->load("test.xsl");
$xslt = new XSLTProcessor();
$xslt->importStylesheet($xsl_DOM);
echo $xslt->transformToXML($temp_DOM);
?>
Contents of XSL File
http://www.w3.org/1999/XSL/Transform";
version="1.0">
Expected result:
Should output xml declaration and value of "fullname" element.
Actual result:
--
Only outputs xml declaration. Value of "fullname" element is not
output.
--
Edit this bug report at http://bugs.php.net/?id=30969&edit=1
#30412 [Com]: Apache Segmentation Fault (11)
ID: 30412 Comment by: rathamahata at ehouse dot ru Reported By: subscription at nazarenko dot net Status: Open Bug Type: OCI8 related Operating System: SuSE Linux 8.2 PHP Version: 5.0.3RC1 New Comment: It looks like this happens (the browser would just wait with nothing happening) even with prefork mpm. strace shows Process 27641 attached - interrupt to quit futex(0x83967f0, FUTEX_WAIT, 2, NULL which is strange becouse apache is compiled with mpm=prefork `apache2 -l' Compiled in modules: core.c mod_access.c mod_auth.c mod_include.c mod_deflate.c mod_log_config.c mod_expires.c mod_setenvif.c prefork.c http_core.c mod_mime.c mod_status.c mod_autoindex.c mod_info.c mod_cgi.c mod_dir.c mod_alias.c mod_rewrite.c mod_so.c Previous Comments: [2004-12-02 15:17:32] subscription at nazarenko dot net Let me confirm it again after some more testing today that I still do get segfaults, but not that often than before. Also, let me point out that it seems to be exclusively Apache/PHP problem. The same script is run from the shell environment with no problems at all. Now to the example that you have asked for. It is really simple. In fact *any* Oracle query will cause occasional browser "hanging". Here is a bit of code I used today for testing: Most of the times this would work fine returning me an array of data. But sometimes the browser would just wait with nothing happening. And very rarely the page would fail immediately (producing a segfault in apache's error log) Hope this helps. [2004-12-02 01:20:38] [EMAIL PROTECTED] >[Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM I don't think PHP/OCI8 is causing this. I saw this problem many times without OCI8 enabled or even without any module enabled at all. >Some page loads are unsuccessful, but there >is no segfault! The browser just keeps waiting and waiting >and nothing I would be very thankful if you provide tiny reproduce script, that I can use to reproduce your problem. happens. [2004-12-02 01:05:47] subscription at nazarenko dot net Marking it as open... [2004-12-02 01:02:06] subscription at nazarenko dot net Hello again, Today I tried PHP 5.0.3RC1 with Apache 2.0.52 Worker and Oracle 9.2.0.4 Client for Linux. I'd say there has been improvement made! But not perfect. In fact the Bug #28603 which was reported by me some time ago and later marked as "Bogus" has been fixed with this new release!! What I mean is that Apache does not crash on graceful restart anymore. Even the Apache-Worker behaves fine. I am getting debug messages in the error log file, but I guess that will be removed in the release version: [Thu Dec 02 00:42:28 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations [Thu Dec 02 00:43:28 2004] [notice] SIGUSR1 received. Doing graceful restart OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci [Thu Dec 02 00:43:29 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci It is somewhat strange that I get some OCIDebug START and END messages *after* the Apache has started, as shown above. If I do full restart via "/etc/init.d/apache2 restart", then sometimes I get the following: OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci OCIDebug: START php_mshutdown_oci OCIDebug: END php_mshutdown_oci [Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:47 2004] [warn] child process 18259 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:51 2004] [error] child process 18167 still did not exit, sending a SIGKILL [Thu Dec 02 00:57:51 2004] [error] child process 18259 still did not exit, sending a SIGKILL [Thu Dec 02 00:58:08 2004] [notice] SIGHUP received. Attempting to restart [Thu Dec 02 00:58:08 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations ...which i guess is ok, since Apache restarts successfully after all. Now to the not so good news: Apache gives significantly less segfaults than before when performing Oracle queries but they still do happen occasionally. Actually, I get *really* ver
#30974 [NEW]: php4ts.lib - Access Violation while sql.safe_mode on
From: diablo dot 4711 at gmx dot de Operating system: Windows 2000 Pro PHP version: 4.3.10RC1 PHP Bug Type: Apache2 related Bug description: php4ts.lib - Access Violation while sql.safe_mode on Description: System: W2K Pro HTTPD: 2.0.52 PHP: 4.3.10RC1 MySQL: 4.0.21-nt Note: I read many postings about this bug with php4ts.dll, but none related to sql.safe_mode ... While sql.safe_mode = on i could not connect to any mysql database: > critical error: Unable to connect to database ! < and > Apache.exe cause Access Violation in php4ts.dll < If sql.safe_mode = off everything works as expected ... -- changes in php.ini: sql.safe_mode set to on max_execution_time set to 120 memory_limit set to 16M extension=php_gd2.dll activated -- default values also won't work ... only insql.safe_mode set to off apache/php works properly ... Reproduce code: --- php.ini: set sql.safe_mode = on ... try 2-3 times to connect to a mysql-database ... Expected result: proper database connection and displaying a php-forum ... Actual result: -- unable to connect to database, and access violation in php4ts.dll ... -- Edit bug report at http://bugs.php.net/?id=30974&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30974&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30974&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30974&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30974&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30974&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30974&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30974&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30974&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30974&r=support Expected behavior: http://bugs.php.net/fix.php?id=30974&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30974&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30974&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30974&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30974&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30974&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30974&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30974&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30974&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30974&r=mysqlcfg
#30973 [Opn->Csd]: segfault when accessing wrong url and get CURLINFO_CONTENT_TYPE
ID: 30973
User updated by: alberty at neptunelabs dot com
Reported By: alberty at neptunelabs dot com
-Status: Open
+Status: Closed
Bug Type: cURL related
Operating System: linux_i686
PHP Version: 4.3.9
New Comment:
Okay, i've seen that's fixed in 4.3.10
Previous Comments:
[2004-12-03 10:46:54] alberty at neptunelabs dot com
Description:
If you get a wrong url and get the content type via curl_getinfo($ch,
CURLINFO_CONTENT_TYPE); the cURL extention crashes with a segfault.
patch:
1213c1213,1215
< RETURN_STRING(s_code, 1);
---
> if (s_code){
> RETURN_STRING(s_code, 1);
> }
Regards,
Steve
Reproduce code:
---
http://www.totallywrongdomain.com/');
if ($ch){
$result=curl_exec ($ch);
$returnvalue['content_type']=curl_getinfo($ch,
CURLINFO_CONTENT_TYPE);
curl_close ($ch);
}
?>
--
Edit this bug report at http://bugs.php.net/?id=30973&edit=1
#30973 [NEW]: segfault when accessing wrong url and get CURLINFO_CONTENT_TYPE
From: alberty at neptunelabs dot com
Operating system: linux_i686
PHP version: 4.3.9
PHP Bug Type: cURL related
Bug description: segfault when accessing wrong url and get
CURLINFO_CONTENT_TYPE
Description:
If you get a wrong url and get the content type via curl_getinfo($ch,
CURLINFO_CONTENT_TYPE); the cURL extention crashes with a segfault.
patch:
1213c1213,1215
< RETURN_STRING(s_code, 1);
---
> if (s_code){
> RETURN_STRING(s_code, 1);
> }
Regards,
Steve
Reproduce code:
---
http://www.totallywrongdomain.com/');
if ($ch){
$result=curl_exec ($ch);
$returnvalue['content_type']=curl_getinfo($ch, CURLINFO_CONTENT_TYPE);
curl_close ($ch);
}
?>
--
Edit bug report at http://bugs.php.net/?id=30973&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30973&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30973&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30973&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30973&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30973&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30973&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30973&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30973&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30973&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30973&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30973&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30973&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30973&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30973&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30973&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30973&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30973&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30973&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30973&r=mysqlcfg
#30968 [Csd->Bgs]: Incorrect foreach() behavior
ID: 30968 Updated by: [EMAIL PROTECTED] Reported By: cow at neondragon dot net -Status: Closed +Status: Bogus Bug Type: Arrays related Operating System: Windows XP PHP Version: 4.3.10RC1 New Comment: Not a bug in PHP -> bogus. Previous Comments: [2004-12-03 10:27:46] cow at neondragon dot net Sorry, I should have tried that earlier. It seemed like the php.ini I was using from a previous version caused some problems; nothing to do with any extensions. Sorry! [2004-12-02 23:42:24] [EMAIL PROTECTED] Works fine here, please remove all Zend extensions from your configuration, and try again. [2004-12-02 23:30:33] cow at neondragon dot net Description: I'm pretty sure this isn't supposed to happen - it didn't happen with earlier versions of PHP, and nothing in the manual documents it. It happens with the RC of 4.3.10. Reproduce code: --- 1 [1] => 0 ) Array ( [0] => 2 [1] => 1 ) Array ( [0] => 3 [1] => 2 ) */ ?> Expected result: The string 1, then string 2, then string 3 - not arrays each time. -- Edit this bug report at http://bugs.php.net/?id=30968&edit=1
#30968 [Fbk->Csd]: Incorrect foreach() behavior
ID: 30968 User updated by: cow at neondragon dot net Reported By: cow at neondragon dot net -Status: Feedback +Status: Closed Bug Type: Arrays related Operating System: Windows XP PHP Version: 4.3.10RC1 New Comment: Sorry, I should have tried that earlier. It seemed like the php.ini I was using from a previous version caused some problems; nothing to do with any extensions. Sorry! Previous Comments: [2004-12-02 23:42:24] [EMAIL PROTECTED] Works fine here, please remove all Zend extensions from your configuration, and try again. [2004-12-02 23:30:33] cow at neondragon dot net Description: I'm pretty sure this isn't supposed to happen - it didn't happen with earlier versions of PHP, and nothing in the manual documents it. It happens with the RC of 4.3.10. Reproduce code: --- 1 [1] => 0 ) Array ( [0] => 2 [1] => 1 ) Array ( [0] => 3 [1] => 2 ) */ ?> Expected result: The string 1, then string 2, then string 3 - not arrays each time. -- Edit this bug report at http://bugs.php.net/?id=30968&edit=1
#30971 [Opn->Fbk]: highlight_string chokes bad when parsing strings containing newline escapes
ID: 30971
Updated by: [EMAIL PROTECTED]
Reported By: jed at jed dot bz
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: *
PHP Version: Irrelevant
New Comment:
Please fill in your PHP version.
Previous Comments:
[2004-12-03 00:56:32] jed at jed dot bz
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little more problematic
than it appears at first hand. The reproduce code below is what is
supposed to be highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
---
getFile())) {
$line = file($e->getFile());
$line = trim($line[$e->getLine() - 1]);
}
else $line = "?";
printf("\n\nSTOP. Uncaught exception \"%s\" in %s:%u\n" .
" >> %s\n" .
" Message: (%u) %s\n Backtrace:\n", get_class($e),
$e->getFile(),
$e->GetLine(), $line, $e->getCode(), $e->getMessage());
$i = 0;
foreach($e->getTrace() as $bt)
printf(" (#%u) %s()\n", ++$i, $bt['class'] . $bt['type'] .
$bt['function'],
$bt['file'], $bt['line']);
printf("\n\n");
exit(0xFE);
}
Expected result:
http://labs.jed.bz/phpbug4.png
Actual result:
--
http://labs.jed.bz/phpbug3.png
(Sporadically)
--
Edit this bug report at http://bugs.php.net/?id=30971&edit=1
