[PHP-BUG] Bug #65665 [NEW]: Exception not properly caught when opcache enabled
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.5.3
Package: opcache
Bug Type: Bug
Bug description:Exception not properly caught when opcache enabled
Description:
When running the following script with opcache enabled, the exception is
not caught by the correct catch block. The exception should be caught by
the 'caught by 1' block, but it is instead caught by the 'caught by 2'
block. Disabling opcache causes the exception to be caught in the correct
block.
Run the script with:
php -n -d zend_extension=opcache.so -d opcache.enable_cli=1 script.php
Test script:
---
?php
try
{
switch (1)
{
case 0:
try
{
}
catch (Exception $e)
{
}
break;
case 1:
try
{
throw new Exception('aaa');
}
catch (Exception $e)
{
echo 'caught by 1';
exit;
}
break;
}
}
catch (Exception $e)
{
echo 'caught by 2';
exit;
}
Expected result:
caught by 1
Actual result:
--
caught by 2
--
Edit bug report at https://bugs.php.net/bug.php?id=65665edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65665r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65665r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65665r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65665r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65665r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65665r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65665r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65665r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65665r=support
Expected behavior: https://bugs.php.net/fix.php?id=65665r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65665r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65665r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65665r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65665r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65665r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65665r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65665r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65665r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65665r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65665r=mysqlcfg
Bug #65255 [Com]: exception not catchable when thrown from autoload in an extended class
Edit report at https://bugs.php.net/bug.php?id=65255edit=1
ID: 65255
Comment by: ryan dot brothers at gmail dot com
Reported by:ryan dot brothers at gmail dot com
Summary:exception not catchable when thrown from autoload in
an extended class
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Thank you for your help. Why does it matter if the class was declared
literally in the try/catch block? The documentation states exceptions thrown
in the __autoload function can be caught in the catch block. It works for the
base class, but not extended classes.
Other exceptions thrown outside of a try/catch always propagate back to the
caller's try/catch such as the below. In these examples, the exception is
caught, but the exception is thrown outside of the literal try/catch.
?php
function __autoload($class)
{
throw new Exception('abcd');
}
try
{
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
?php
function test()
{
throw new Exception('abcd');
}
try
{
test();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
?php
class test1
{
public static function go()
{
throw new Exception('abcd');
}
}
try
{
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
Previous Comments:
[2013-07-14 03:17:40] larue...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
try the following example, you may found why this is expected:
?php
function __autoload($class)
{
throw new Exception('abcd');
}
try
{
class test1 extends test2
{
public static function go()
{
}
}
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
[2013-07-12 19:43:37] ryan dot brothers at gmail dot com
Description:
This issue may be the same issue as bug 65254 that I just submitted. The
following script throws a Fatal Error rather than catching the exception.
Test script:
---
?php
function __autoload($class)
{
throw new Exception('abcd');
}
class test1 extends test2
{
public static function go()
{
}
}
try
{
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
Expected result:
caught
Actual result:
--
Fatal error: Uncaught exception 'Exception' with message 'abcd' in
/tmp/test.php:4
Stack trace:
#0 /tmp/test.php(8): __autoload('test2')
#1 {main}
thrown in /tmp/test.php on line 4
--
Edit this bug report at https://bugs.php.net/bug.php?id=65255edit=1
Bug #65255 [Com]: exception not catchable when thrown from autoload in an extended class
Edit report at https://bugs.php.net/bug.php?id=65255edit=1
ID: 65255
Comment by: ryan dot brothers at gmail dot com
Reported by:ryan dot brothers at gmail dot com
Summary:exception not catchable when thrown from autoload in
an extended class
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Nevermind, I see the issue now and why it's expected behavior. The autoload
gets called when the class is declared rather than when the class is first
called. I'll see if your fix in bug 65254 resolves the issue I was having.
Thanks again for your help.
Previous Comments:
[2013-07-14 13:22:01] ryan dot brothers at gmail dot com
Thank you for your help. Why does it matter if the class was declared
literally in the try/catch block? The documentation states exceptions thrown
in the __autoload function can be caught in the catch block. It works for the
base class, but not extended classes.
Other exceptions thrown outside of a try/catch always propagate back to the
caller's try/catch such as the below. In these examples, the exception is
caught, but the exception is thrown outside of the literal try/catch.
?php
function __autoload($class)
{
throw new Exception('abcd');
}
try
{
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
?php
function test()
{
throw new Exception('abcd');
}
try
{
test();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
?php
class test1
{
public static function go()
{
throw new Exception('abcd');
}
}
try
{
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
[2013-07-14 03:17:40] larue...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
try the following example, you may found why this is expected:
?php
function __autoload($class)
{
throw new Exception('abcd');
}
try
{
class test1 extends test2
{
public static function go()
{
}
}
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
[2013-07-12 19:43:37] ryan dot brothers at gmail dot com
Description:
This issue may be the same issue as bug 65254 that I just submitted. The
following script throws a Fatal Error rather than catching the exception.
Test script:
---
?php
function __autoload($class)
{
throw new Exception('abcd');
}
class test1 extends test2
{
public static function go()
{
}
}
try
{
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
Expected result:
caught
Actual result:
--
Fatal error: Uncaught exception 'Exception' with message 'abcd' in
/tmp/test.php:4
Stack trace:
#0 /tmp/test.php(8): __autoload('test2')
#1 {main}
thrown in /tmp/test.php on line 4
--
Edit this bug report at https://bugs.php.net/bug.php?id=65255edit=1
[PHP-BUG] Bug #65254 [NEW]: Exception not catchable when exception thrown in autoload with a namespace
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.5.0
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Exception not catchable when exception thrown in autoload with
a namespace
Description:
In the following code, the exception is not caught. In PHP 5.3, the
exception is caught, but in PHP 5.4 and PHP 5.5, the exception is not
caught. The issue only occurs when the class is in a namespace. If I
remove the namespace from the class, then the exception is caught.
Test script:
---
?php
function __autoload($class)
{
require('ns_test.php');
throw new \Exception('abcd');
}
try
{
\ns_test\test::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
ns_test.php:
?php
namespace ns_test;
class test
{
}
Expected result:
caught
Actual result:
--
Warning: Uncaught exception 'Exception' with message 'abcd' in
/tmp/test.php:6
Stack trace:
#0 /tmp/test.php(11): __autoload('ns_test\test')
#1 {main}
thrown in /tmp/test.php on line 6
Fatal error: Call to undefined method ns_test\test::go() in /tmp/test.php
on line 11
--
Edit bug report at https://bugs.php.net/bug.php?id=65254edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65254r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65254r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65254r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65254r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65254r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65254r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65254r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65254r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65254r=support
Expected behavior: https://bugs.php.net/fix.php?id=65254r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65254r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65254r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65254r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65254r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65254r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65254r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65254r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65254r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65254r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65254r=mysqlcfg
Bug #65254 [Com]: Exception not catchable when exception thrown in autoload with a namespace
Edit report at https://bugs.php.net/bug.php?id=65254edit=1
ID: 65254
Comment by: ryan dot brothers at gmail dot com
Reported by:ryan dot brothers at gmail dot com
Summary:Exception not catchable when exception thrown in
autoload with a namespace
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Upon further testing, I can reproduce the issue without using namespaces with
the following:
?php
function __autoload($class)
{
require('ns_test.php');
throw new \Exception('abcd');
}
try
{
test::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
ns_test.php:
?php
class test
{
}
Previous Comments:
[2013-07-12 18:41:12] ryan dot brothers at gmail dot com
Description:
In the following code, the exception is not caught. In PHP 5.3, the exception
is caught, but in PHP 5.4 and PHP 5.5, the exception is not caught. The issue
only occurs when the class is in a namespace. If I remove the namespace from
the class, then the exception is caught.
Test script:
---
?php
function __autoload($class)
{
require('ns_test.php');
throw new \Exception('abcd');
}
try
{
\ns_test\test::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
ns_test.php:
?php
namespace ns_test;
class test
{
}
Expected result:
caught
Actual result:
--
Warning: Uncaught exception 'Exception' with message 'abcd' in /tmp/test.php:6
Stack trace:
#0 /tmp/test.php(11): __autoload('ns_test\test')
#1 {main}
thrown in /tmp/test.php on line 6
Fatal error: Call to undefined method ns_test\test::go() in /tmp/test.php on
line 11
--
Edit this bug report at https://bugs.php.net/bug.php?id=65254edit=1
[PHP-BUG] Bug #65255 [NEW]: exception not catchable when thrown from autoload in an extended class
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.5.0
Package: Scripting Engine problem
Bug Type: Bug
Bug description:exception not catchable when thrown from autoload in an
extended class
Description:
This issue may be the same issue as bug 65254 that I just submitted. The
following script throws a Fatal Error rather than catching the exception.
Test script:
---
?php
function __autoload($class)
{
throw new Exception('abcd');
}
class test1 extends test2
{
public static function go()
{
}
}
try
{
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
Expected result:
caught
Actual result:
--
Fatal error: Uncaught exception 'Exception' with message 'abcd' in
/tmp/test.php:4
Stack trace:
#0 /tmp/test.php(8): __autoload('test2')
#1 {main}
thrown in /tmp/test.php on line 4
--
Edit bug report at https://bugs.php.net/bug.php?id=65255edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65255r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65255r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65255r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65255r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65255r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65255r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65255r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65255r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65255r=support
Expected behavior: https://bugs.php.net/fix.php?id=65255r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65255r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65255r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65255r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65255r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65255r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65255r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65255r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65255r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65255r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65255r=mysqlcfg
Bug #65111 [Nab]: Calling traits directly with static properties/methods
Edit report at https://bugs.php.net/bug.php?id=65111edit=1
ID: 65111
User updated by:ryan dot brothers at gmail dot com
Reported by:ryan dot brothers at gmail dot com
Summary:Calling traits directly with static
properties/methods
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Thank you for the feedback. I see that the same functionality exists with
abstract classes. If an abstract class has a static property or method, you
can call it directly. In my particular case, I would like to enforce that all
calls go to the classes that use the traits, and to prevent accidental calls to
the traits directly. I will work around it in a different manner. Thanks.
Previous Comments:
[2013-06-25 15:15:00] fel...@php.net
Thanks for explaining it.
[2013-06-25 07:19:04] g...@php.net
Yes, traits are not supposed to be instantiated. However, this behavior is not
really related to instantiation.
Traits are still a lexical entity, i.e., a programming language entity that
provides a lexical scope when defined. Since PHP allows us to define functions
in
such scopes, we can define also static methods on traits.
The way to avoid that would be to change the grammar for traits.
I decided to not do that back in the day. And I still feel that it is unclear
whether it would be conceptually cleaner if it is not possible to defined
static
state/methods.
So, I would leave it as it is. Except, someone comes up with a good reason to
change it. But it would also be quite a bit of a BC issue.
[2013-06-25 04:30:41] larue...@php.net
hmm, trait is actually a class in php, I have a quick look into this..
changing
this will needs a significant works..
actually, the is_callable / do_call alreay is a little mess now. I mean the
codes
[2013-06-24 16:52:52] ryan dot brothers at gmail dot com
Description:
The documentation for traits indicates that it is not possible to instantiate
a Trait on its own, but I have noticed that a trait can be called directly if
it has a static property or method, as per the below example. Is this intended
behavior? Or should traits be restricted from being called directly? I was
under the impression that traits cannot be called directly per the
documentation. If not, is there a way to prevent traits from being called
directly as in the below example?
Test script:
---
?php
trait t1
{
public static $a1 = 'test1';
public static function test()
{
return 'test2';
}
}
echo t1::$a1.\n;
echo t1::test().\n;
Expected result:
Fatal Error that traits cannot be called directly.
Actual result:
--
test1
test2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65111edit=1
[PHP-BUG] Bug #65111 [NEW]: Calling traits directly with static properties/methods
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.5.0
Package: Class/Object related
Bug Type: Bug
Bug description:Calling traits directly with static properties/methods
Description:
The documentation for traits indicates that it is not possible to
instantiate a Trait on its own, but I have noticed that a trait can be
called directly if it has a static property or method, as per the below
example. Is this intended behavior? Or should traits be restricted from
being called directly? I was under the impression that traits cannot be
called directly per the documentation. If not, is there a way to prevent
traits from being called directly as in the below example?
Test script:
---
?php
trait t1
{
public static $a1 = 'test1';
public static function test()
{
return 'test2';
}
}
echo t1::$a1.\n;
echo t1::test().\n;
Expected result:
Fatal Error that traits cannot be called directly.
Actual result:
--
test1
test2
--
Edit bug report at https://bugs.php.net/bug.php?id=65111edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65111r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65111r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65111r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65111r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65111r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65111r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65111r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65111r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65111r=support
Expected behavior: https://bugs.php.net/fix.php?id=65111r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65111r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65111r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65111r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65111r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65111r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65111r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65111r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65111r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65111r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65111r=mysqlcfg
[PHP-BUG] Bug #65035 [NEW]: yield / exit segfault
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.5Git-2013-06-13 (snap)
Package: Reproducible crash
Bug Type: Bug
Bug description:yield / exit segfault
Description:
The following script causes a segfault. It is occurring when exit is
called in a function that is called from a generator function.
Test script:
---
?php
function f1()
{
f2();
$i = 0;
yield $i;
}
function f2()
{
exit;
}
$rows = f1();
foreach ($rows as $row)
{
}
Expected result:
Script exits with no output.
Actual result:
--
[Thu Jun 13 18:44:50 2013] Script: '/tmp/test.php'
---
/usr/local/src/php5.5-201306132030/Zend/zend_execute.h(196) : Block
0x7f7b17658d28 status:
Beginning: Freed
Start: OK
End: Overflown (magic=0x005A instead of 0xEAF0B464)
At least 4 bytes overflown
---
--
Edit bug report at https://bugs.php.net/bug.php?id=65035edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65035r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65035r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65035r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65035r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65035r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65035r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65035r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65035r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65035r=support
Expected behavior: https://bugs.php.net/fix.php?id=65035r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65035r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65035r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65035r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65035r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65035r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65035r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65035r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65035r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65035r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65035r=mysqlcfg
[PHP-BUG] Bug #61587 [NEW]: XMLReader - invalid schema error using ampersands
From:
Operating system: Linux
PHP version: 5.3.10
Package: XML Reader
Bug Type: Bug
Bug description:XMLReader - invalid schema error using ampersands
Description:
In the following test script, the example xml is valid against the supplied
schema. DOMDocument displays no schema errors as expected, but XMLReader
displays a schema violation. I was expecting XMLReader to not report any
schema violations.
Test script:
---
?php
error_reporting(E_ALL);
$xml = 'user name=a amp; b/';
$schema = '?xml version=1.0 encoding=UTF-8?
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element name=user
xs:complexType
xs:attribute name=name use=required
xs:simpleType
xs:restriction base=xs:string
xs:enumeration value=a amp;
b/
/xs:restriction
/xs:simpleType
/xs:attribute
/xs:complexType
/xs:element
/xs:schema';
// create temp file with schema
$schema_file = tempnam(sys_get_temp_dir(), '');
file_put_contents($schema_file, $schema);
// test with DOMDocument
$dom = new DOMDocument;
$dom-loadXML($xml);
$dom-schemaValidate($schema_file);
// test with XMLReader
$xmlreader = new XMLReader;
$xmlreader-xml($xml);
$xmlreader-setSchema($schema_file);
while ($xmlreader-read() == true);
$xmlreader-close();
// delete temp file
unlink($schema_file);
Expected result:
No output
Actual result:
--
Warning: XMLReader::read(): Element 'user', attribute 'name': [facet
'enumeration'] The value 'a #38; b' is not an element of the set {'a
b'}. in test.php on line 38
Warning: XMLReader::read(): Element 'user', attribute 'name': 'a #38; b'
is not a valid value of the local atomic type. in test.php on line 38
--
Edit bug report at https://bugs.php.net/bug.php?id=61587edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61587r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61587r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61587r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61587r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61587r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61587r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61587r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61587r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61587r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61587r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61587r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61587r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61587r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61587r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61587r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61587r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61587r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61587r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61587r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61587r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61587r=mysqlcfg
#48420 [Bgs]: stream_get_line() - invalid result when passing $length and $ending
ID: 48420
User updated by: ryan dot brothers at gmail dot com
Reported By: ryan dot brothers at gmail dot com
Status: Bogus
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.*, 6CVS(2009-05-29)
New Comment:
Thanks for your reply. Shouldn't stream_get_line() find the EOF since
it will read the first 5 characters and then find the EOF when trying to
read the next character since $length = 6? Also, if what you wrote is
the case, I'm not sure why this:
?php
$fp = tmpfile();
fwrite($fp, 12345);
fseek($fp, 0);
var_dump(stream_get_line($fp, 6, \n));
?
returns:
bool(false)
but this works successfully:
?
$fp = tmpfile();
fwrite($fp, 12345\n67890);
fseek($fp, 0);
var_dump(stream_get_line($fp, 6, \n));
var_dump(stream_get_line($fp, 6, \n));
?
returns:
string(5) 12345
string(5) 67890
On the 2nd call to stream_get_line(), there are 5 bytes remaining to be
read, $length = 6, and there are no \n's remaining, which is the same
exact scenario as my first example above. In my first example,
stream_get_line() returns false, but in the 2nd example,
stream_get_line() returns the expected string - should both of these
calls have the same results?
I encountered this issue when trying to use stream_get_line() to parse
very large text files reading in each file in sections delimited by a
string delimiter, but one of my text files did not contain this
delimiter and stream_get_line() returned false for that file which I
don't believe was correct. I was expecting it to read in the entire
file since $length was greater than the size of the file, which is what
the documentation says should occur.
Thanks again for your assistance.
Previous Comments:
[2009-06-01 13:03:18] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Because the file is still open there is no EOF, so the
stream_get_line()
cannot find the line's end and there is no EOF, thus it returns false.
[2009-05-29 13:09:26] ryan dot brothers at gmail dot com
Thanks for your feedback. I tried it on the latest PHP 5.3 snapshot
and got the same results.
I noticed though when I run this:
?php
fseek($fp, 0);
var_dump(fgets($fp, 6));
fseek($fp, 0);
var_dump(fgets($fp, 7));
?
I get the expected results of:
string(5) 12345
string(5) 12345
Since the manual page for stream_get_line() states that this function
is identical to fgets() except for handling of the delimiter, should
stream_get_line() return the same results as fgets() for this case since
my delimiter is a newline?
Also, I'm not sure why these 2 calls to stream_get_line() return
different output:
?php
fseek($fp, 0);
var_dump(stream_get_line($fp, 6));
fseek($fp, 0);
var_dump(stream_get_line($fp, 6, \n));
?
Result:
string(5) 12345
bool(false)
[2009-05-29 09:00:45] lbarn...@php.net
Verified. Actually this may be expected.
?php
fseek($fp, 0);
var_dump(stream_get_line($fp, 6, \n));
?
If stream_get_line() reads only 5 bytes here there is no way to tell if
this is the end of the stream (without re-reading from the stream, which
would block on sockets, etc). So it can't find the end of the line and
return false.
The next call to stream_get_line() will mark the stream as EOF, and
stream_get_line will return the line:
?php
$fp = tmpfile();
fwrite($fp, '12345');
fseek($fp, 0);
while (!feof($fp)) {
$line = stream_get_line($fp);
if ($line === false) continue;
var_dump($line);
}
?
Result:
string(5) 12345
[2009-05-29 08:39:03] lbarn...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-05-28 22:21:09] ryan dot brothers at gmail dot com
Description:
When you pass to stream_get_line() a $length that is greater than the
file size and a $ending that does not appear in the file,
stream_get_line() returns bool(false) rather than the string that is in
your file.
In the below example, when I run stream_get_line() passing in a $length
of 6 and a $ending of \n, stream_get_line() returns false rather than
the contents of the file.
The manual states Reading ends when length bytes have been read, when
the string specified by ending is found (which is not included in the
return value), or on EOF (whichever comes first)., so I believe the
contents of my file should be returned since EOF is first to be reached.
Reproduce code:
---
?php
$fp = tmpfile();
fwrite
#48420 [Fbk-Opn]: stream_get_line() - invalid result when passing $length and $ending
ID: 48420
User updated by: ryan dot brothers at gmail dot com
Reported By: ryan dot brothers at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.*, 6CVS(2009-05-29)
New Comment:
Thanks for your feedback. I tried it on the latest PHP 5.3 snapshot
and got the same results.
I noticed though when I run this:
?php
fseek($fp, 0);
var_dump(fgets($fp, 6));
fseek($fp, 0);
var_dump(fgets($fp, 7));
?
I get the expected results of:
string(5) 12345
string(5) 12345
Since the manual page for stream_get_line() states that this function
is identical to fgets() except for handling of the delimiter, should
stream_get_line() return the same results as fgets() for this case since
my delimiter is a newline?
Also, I'm not sure why these 2 calls to stream_get_line() return
different output:
?php
fseek($fp, 0);
var_dump(stream_get_line($fp, 6));
fseek($fp, 0);
var_dump(stream_get_line($fp, 6, \n));
?
Result:
string(5) 12345
bool(false)
Previous Comments:
[2009-05-29 09:00:45] lbarn...@php.net
Verified. Actually this may be expected.
?php
fseek($fp, 0);
var_dump(stream_get_line($fp, 6, \n));
?
If stream_get_line() reads only 5 bytes here there is no way to tell if
this is the end of the stream (without re-reading from the stream, which
would block on sockets, etc). So it can't find the end of the line and
return false.
The next call to stream_get_line() will mark the stream as EOF, and
stream_get_line will return the line:
?php
$fp = tmpfile();
fwrite($fp, '12345');
fseek($fp, 0);
while (!feof($fp)) {
$line = stream_get_line($fp);
if ($line === false) continue;
var_dump($line);
}
?
Result:
string(5) 12345
[2009-05-29 08:39:03] lbarn...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-05-28 22:21:09] ryan dot brothers at gmail dot com
Description:
When you pass to stream_get_line() a $length that is greater than the
file size and a $ending that does not appear in the file,
stream_get_line() returns bool(false) rather than the string that is in
your file.
In the below example, when I run stream_get_line() passing in a $length
of 6 and a $ending of \n, stream_get_line() returns false rather than
the contents of the file.
The manual states Reading ends when length bytes have been read, when
the string specified by ending is found (which is not included in the
return value), or on EOF (whichever comes first)., so I believe the
contents of my file should be returned since EOF is first to be reached.
Reproduce code:
---
?php
$fp = tmpfile();
fwrite($fp, '12345');
fseek($fp, 0);
var_dump(stream_get_line($fp, 5));
fseek($fp, 0);
var_dump(stream_get_line($fp, 6));
fseek($fp, 0);
var_dump(stream_get_line($fp, 5, \n));
fseek($fp, 0);
var_dump(stream_get_line($fp, 6, \n));
fclose($fp);
Expected result:
string(5) 12345
string(5) 12345
string(5) 12345
string(5) 12345
Actual result:
--
string(5) 12345
string(5) 12345
string(5) 12345
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=48420edit=1
#48420 [NEW]: stream_get_line() - invalid result when passing $length and $ending
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Streams related Bug description: stream_get_line() - invalid result when passing $length and $ending Description: When you pass to stream_get_line() a $length that is greater than the file size and a $ending that does not appear in the file, stream_get_line() returns bool(false) rather than the string that is in your file. In the below example, when I run stream_get_line() passing in a $length of 6 and a $ending of \n, stream_get_line() returns false rather than the contents of the file. The manual states Reading ends when length bytes have been read, when the string specified by ending is found (which is not included in the return value), or on EOF (whichever comes first)., so I believe the contents of my file should be returned since EOF is first to be reached. Reproduce code: --- ?php $fp = tmpfile(); fwrite($fp, '12345'); fseek($fp, 0); var_dump(stream_get_line($fp, 5)); fseek($fp, 0); var_dump(stream_get_line($fp, 6)); fseek($fp, 0); var_dump(stream_get_line($fp, 5, \n)); fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); fclose($fp); Expected result: string(5) 12345 string(5) 12345 string(5) 12345 string(5) 12345 Actual result: -- string(5) 12345 string(5) 12345 string(5) 12345 bool(false) -- Edit bug report at http://bugs.php.net/?id=48420edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48420r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48420r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48420r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48420r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48420r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48420r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48420r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48420r=needscript Try newer version: http://bugs.php.net/fix.php?id=48420r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48420r=support Expected behavior: http://bugs.php.net/fix.php?id=48420r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48420r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48420r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48420r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48420r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48420r=dst IIS Stability: http://bugs.php.net/fix.php?id=48420r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48420r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48420r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48420r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48420r=mysqlcfg
#48421 [NEW]: stream_get_line() - allow $length to be optional
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: stream_get_line() - allow $length to be optional
Description:
I believe stream_get_line() should allow the $length parameter to be
optional by allowing a $length of -1 that would read the remaining buffer
up to either the $ending delimiter or EOF.
Currently if you pass a $length of 0, the $length defaults to
PHP_SOCK_CHUNK_SIZE (8192) in ext/standard/streamsfuncs.c. If you pass a
length of -1, a PHP Warning is generated.
Other 'similar' functions that allow length to be optional or -1 are
fgets, stream_get_contents, and file_get_contents.
Also, the manual page for stream_get_line() states that this function is
the same fgets() except for the handling of the delimiter - but another
difference, at least right now, is that the $length parameter is required
in stream_get_line(), but optional in fgets().
Reproduce code:
---
?php
$fp = tmpfile();
fwrite($fp, str_repeat('a', 1));
fseek($fp, 0);
echo strlen(stream_get_line($fp, 0));
fseek($fp, 0);
echo strlen(stream_get_line($fp, -1));
fclose($fp);
Expected result:
8192
1
Actual result:
--
8192
Warning: stream_get_line(): The maximum allowed length must be greater
than or equal to zero
--
Edit bug report at http://bugs.php.net/?id=48421edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48421r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48421r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48421r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48421r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48421r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48421r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48421r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48421r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48421r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48421r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48421r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48421r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48421r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48421r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48421r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48421r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48421r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48421r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48421r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48421r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48421r=mysqlcfg
