#30725 [NEW]: PHP segfaults when an exception is thrown in getIterator() within foreach
From: benjcarson at digitaljunkies dot ca
Operating system: Linux
PHP version: 5CVS-2004-11-09 (dev)
PHP Bug Type: Reproducible crash
Bug description: PHP segfaults when an exception is thrown in getIterator()
within foreach
Description:
When an object implementing IteratorAggregate is used within a foreach
loop, PHP will segfault if an exception is thrown within getIterator().
Reproduce code:
---
?php
class Iter implements IteratorAggregate {
function getIterator() {
throw new Exception('exception');
}
}
$test = new Iter();
foreach($test as $val)
echo foo;
?
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'exception' in
/home/benj/projects/bugs/spl_foreach.php:5
Stack trace:
#0 {main}
thrown in /home/benj/projects/bugs/spl_foreach.php on line 5
Actual result:
--
Segmentation fault (core dumped)
Here's a backtrace:
#0 zend_user_it_get_new_iterator (ce=0x8515b64, object=0x850622c) at
/usr/src/php/php-src/Zend/zend_interfaces.c:273
#1 0x08251d8c in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbfffd590)
at zend_vm_execute.h:18131
#2 0x0821b448 in execute (op_array=0x851068c) at zend_vm_execute.h:58
#3 0x081f981f in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/src/php/php-src/Zend/zend.c:1053
#4 0x081bd5bf in php_execute_script (primary_file=0xb990) at
/usr/src/php/php-src/main/main.c:1634
#5 0x0828704e in main (argc=2, argv=0xba54) at
/usr/src/php/php-src/sapi/cli/php_cli.c:943
--
Edit bug report at http://bugs.php.net/?id=30725edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30725r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30725r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30725r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30725r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30725r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30725r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30725r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30725r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30725r=support
Expected behavior: http://bugs.php.net/fix.php?id=30725r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30725r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30725r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30725r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30725r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30725r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30725r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30725r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30725r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30725r=mysqlcfg
#30285 [Opn-Csd]: switch statement: default executed when case matches
ID: 30285
User updated by: benjcarson at digitaljunkies dot ca
Reported By: benjcarson at digitaljunkies dot ca
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Debian Linux
PHP Version: 5CVS-2004-09-30 (dev)
New Comment:
As per discussion on [EMAIL PROTECTED], this has been fixed in
CVS (5.1.x-dev). Thanks Andi.
Previous Comments:
[2004-10-13 03:34:11] dev at null dot dk
got expected result in php version 4.3.1 running under apache.
[2004-10-08 22:49:09] paco at arsteca dot net
got expected result with 4.3.2, including CLI
[2004-10-08 16:25:50] Jared dot Williams1 at ntlworld dot com
5.0.2 does produce the expected result, as does 4.3.8
[2004-09-30 05:25:18] benjcarson at digitaljunkies dot ca
Description:
It seems that the default: block of a switch statement now
short-circuits the remaining case: tests. If the default: block is put
before a matching case: block, it will _always_ be executed. While the
docs (http://www.php.net/manual/en/control-structures.switch.php) do
recommend making default: last, this is a BC break (tested with 5.0.0
and 4.3.2).
This bug is also present at least as early as the 5.1.x-dev 2004-09-25
snap (sorry, the next earliest one I have is 5.0.0).
The reproduce code below works if the default: block is put after the
case a: block.
Reproduce code:
---
?php
$x = a;
switch ($x) {
default:
echo default\n;
break;
case a:
echo case: a\n;
break;
}
?
Expected result:
case: a
Actual result:
--
default
--
Edit this bug report at http://bugs.php.net/?id=30285edit=1
#30285 [NEW]: switch statement: default executed when case matches
From: benjcarson at digitaljunkies dot ca
Operating system: Debian Linux
PHP version: 5CVS-2004-09-30 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: switch statement: default executed when case matches
Description:
It seems that the default: block of a switch statement now short-circuits
the remaining case: tests. If the default: block is put before a matching
case: block, it will _always_ be executed. While the docs
(http://www.php.net/manual/en/control-structures.switch.php) do recommend
making default: last, this is a BC break (tested with 5.0.0 and 4.3.2).
This bug is also present at least as early as the 5.1.x-dev 2004-09-25
snap (sorry, the next earliest one I have is 5.0.0).
The reproduce code below works if the default: block is put after the case
a: block.
Reproduce code:
---
?php
$x = a;
switch ($x) {
default:
echo default\n;
break;
case a:
echo case: a\n;
break;
}
?
Expected result:
case: a
Actual result:
--
default
--
Edit bug report at http://bugs.php.net/?id=30285edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30285r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30285r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30285r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30285r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30285r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30285r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30285r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30285r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30285r=support
Expected behavior: http://bugs.php.net/fix.php?id=30285r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30285r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30285r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30285r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30285r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30285r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30285r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30285r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30285r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30285r=mysqlcfg
#29620 [NEW]: money_format treats 0.00*-1 strangely
From: benjcarson at digitaljunkies dot ca Operating system: Linux PHP version: 5CVS-2004-08-11 (dev) PHP Bug Type: Strings related Bug description: money_format treats 0.00*-1 strangely Description: When using the format '%(n' (i.e. represent negative numbers in parenthesis), money_format still prints out a negative sign when its second parameter is 0.00*-1. It works fine for the following values, however: -0.00 -0 0*-1 -1*0 -1*0.00 -1.00*0 (Note: echo(0.00*-1) prints out -0.) Interestingly, using gcc-3.3.4 and glibc-2.3.2, the following fails in a similar fashion: strfmon(buf, sizeof(buf), %(n, atof(-0.00)); /* buf = -0.00 */ double val = 0.00 * -1; strfmon(buf, sizeof(buf), %(n, val); /* buf = -0.00 */ double val = -1*0.00; strfmon(buf, sizeof(buf), %(n, val); /* buf = -0.00 */ It appears it might have something to do with strfmon()'s handling of 'negative zero', except money_format() works correctly for values where strfmon() fails (e.g. -1*0.00). Reproduce code: --- echo money_format(%(n, 0.00*-1) . \n; Expected result: 0.00 or even (0.00) Actual result: -- -0.00 -- Edit bug report at http://bugs.php.net/?id=29620edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29620r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29620r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29620r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29620r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29620r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29620r=needscript Try newer version: http://bugs.php.net/fix.php?id=29620r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29620r=support Expected behavior: http://bugs.php.net/fix.php?id=29620r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29620r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29620r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29620r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29620r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29620r=dst IIS Stability: http://bugs.php.net/fix.php?id=29620r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29620r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29620r=float
#29234 [Com]: empty($object-property) incorrect when property has access overloaded (__get)
ID: 29234
Comment by: benjcarson at digitaljunkies dot ca
Reported By: chrissy at codegoat dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows XP
PHP Version: 5.0.0
New Comment:
This may be related to bug #28176.
Previous Comments:
[2004-07-18 01:14:15] chrissy at codegoat dot com
Description:
The code below has a class with two properties. One which is a regular
public class property and the other which is accessed through the __get
function. Both are set to Not Empty. However, when you call empty()
on the one accessed through __get, the empty() function returns TRUE
which is incorrect. The problem can be remedied by first assigning the
value of the property to a variable and then calling the empty function
on that variable.
Reproduce code:
---
?php
class EmptyTest {
public $emptyTest1 = Not Empty;
protected $properties = array ('emptyTest2' = Not Empty);
function __get($key) {
if (array_key_exists($key, $this-properties)) return
$this-properties[$key];
}
}
$emptyTest = new EmptyTest();
echo The value of Test 1 is: \ . $emptyTest-emptyTest1 .
\br/The value of Test 2 is: \ . $emptyTest-emptyTest2 .
\br/---br/br/;
if (empty($emptyTest-emptyTest1)) echo Test 1 was empty br/;
else echo Test 1 was not empty br/;
if (empty($emptyTest-emptyTest2))echo Test 2 was empty br/;
else echo Test 2 was not empty br/;
$test = $emptyTest-emptyTest2;
if (empty($test))echo Test 2 was empty this timebr/;
else echo Test 2 was not empty this timebr/;
?
Expected result:
Both emptyTest1 and emptyTest2, when passed to the empty function, the
function should return true.
It could be that calling empty with a property that has had its access
overloaded by the __get function is invalid. If this is the case, I
would assume empty should at least throw a Warning.
Actual result:
--
The output of the above program is...
The value of Test 1 is: Not Empty
The value of Test 2 is: Not Empty
---
Test 1 was not empty
Test 2 was empty
Test 2 was not empty this time
--
Edit this bug report at http://bugs.php.net/?id=29234edit=1
#29023 [Asn]: fread() only reads 8192 bytes from a local file
ID: 29023 User updated by: benjcarson at digitaljunkies dot ca Reported By: benjcarson at digitaljunkies dot ca Status: Assigned Bug Type: Filesystem function related Operating System: Linux PHP Version: 5CVS-2004-07-05 (dev) Assigned To: wez New Comment: While I realize that file_get_contents() is faster, the code that lead me to this bug was not my own. It was Smarty (2.6.2, although 2.6.3 has the same problem), which has worked very well with PHP5 until now. Previous Comments: [2004-07-06 15:26:51] [EMAIL PROTECTED] I really can't see how this can be CORRECT behaviour as this has worked (like it says in docs too :) before just fine. OTOH, you should always use file_get_contents() instead anyway. :) [2004-07-06 09:14:52] [EMAIL PROTECTED] Assigning to Wez... although I'd say that this is *correct* behavior, it shouldn't cause a BC break. [2004-07-05 22:28:48] benjcarson at digitaljunkies dot ca Description: In the latest cvs snap, fread() does not read more than 8192 bytes from a local file, despite specifying a larger read size as the second parameter. If the fread() call is wrapped in a while (!feof) loop the file can be read correctly, but only 8k at a time. This contradicts the first example in the manual (http://www.php.net/manual/en/function.fread.php) and is a BC break. As far as I can tell the change was made sometime between the 2004-06-22 snap and the 2004-07-04 snap. I've tested both using my php.ini file and without (i.e. using the built-in defaults). I configured using the following command: ./configure --prefix=/usr --with-apxs=/usr/bin/apxs \ --enable-memory-limit \ --with-layout-GNU\ --enable-bcmath \ --enable-calendar \ --with-curl=/usr \ --enable-exif \ --enable-ftp \ --enable-mbstring \ --enable-shmop \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-wddx \ --with-bz2 \ --with-config-file-path=/etc/php5/apache \ --with-gd=/usr \ --with-freetype-dir=shared,/usr \ --with-jpeg-dir=/usr \ --with-png-dir=shared,/usr \ --with-ttf=shared,/usr \ --with-xpm-dir=shared,/usr/X11R6 \ --with-gettext \ --with-kerberos=/usr \ --with-ldap=shared,/usr \ --with-mhash=shared,/usr \ --with-mm \ --with-ncurses=/usr \ --with-openssl=/usr \ --with-pcre-regex=/usr \ --with-pear \ --with-pgsql \ --with-pspell=/usr \ --with-zlib \ --with-zlib-dir=/usr Reproduce code: --- #!/usr/bin/php ?php $filename = /some/largish/local/file; $fd = fopen($filename, 'r'); $contents = fread($fd, filesize($filename)); echo strlen($contents) .\n; fclose($fd); ? Expected result: (the file's actual size, in bytes) Actual result: -- 8192 -- Edit this bug report at http://bugs.php.net/?id=29023edit=1
#29023 [NEW]: fread() only reads 8192 bytes from a local file
From: benjcarson at digitaljunkies dot ca Operating system: Linux PHP version: 5CVS-2004-07-05 (dev) PHP Bug Type: Filesystem function related Bug description: fread() only reads 8192 bytes from a local file Description: In the latest cvs snap, fread() does not read more than 8192 bytes from a local file, despite specifying a larger read size as the second parameter. If the fread() call is wrapped in a while (!feof) loop the file can be read correctly, but only 8k at a time. This contradicts the first example in the manual (http://www.php.net/manual/en/function.fread.php) and is a BC break. As far as I can tell the change was made sometime between the 2004-06-22 snap and the 2004-07-04 snap. I've tested both using my php.ini file and without (i.e. using the built-in defaults). I configured using the following command: ./configure --prefix=/usr --with-apxs=/usr/bin/apxs \ --enable-memory-limit \ --with-layout-GNU\ --enable-bcmath \ --enable-calendar \ --with-curl=/usr \ --enable-exif \ --enable-ftp \ --enable-mbstring \ --enable-shmop \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-wddx \ --with-bz2 \ --with-config-file-path=/etc/php5/apache \ --with-gd=/usr \ --with-freetype-dir=shared,/usr \ --with-jpeg-dir=/usr \ --with-png-dir=shared,/usr \ --with-ttf=shared,/usr \ --with-xpm-dir=shared,/usr/X11R6 \ --with-gettext \ --with-kerberos=/usr \ --with-ldap=shared,/usr \ --with-mhash=shared,/usr \ --with-mm \ --with-ncurses=/usr \ --with-openssl=/usr \ --with-pcre-regex=/usr \ --with-pear \ --with-pgsql \ --with-pspell=/usr \ --with-zlib \ --with-zlib-dir=/usr Reproduce code: --- #!/usr/bin/php ?php $filename = /some/largish/local/file; $fd = fopen($filename, 'r'); $contents = fread($fd, filesize($filename)); echo strlen($contents) .\n; fclose($fd); ? Expected result: (the file's actual size, in bytes) Actual result: -- 8192 -- Edit bug report at http://bugs.php.net/?id=29023edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29023r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29023r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29023r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29023r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29023r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29023r=needscript Try newer version: http://bugs.php.net/fix.php?id=29023r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29023r=support Expected behavior: http://bugs.php.net/fix.php?id=29023r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29023r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29023r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29023r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29023r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29023r=dst IIS Stability: http://bugs.php.net/fix.php?id=29023r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29023r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29023r=float
#28796 [Com]: Apache eat all Memory (parent::$this-__construct())
ID: 28796
Comment by: benjcarson at digitaljunkies dot ca
Reported By: felix at trilithium dot de
Status: Open
Bug Type: Apache related
Operating System: Linux version 2.4.21-199-default
PHP Version: 5.0.0RC3
New Comment:
$this-__construct() is a recursive call to secondClass' constructor.
Since the constructor never returns, the recursion never bottoms out;
it is effectively an infinite loop. Each call consumes space on the
stack, so eventually PHP chews up all available memory and dies.
You would see the same behaviour if secondClass' constructor was:
function __construct() {
$this-__construct();
}
What you really want, as alex dot pagnoni at solarix dot it has pointed
out is:
function __construct() {
parent::__construct();
}
Previous Comments:
[2004-06-17 13:38:32] alex dot pagnoni at solarix dot it
is parent::$this-__construct() the correct syntax? Wasn't
it supposed to be parent::__construct()?
[2004-06-15 17:03:13] felix at trilithium dot de
Description:
Apache eat all memory when your try the example code
Reproduce code:
---
class firstClass{
function __construct(){
echo __CLASS__.::.__FUNCTION__.br;
}
function test(){
echo __CLASS__.::.__FUNCTION__.br;
return $this;
}
}
class secondClass extends firstClass{
function __construct(){
echo __CLASS__.::.__FUNCTION__.br;
parent::$this-__construct(); //-here Apache eat all memory
//parent::$this-test(); // this works
}
}
$e= new secondClass;
--
Edit this bug report at http://bugs.php.net/?id=28796edit=1
#28820 [NEW]: Relative paths do not work with 'file://' stream wrapper
From: benjcarson at digitaljunkies dot ca Operating system: Linux PHP version: 5CVS-2004-06-17 (dev) PHP Bug Type: Filesystem function related Bug description: Relative paths do not work with 'file://' stream wrapper Description: When using fopen_wrappers, if a relative path is prepended with 'file://', fopen() and friends fail and emit a warning about remote access being unsupported for file access. fopen() succeeds if 'file://' is omitted. On a possibly related note, parse_url(file://test.php) returns array(scheme = file, host = test.php). I would imagine this is the desired behaviour for remote protocols (e.g. 'http://php.net'). However, if the fopen wrapper for 'file://' is calling parse_url() internally, this could explain why the error message is complaining about remote hosts. I'm not familiar with the stream internals, though, so I might be way off here... And just in case anyone asks: [EMAIL PROTECTED]:test$ php -r 'print_r(stream_get_wrappers());' Array ( [0] = php [1] = file [2] = http [3] = ftp [4] = compress.bzip2 [5] = compress.zlib [6] = https [7] = ftps ) Reproduce code: --- #!/usr/bin/php ?php // Note: 'test.php' exists in the current directory $filename = test.php; $f1 = fopen($filename, r); // works $f2 = fopen(file://. $filename, r);// fails $f3 = fopen(realpath($filename), r); // works $f4 = fopen(file:// . realpath($filename), r); // works ? Expected result: (no output) Actual result: -- Warning: fopen(): remote host file access not supported, file://test.php in ./file_get_contents.php on line 6 Warning: fopen(file://test.php): failed to open stream: no suitable wrapper could be found in ./file_get_contents.php on line 6 -- Edit bug report at http://bugs.php.net/?id=28820edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28820r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28820r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28820r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28820r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28820r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28820r=needscript Try newer version: http://bugs.php.net/fix.php?id=28820r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28820r=support Expected behavior: http://bugs.php.net/fix.php?id=28820r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28820r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28820r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28820r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28820r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28820r=dst IIS Stability: http://bugs.php.net/fix.php?id=28820r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28820r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28820r=float
#28820 [WFx]: Relative paths do not work with 'file://' stream wrapper
ID: 28820
User updated by: benjcarson at digitaljunkies dot ca
Reported By: benjcarson at digitaljunkies dot ca
Status: Wont fix
Bug Type: Filesystem function related
Operating System: Linux
PHP Version: 5CVS-2004-06-17 (dev)
New Comment:
Thanks for the explanation the doc fix. What you say makes perfect
sense.
Previous Comments:
[2004-06-18 00:29:52] [EMAIL PROTECTED]
On the note about parse_url(), no fopen() does not call parse_url to
determine wrapper usage.
The reason relative paths are not supported with the file:// wrapper
comes down to a compromise in how UNC paths are dealt with (and more
specifically how / are fuzzily interpreted as \ for windows
installations).
For Example:
file://foo/bar
Could be interpreted as a relative URI: foo/bar from the current
working directory, OR it could be interpreted as a UNC: \\foo\bar
(share `bar` on computer `foo`).
For this and a few internal reasons the file:// wrapper is limited to
absolute paths when called explicitly. For relative paths either use
realpath() {as you did in your report}, or omit the explicit naming of
the file wrapper.
I notice that the wording on http://www.php.net/wrappers regarding
relative paths is a touch ambiguous. I'll update that to show that
only absolute paths are supported when explicitly naming the wrapper.
[2004-06-17 22:39:25] benjcarson at digitaljunkies dot ca
Description:
When using fopen_wrappers, if a relative path is prepended with
'file://', fopen() and friends fail and emit a warning about remote
access being unsupported for file access. fopen() succeeds if
'file://' is omitted.
On a possibly related note, parse_url(file://test.php) returns
array(scheme = file, host = test.php). I would imagine this is
the desired behaviour for remote protocols (e.g. 'http://php.net').
However, if the fopen wrapper for 'file://' is calling parse_url()
internally, this could explain why the error message is complaining
about remote hosts. I'm not familiar with the stream internals,
though, so I might be way off here...
And just in case anyone asks:
[EMAIL PROTECTED]:test$ php -r 'print_r(stream_get_wrappers());'
Array
(
[0] = php
[1] = file
[2] = http
[3] = ftp
[4] = compress.bzip2
[5] = compress.zlib
[6] = https
[7] = ftps
)
Reproduce code:
---
#!/usr/bin/php
?php
// Note: 'test.php' exists in the current directory
$filename = test.php;
$f1 = fopen($filename, r); // works
$f2 = fopen(file://. $filename, r);// fails
$f3 = fopen(realpath($filename), r); // works
$f4 = fopen(file:// . realpath($filename), r); // works
?
Expected result:
(no output)
Actual result:
--
Warning: fopen(): remote host file access not supported,
file://test.php in ./file_get_contents.php on line 6
Warning: fopen(file://test.php): failed to open stream: no suitable
wrapper could be found in ./file_get_contents.php on line 6
--
Edit this bug report at http://bugs.php.net/?id=28820edit=1
#28721 [Fbk-Opn]: appendChild() and insertBefore() unset DOMText node arguments (includes patch)
ID: 28721
User updated by: benjcarson at digitaljunkies dot ca
Reported By: benjcarson at digitaljunkies dot ca
-Status: Feedback
+Status: Open
Bug Type: DOM XML related
Operating System: Linux
PHP Version: 5CVS-2004-06-10 (dev)
New Comment:
The new patch seems to work great! Thanks. Would you like my test
cases for ext/dom/tests?
Previous Comments:
[2004-06-11 14:12:16] [EMAIL PROTECTED]
Can you try again with an updated patch:
http://ctindustries.net/dom/dom_node.diff.txt
[2004-06-11 01:00:06] benjcarson at digitaljunkies dot ca
Well, the text node stuff seems to work well, but when I tried adding a
document fragment, php segfaulted. It also seemed to modify other
parts of the tree. Try running the test script below, and note how $p
eventually includes nodes from $d.
Here's my test code:
?php
function print_node(DomNode $node) {
echo name (value): . $node-nodeName . ( . $node-nodeValue .
)\n;
}
$xml = new DomDocument();
$p = $xml-createElement(p);
$p-appendChild($p1 = $xml-createTextNode( p1 ));
$p-appendChild($b = $xml-createElement(b));
$b-appendChild($xml-createTextNode(p2));
$p-appendChild($p3 = $xml-createTextNode( p3 ));
$p-appendChild($xml-createTextNode( p4 ));
$d = $xml-createElement(div);
$d-appendChild($d1 = $xml-createTextNode( d1 ));
$d-appendChild($b2 = $xml-createElement(b));
$b2-appendChild($xml-createTextNode(d2));
$d-appendChild($d3 = $xml-createTextNode( d3 ));
$d-appendChild($xml-createTextNode( d4 ));
$frag = $xml-createDocumentFragment();
$t5 = $frag-appendChild($xml-createTextNode( frag1 ));
$frag-appendChild($i = $xml-createElement(i));
$i-appendChild($xml-createTextNode( frag2 ));
$frag-appendChild($xml-createTextNOde( frag3 ));
echo \np:\n;
print_node($p);
echo \nFragment:\n;
print_node($frag);
echo \nAppending fragment to p:\n;
$p-appendChild($frag);
print_node($p);
echo \nFragment:\n;
print_node($frag);
print_node($d);
echo \nInserting fragment before d1\n;
// If the next line is executed, php segfaults on exit:
$d-insertBefore($frag, $d1);
print_node($d);
echo \np:\n;
print_node($p);
?
Here's a gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1080672096 (LWP 7486)]
php_libxml_decrement_node_ptr (object=0x84990e8) at
/usr/src/php/php5-200406091430/ext/libxml/libxml.c:569
569 ret_refcount = --obj_node-refcount;
(gdb) bt
#0 php_libxml_decrement_node_ptr (object=0x84990e8) at
/usr/src/php/php5-200406091430/ext/libxml/libxml.c:569
#1 0x080873f0 in php_libxml_clear_object (object=0x84990e8) at
/usr/src/php/php5-200406091430/ext/libxml/libxml.c:131
#2 0x0808742e in php_libxml_unregister_node (nodep=0x0) at
/usr/src/php/php5-200406091430/ext/libxml/libxml.c:144
#3 0x0808759b in php_libxml_node_free_list (node=0x84991d0) at
/usr/src/php/php5-200406091430/ext/libxml/libxml.c:222
#4 0x0808823b in php_libxml_node_free_resource (node=0x8498c60) at
/usr/src/php/php5-200406091430/ext/libxml/libxml.c:631
#5 0x080882e5 in php_libxml_node_decrement_resource
(object=0x406a965c) at
/usr/src/php/php5-200406091430/ext/libxml/libxml.c:665
#6 0x080a03b2 in dom_objects_free_storage (object=0x406a965c) at
/usr/src/php/php5-200406091430/ext/dom/php_dom.c:773
#7 0x0822349d in zend_objects_store_del_ref (zobject=0x0) at
/usr/src/php/php5-200406091430/Zend/zend_objects_API.c:149
#8 0x0820e673 in _zval_dtor (zvalue=0x406a963c) at
/usr/src/php/php5-200406091430/Zend/zend_variables.c:61
#9 0x08205508 in _zval_ptr_dtor (zval_ptr=0x406a9720) at
/usr/src/php/php5-200406091430/Zend/zend_execute_API.c:391
#10 0x082168f8 in zend_hash_apply_deleter (ht=0x83fadf0, p=0x406a9714)
at /usr/src/php/php5-200406091430/Zend/zend_hash.c:568
#11 0x0821699c in zend_hash_graceful_reverse_destroy (ht=0x83fadf0) at
/usr/src/php/php5-200406091430/Zend/zend_hash.c:634
#12 0x08205342 in shutdown_executor () at
/usr/src/php/php5-200406091430/Zend/zend_execute_API.c:210
#13 0x0820fc64 in zend_deactivate () at
/usr/src/php/php5-200406091430/Zend/zend.c:819
#14 0x081d55d8 in php_request_shutdown (dummy=0x0) at
/usr/src/php/php5-200406091430/main/main.c:1212
#15 0x08243696 in main (argc=3, argv=0xba54) at
/usr/src/php/php5-200406091430/sapi/cli/php_cli.c:1046
[2004-06-10 22:34:36] [EMAIL PROTECTED]
Can you try with this patch? The text nodes piece is working fine.
Havent had a chance to test out the domfragment stuff yet. I would like
to use libxml functions as much as possible any only fall back to
custom coding when absolutely necessary.
http://ctindustries.net/dom/dom_node.diff.txt
[2004-06-10 20:22:41] benjcarson at digitaljunkies dot ca
There was a bug with insertBefore
#28721 [Opn]: appendChild() and insertBefore() unset DOMText node arguments (includes patch)
ID: 28721 User updated by: benjcarson at digitaljunkies dot ca Reported By: benjcarson at digitaljunkies dot ca Status: Open Bug Type: DOM XML related Operating System: Linux PHP Version: 5CVS-2004-06-10 (dev) New Comment: There was a bug with insertBefore() in the patch. If you downloaded the patch prior to this post, please download it again. Previous Comments: [2004-06-10 07:12:43] benjcarson at digitaljunkies dot ca Description: If a DOMText node is added to a node using appendChild() or insertBefore(), the node is destroyed (i.e. the parameter's properties are cleared) and a new node is returned instead. In addition, when a text node is inserted it is collapsed with adjacent text nodes. This behaviour is inconsistent with other DOM implementations (e.g. Mozilla, gdome). It means that code like this: $p-appendChild($textNode); will unset all of $textNode's properties. Here is an html version of the reproduce code, for an example of what your browser does: http://www.digitaljunkies.ca/~benj/dom_insert_demo.php I've tried to fix this and I've rolled a patch available at: http://www.digitaljunkies.ca/~benj/node.c.diff Basically what I've done is remove any special handling of text nodes. In appendChild() I also manually add the child to the parent's children list. This is because xmlAddChild collapses adjacent text nodes. (I figure that if adjacent text nodes need to be collapsed, users can use DomDocument::normalize().) In looking at the code, there may be a similar problem with attribute nodes, but since I'm not as familliar with manipulating them, I'm not sure what the desired behaviour should be. Please indicate if there are any problems with the patch. Thanks. Reproduce code: --- #!/usr/bin/php ?php $xml = new DomDocument(); $p = $xml-createElement(p); $p-appendChild($t1 = $xml-createTextNode( t1 )); $p-appendChild($b = $xml-createElement(b)); $b-appendChild($xml-createTextNode(X)); $p-appendChild($t2 = $xml-createTextNode()); $ret = $p-appendChild($t1); var_dump($t1-nodeName); var_dump($ret-nodeName); var_dump( $t1 === $ret ); var_dump( $p-lastChild-nodeValue ); ? Expected result: string(5) #text string(5) #text bool(true) string(4) t1 Actual result: -- NULL string(5) #text bool(false) string(8) t2 t1 -- Edit this bug report at http://bugs.php.net/?id=28721edit=1
#28721 [NEW]: appendChild() and insertBefore() unset DOMText node arguments (includes patch)
From: benjcarson at digitaljunkies dot ca Operating system: Linux PHP version: 5CVS-2004-06-10 (dev) PHP Bug Type: DOM XML related Bug description: appendChild() and insertBefore() unset DOMText node arguments (includes patch) Description: If a DOMText node is added to a node using appendChild() or insertBefore(), the node is destroyed (i.e. the parameter's properties are cleared) and a new node is returned instead. In addition, when a text node is inserted it is collapsed with adjacent text nodes. This behaviour is inconsistent with other DOM implementations (e.g. Mozilla, gdome). It means that code like this: $p-appendChild($textNode); will unset all of $textNode's properties. Here is an html version of the reproduce code, for an example of what your browser does: http://www.digitaljunkies.ca/~benj/dom_insert_demo.php I've tried to fix this and I've rolled a patch available at: http://www.digitaljunkies.ca/~benj/node.c.diff Basically what I've done is remove any special handling of text nodes. In appendChild() I also manually add the child to the parent's children list. This is because xmlAddChild collapses adjacent text nodes. (I figure that if adjacent text nodes need to be collapsed, users can use DomDocument::normalize().) In looking at the code, there may be a similar problem with attribute nodes, but since I'm not as familliar with manipulating them, I'm not sure what the desired behaviour should be. Please indicate if there are any problems with the patch. Thanks. Reproduce code: --- #!/usr/bin/php ?php $xml = new DomDocument(); $p = $xml-createElement(p); $p-appendChild($t1 = $xml-createTextNode( t1 )); $p-appendChild($b = $xml-createElement(b)); $b-appendChild($xml-createTextNode(X)); $p-appendChild($t2 = $xml-createTextNode()); $ret = $p-appendChild($t1); var_dump($t1-nodeName); var_dump($ret-nodeName); var_dump( $t1 === $ret ); var_dump( $p-lastChild-nodeValue ); ? Expected result: string(5) #text string(5) #text bool(true) string(4) t1 Actual result: -- NULL string(5) #text bool(false) string(8) t2 t1 -- Edit bug report at http://bugs.php.net/?id=28721edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28721r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28721r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28721r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28721r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28721r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28721r=needscript Try newer version: http://bugs.php.net/fix.php?id=28721r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28721r=support Expected behavior: http://bugs.php.net/fix.php?id=28721r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28721r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28721r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28721r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28721r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28721r=dst IIS Stability: http://bugs.php.net/fix.php?id=28721r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28721r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28721r=float
#28584 [NEW]: DOMText::splitText() does not split text properly (includes patch)
From: benjcarson at digitaljunkies dot ca
Operating system: Linux
PHP version: 5CVS-2004-05-30 (dev)
PHP Bug Type: DOM XML related
Bug description: DOMText::splitText() does not split text properly (includes patch)
Description:
DOMText-splitText() does not split text nodes correctly. The node
returned from the splitText() includes text from additional DOMText nodes
following the one being split. Instead, the returned node should only
containg text that was in the original node, following the split offset.
Here is a html version of the reproduce code, along with some javascript
to demonstrate the splitText() method:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
meta http-equiv=Content-Type content=text/html; charset=iso-8859-15
/head
body
p id=p onclick=splitText(this)text1ii/itext2/p
script type=text/javascript
function splitText(node) {
text1 = node.firstChild;
split = text1.splitText(2);
text2 = node.lastChild;
str = 'text1: ' + text1.nodeValue + '\n' +
'split: ' + split.nodeValue + '\n' +
'text2: ' + text2.nodeValue;
alert(str);
}
/script
/body/html
It turns out the fix for this is a 1-liner in ext/dom/text.c. I've
created a diff available here:
http://www.digitaljunkies.ca/~benj/text.c.diff
Reproduce code:
---
#!/usr/bin/php
?php
$xml = new DomDocument();
$p = $xml-createElement(p);
$p-insertBefore($text1 = $xml-createTextNode(text1));
$p-insertBefore($i = $xml-createElement(i));
$i-insertBefore($itext = $xml-createTextNode(i));
$p-insertBefore($text2 = $xml-createTextNode(text2));
$split = $text1-splitText(2);
echo (text1: . $text1-nodeValue . \n);
echo (split: . $split-nodeValue . \n);
echo (text2: . $text2-nodeValue .\n);
?
Expected result:
text1: te
split: xt1
text2: text2
Actual result:
--
text1: te
split: xt1text2
text2: text2
--
Edit bug report at http://bugs.php.net/?id=28584edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28584r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28584r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28584r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28584r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28584r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28584r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28584r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28584r=support
Expected behavior: http://bugs.php.net/fix.php?id=28584r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28584r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28584r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28584r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28584r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28584r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28584r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28584r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28584r=float
#28176 [Opn]: isset() returns false for properties returned from __get()
ID: 28176
User updated by: benjcarson at digitaljunkies dot ca
Reported By: benjcarson at digitaljunkies dot ca
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2004-04-27 (dev)
New Comment:
It may come as no surprise, but I figure I should also mention it here
for completeness: empty() displays the same behaviour--it does not call
__get() either and returns true for variables that are set and
retrieved via __get().
Obviously I agree with amt at php.net and think these are bugs. For
now, I'm working around this with:
!is_null($f-key);
From a user's point of view, the fact that this works and
isset()/empty() do not is inconsistent. Of course, knowing that
isset()/empty() are language constructs and is_null() a function
explains the behaviour, but I still think it is incorrect.
Previous Comments:
[2004-04-27 08:42:15] [EMAIL PROTECTED]
Hum. I think it's a good idea to modify isset() to call
__get() and __set().
Otherwise, it breaks the principle of encapsulation. As
a user of the class, I'm not supposed to know/care if
I'm accessing the properties directly or if the
developer has overloaded the property handler.
Besides, how else as a user can I check if a property is
set if I can't use isset()?
[2004-04-27 08:31:59] [EMAIL PROTECTED]
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 correct behavior, isset() does not call the __get and __set
handlers.
[2004-04-27 03:57:42] benjcarson at digitaljunkies dot ca
Description:
isset() returns false for variables that are returned using the __get()
method, even though the variables are set and their values are returned
properly.
Reproduce code:
---
?php
class Foo { var $arr; function __get($var) { return $this-arr[$var]; }
}
class Bar { var $var; function __get($tmp) { return $this-var; } }
$f = new Foo();
$f-arr[key] = val;
var_dump($f-key); // Value returned correctly
var_dump(isset($f-key));// isset() disagrees
$b = new Bar();
$b-var = blah;
var_dump($b-dummy); // Value returned correctly
var_dump(isset($b-dummy)); // isset() returns false
?
Expected result:
string(3) val
bool(true)
string(4) blah
bool(true)
Actual result:
--
string(3) val
bool(false)
string(4) blah
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=28176edit=1
#28176 [NEW]: isset() returns false for properties returned from __get()
From: benjcarson at digitaljunkies dot ca
Operating system: Linux
PHP version: 5CVS-2004-04-27 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: isset() returns false for properties returned from __get()
Description:
isset() returns false for variables that are returned using the __get()
method, even though the variables are set and their values are returned
properly.
Reproduce code:
---
?php
class Foo { var $arr; function __get($var) { return $this-arr[$var]; } }
class Bar { var $var; function __get($tmp) { return $this-var; } }
$f = new Foo();
$f-arr[key] = val;
var_dump($f-key); // Value returned correctly
var_dump(isset($f-key));// isset() disagrees
$b = new Bar();
$b-var = blah;
var_dump($b-dummy); // Value returned correctly
var_dump(isset($b-dummy)); // isset() returns false
?
Expected result:
string(3) val
bool(true)
string(4) blah
bool(true)
Actual result:
--
string(3) val
bool(false)
string(4) blah
bool(false)
--
Edit bug report at http://bugs.php.net/?id=28176edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28176r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28176r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28176r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28176r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28176r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28176r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28176r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28176r=support
Expected behavior: http://bugs.php.net/fix.php?id=28176r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28176r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28176r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28176r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28176r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28176r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28176r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28176r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28176r=float
#27283 [Ver]: Exception not caught if more than two catch blocks are used
ID: 27283
User updated by: benjcarson at digitaljunkies dot ca
Reported By: benjcarson at digitaljunkies dot ca
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-02-16
New Comment:
For now we've had to use this workaround:
?php
class Ex1 extends Exception { }
class Ex2 extends Exception { }
class Ex3 extends Exception { }
try {
throw new Ex3(Ex3);
} catch (Exception $e) {
if ($e instanceof Ex1)
echo (Ex1: . $e-getMessage() . \n);
else if ($e instanceof Ex2)
echo (Ex2: . $e-getMessage() . \n);
else if ($e instanceof Ex3)
echo (Ex3: . $e-getMessage() . \n);
else
echo (Exception: . $e-getMessage() . \n);
}
Previous Comments:
[2004-03-06 13:10:21] kase at gmx dot net
Still NOT fixed in latest CVS (6 Mar)
I think, it is very important to fix for users working intensively with
exceptions ?!
[2004-02-16 21:09:43] benjcarson at digitaljunkies dot ca
Description:
If an exception is thrown within a try block and more than two catch
blocks follow, the exception may not be caught. If the exception
matches either of the first two catch blocks then the exception will be
caught. However, if the exception does not match the first two catch
blocks, it will skip any remaining catch blocks and remain uncaught.
In the code below, the exception is caught properly if the second catch
block is commented out. Once it is included again though, the
exception is not caught.
Reproduce code:
---
?php
class Ex1 extends Exception { }
class Ex2 extends Exception { }
class Ex3 extends Exception { }
try {
throw new Ex3(Ex3);
} catch (Ex1 $e) {
echo (Ex1: . $e-getMessage() .\n);
} catch (Ex2 $e) {
echo (Ex2: . $e-getMessage() .\n);
} catch (Exception $e) { // Note: trying to catch Ex3 also fails
echo (Exception: . $e-getMessage() . \n);
}
exit(0);
?
Expected result:
Execption: Ex3
Actual result:
--
Fatal error: Uncaught exception 'Ex3' with message 'Ex3'
exception.php:8
Stack trace:
#0 {main}
thrown in exception.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=27283edit=1
#27335 [NEW]: http_build_query segfaults when passing an array with numeric indices
From: benjcarson at digitaljunkies dot ca Operating system: Linux PHP version: 5CVS-2004-02-20 (dev) PHP Bug Type: *URL Functions Bug description: http_build_query segfaults when passing an array with numeric indices Description: http_build_query segfaults if its argument is an array that has numeric indices. gdb backtrace: #0 php_url_encode_hash_ex (ht=0x40690c8c, formstr=0xbfffd2d0, num_prefix=0x0, num_prefix_len=0, key_prefix=0x0, key_prefix_len=0, key_suffix=0x0, key_suffix_len=0, type=0x0) at /usr/src/php5-200402201830/ext/standard/http.c:64 #1 0x081b962c in zif_http_build_query (ht=138264191, return_value=0x406902fc, this_ptr=0x0, return_value_used=1) at /usr/src/php5-200402201830/ext/standard/http.c:204 #2 0x08224ede in zend_do_fcall_common_helper (execute_data=0xbfffd470, opline=0x40690a68, op_array=0x4069075c) at /usr/src/php5-200402201830/Zend/zend_execute.c:2642 #3 0x0822505e in zend_do_fcall_handler (execute_data=0xbfffd470, opline=0x40690a68, op_array=0x83dbe7f) at /usr/src/php5-200402201830/Zend/zend_execute.c:2771 #4 0x08221388 in execute (op_array=0x4069075c) at /usr/src/php5-200402201830/Zend/zend_execute.c:1339 #5 0x082032ff in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php5-200402201830/Zend/zend.c:1053 #6 0x081ca76f in php_execute_script (primary_file=0xb860) at /usr/src/php5-200402201830/main/main.c:1647 #7 0x08235a2e in main (argc=2, argv=0xb924) at /usr/src/php5-200402201830/sapi/cli/php_cli.c:941 Reproduce code: --- ?php $arr[0] = a; $q = http_build_query($arr); echo $q; ? Expected result: 0=a Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=27335edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27335r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27335r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27335r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27335r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27335r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27335r=needscript Try newer version: http://bugs.php.net/fix.php?id=27335r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27335r=support Expected behavior: http://bugs.php.net/fix.php?id=27335r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27335r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27335r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27335r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27335r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27335r=dst IIS Stability: http://bugs.php.net/fix.php?id=27335r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27335r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27335r=float
#27335 [Opn]: http_build_query segfaults when passing an array with numeric indices
ID: 27335 User updated by: benjcarson at digitaljunkies dot ca Reported By: benjcarson at digitaljunkies dot ca Status: Open Bug Type: *URL Functions Operating System: Linux PHP Version: 5CVS-2004-02-20 (dev) New Comment: I should also add that http_build_query will segfault if a numeric index is used in a sub-array of its argument as well: $arr = array(foo=bar, baz=array(one, two, three)); $q = http_build_query($arr); will also segfault. Previous Comments: [2004-02-20 15:18:06] benjcarson at digitaljunkies dot ca Description: http_build_query segfaults if its argument is an array that has numeric indices. gdb backtrace: #0 php_url_encode_hash_ex (ht=0x40690c8c, formstr=0xbfffd2d0, num_prefix=0x0, num_prefix_len=0, key_prefix=0x0, key_prefix_len=0, key_suffix=0x0, key_suffix_len=0, type=0x0) at /usr/src/php5-200402201830/ext/standard/http.c:64 #1 0x081b962c in zif_http_build_query (ht=138264191, return_value=0x406902fc, this_ptr=0x0, return_value_used=1) at /usr/src/php5-200402201830/ext/standard/http.c:204 #2 0x08224ede in zend_do_fcall_common_helper (execute_data=0xbfffd470, opline=0x40690a68, op_array=0x4069075c) at /usr/src/php5-200402201830/Zend/zend_execute.c:2642 #3 0x0822505e in zend_do_fcall_handler (execute_data=0xbfffd470, opline=0x40690a68, op_array=0x83dbe7f) at /usr/src/php5-200402201830/Zend/zend_execute.c:2771 #4 0x08221388 in execute (op_array=0x4069075c) at /usr/src/php5-200402201830/Zend/zend_execute.c:1339 #5 0x082032ff in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php5-200402201830/Zend/zend.c:1053 #6 0x081ca76f in php_execute_script (primary_file=0xb860) at /usr/src/php5-200402201830/main/main.c:1647 #7 0x08235a2e in main (argc=2, argv=0xb924) at /usr/src/php5-200402201830/sapi/cli/php_cli.c:941 Reproduce code: --- ?php $arr[0] = a; $q = http_build_query($arr); echo $q; ? Expected result: 0=a Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=27335edit=1
#27300 [NEW]: pg_convert: interval type regex does not compile
From: benjcarson at digitaljunkies dot ca
Operating system: Linux
PHP version: 5CVS-2004-02-17 (dev)
PHP Bug Type: PostgreSQL related
Bug description: pg_convert: interval type regex does not compile
Description:
When trying to call pg_convert for a table with an interval column, php
throws a warning indicating that it can not compile the regex used to
match interval values.
The regex is on line 3999 of ext/pgsql/pgsql.c I think the regex is
missing a ')' as the second last character.
However, this regex also contains other semantic errors and rejects valid
values as well as accepts some bogus ones. I have written a replacement
regex and created a patch, available at
http://www.digitaljunkies.ca/~benj/pgsql.c.diff.txt.
Reproduce code:
---
?php
error_reporting(E_ALL);
$con = pg_connect(dbname=database);
$arr = array(interval_col = 1 day);
// Presumably tmp_table contains a column 'interval_col' with type
'interval'
$sql = pg_convert($con, tmp_table, $arr);
print_r($sql);
echo \n;
exit(0);
?
Expected result:
Array
(
[interval_col] = '1 day'
)
Actual result:
--
Notice: pg_convert(): '1 day' does not match with '^[+-]{0,1}[
\t]+((second|seconds|minute|minute|hour|hour|day|days|week|weeks|month|monthes|year|years|decade|decades|century|centuries|millennium|millenniums){1,1}[
\t]+)+([ \t]+ago){0,1}$' in pg_convert.php on line 8
Warning: pg_convert(): Cannot compile regex in pg_convert.php on line 8
Notice: pg_convert(): Expects NULL or string for PostgreSQL interval field
(interval_col) in pg_convert.php on line 8
--
Edit bug report at http://bugs.php.net/?id=27300edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27300r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27300r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27300r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27300r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27300r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27300r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27300r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27300r=support
Expected behavior: http://bugs.php.net/fix.php?id=27300r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27300r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27300r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27300r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27300r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27300r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27300r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27300r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27300r=float
#27283 [NEW]: Exception not caught if more than two catch blocks are used
From: benjcarson at digitaljunkies dot ca
Operating system: Linux
PHP version: 5CVS-2004-02-16 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: Exception not caught if more than two catch blocks are used
Description:
If an exception is thrown within a try block and more than two catch
blocks follow, the exception may not be caught. If the exception matches
either of the first two catch blocks then the exception will be caught.
However, if the exception does not match the first two catch blocks, it
will skip any remaining catch blocks and remain uncaught.
In the code below, the exception is caught properly if the second catch
block is commented out. Once it is included again though, the exception
is not caught.
Reproduce code:
---
?php
class Ex1 extends Exception { }
class Ex2 extends Exception { }
class Ex3 extends Exception { }
try {
throw new Ex3(Ex3);
} catch (Ex1 $e) {
echo (Ex1: . $e-getMessage() .\n);
} catch (Ex2 $e) {
echo (Ex2: . $e-getMessage() .\n);
} catch (Exception $e) { // Note: trying to catch Ex3 also fails
echo (Exception: . $e-getMessage() . \n);
}
exit(0);
?
Expected result:
Execption: Ex3
Actual result:
--
Fatal error: Uncaught exception 'Ex3' with message 'Ex3' exception.php:8
Stack trace:
#0 {main}
thrown in exception.php on line 8
--
Edit bug report at http://bugs.php.net/?id=27283edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27283r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27283r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27283r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27283r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27283r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27283r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27283r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27283r=support
Expected behavior: http://bugs.php.net/fix.php?id=27283r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27283r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27283r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27283r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27283r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27283r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27283r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27283r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27283r=float
#26864 [NEW]: pg_update pg_delete ignore PGSQL_DML_EXEC option
From: benjcarson at digitaljunkies dot ca
Operating system: Linux
PHP version: 5CVS-2004-01-10 (dev)
PHP Bug Type: PostgreSQL related
Bug description: pg_update pg_delete ignore PGSQL_DML_EXEC option
Description:
Both pg_update() and pg_delete() ignore the PGSQL_DML_EXEC option and
attempt to excute the query regardless of whether it is set or not. This
is in contrast to pg_insert() which does not execute the query if
PGSQL_DML_EXEC is not set. This also has the side effect of not being
able to use pg_update() and pg_delete() with the PGSQL_DML_STRING option
to create sql strings for queries that would fail if executed.
This can be fixed fairly easily by changing a few lines in the
php_pgsql_update() and php_pgsql_delete() functions in pgsql.c to match
the behaviour of pg_insert(). On line 4427 of pgsql.c (in the latest CVS
checkout, 2004-01-10), in the function php_pgsql_update(), the if
statment:
if (do_exec(querystr, PGRES_COMMAND_OK, pg_link, opt TSRMLS_CC) == 0)
ret = SUCCESS;
Should probably be:
if ((opt (PGSQL_DML_EXEC|PGSQL_DML_ASYNC))
do_exec(querystr, PGRES_COMMAND_OK, pg_link, opt TSRMLS_CC) == 0) {
ret = SUCCESS;
}
else if (opt PGSQL_DML_STRING) {
ret = SUCCESS;
}
The same new if statment can be used to replace the if statment on line
4520 in the php_pgsql_delete() function.
Reproduce code:
---
?php
error_reporting(E_ALL);
$con = pg_connect(host=localhost dbname=db user=php password=password);
if (!$con)
die(Unable to connect.\n);
$assoc = array(first_name=name);
$where = array(contact_id=8);
$sql = pg_update($con,employee, $assoc, $where, PGSQL_DML_STRING);
if (!$sql)
echo pg_update() failed.\n;
echo $sql;
?
Expected result:
UPDATE employee SET first_name='name' WHERE contact_id=8;
Actual result:
--
Notice: pg_update(): Failed to execute 'UPDATE employee SET
first_name='name' WHERE contact_id=8;' in pg_update.php on line 11
pg_update() failed.
--
Edit bug report at http://bugs.php.net/?id=26864edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26864r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26864r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26864r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26864r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26864r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26864r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26864r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26864r=support
Expected behavior: http://bugs.php.net/fix.php?id=26864r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26864r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26864r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26864r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26864r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26864r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26864r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26864r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26864r=float
#26624 [Com]: cannot get the right value when i use + operator
ID: 26624 Comment by: benjcarson at digitaljunkies dot ca Reported By: mlsx at cie dot xtu dot edu dot cn Status: Open Bug Type: Math related Operating System: windows server 2003 PHP Version: 4.3.3 New Comment: I believe you need to put the math expression in parentheses because '.' and '+' have the same precedence. What is happening is that you end up adding the value 2 to the string a+b=2. If I do: echo a+b=.($a+$b).br; it comes out correctly. Previous Comments: [2003-12-15 02:45:01] mlsx at cie dot xtu dot edu dot cn Description: first i define a is 8 and b is 6. When i use echo a+b=.$a+$b.br; the MS IE show the result is 2. While i use echo a+b=; echo $a+$b.br; the result is correct! the same result when use - operator use a line command. but the result is correct when i use * and / i cannnot fix it! Reproduce code: --- ?php $a = 8; $b = 2; $c = 3; echo a+b=.$a+$b.br; echo a-b=.$a-$b.br; echo a*b=.$a*$b.br; echo a/b=.$a/$b.br; echo a%c=.$a%$c.br; echo a++ is .$a++; ? Expected result: 2 -2 a*b=16 a/b=4 a%c=2 a++ is 8 Actual result: -- a+b=10 a-b=6 a*b=16 a/b=4 a%c=2 a++ is 8 -- Edit this bug report at http://bugs.php.net/?id=26624edit=1
