php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60620 ReflectionFunction Internal Error provocation
Submitted: 2011-12-29 01:37 UTC Modified: 2017-09-13 21:44 UTC
Votes:1
Avg. Score:1.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: hanskrentel at yahoo dot de Assigned: cmb (profile)
Status: Closed Package: Reflection related
PHP Version: 5.3.8 OS: win
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: hanskrentel at yahoo dot de
New email:
PHP Version: OS:

 

 [2011-12-29 01:37 UTC] hanskrentel at yahoo dot de
Description:
------------
Normally Instantiation fails (ReflectionException):

$test = new ReflectionFunction('');

However this can be fooled:

$obj = new stdClass();
$test = new ReflectionFunction($obj);
echo $test;

The echo line triggers a fatal error then:

Fatal error: ReflectionFunction::__toString(): Internal error: Failed to 
retrieve the reflection object

Before that happens there is a slightly misworded warning ahead:

Warning: ReflectionFunction::__construct() expects parameter 1 to be string, 
object given

Misworded in the sense that it's possible objects with __toString() and 
closures.

Probably something in the logic inside the constructor is not right. It would be 
good if in such cases an ReflectionException is thrown on instantiation.

Test script:
---------------
$obj = new stdClass();
$test = new ReflectionFunction($obj);
echo $test;

Expected result:
----------------
ReflectionException

Actual result:
--------------
Fatal Error

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-09-13 17:22 UTC] cmb@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2017-09-13 17:22 UTC] cmb@php.net
As of PHP 7.0.0 a TypeError is thrown, if the parameter is not a
string, see <https://3v4l.org/DuLJt>.
 [2017-09-13 17:59 UTC] spam2 at rhsoft dot net
that below is part of my fuzzy-call-suite for string params with work with 7.0/7.1/7.2 perfectly - you can catch fatal errors starzing with PHP 7.0

try
{
 $params[] = $reflection_param->getDefaultValue();
}
catch(Throwable $exception)
{
 $params[] = bin2hex(random_bytes(5));
}
 [2017-09-13 20:44 UTC] cmb@php.net
> you can catch fatal errors starzing with PHP 7.0

No, that is not possible. A TypeError isn't a fatal error, though.
 [2017-09-13 20:54 UTC] spam2 at rhsoft dot net
> No, that is not possible. A TypeError isn't a fatal error, though

no idea what you are talking about - you can catch it - PERIOD
the only crap you still can't catch is https://bugs.php.net/bug.php?id=73451

[harry@srv-rhsoft:/downloads]$ php test.php
CATCHED: TypeError: Argument 1 passed to test() must be of the type string, integer given, called in /mnt/data/downloads/test.php on line 4 and defined in /mnt/data/downloads/test.php:11 Stack trace: #0 /mnt/data/downloads/test.php(4): test(1) #1 {main}

[harry@srv-rhsoft:/downloads]$ cat test.php
<?php declare(strict_types=1);
try
{
 test(1);
}
catch(Throwable $exception)
{
 $exception = str_replace("\n", ' ', (string)$exception);
 echo "CATCHED: $exception\n";
}
function test(string $x)
{

}
 [2017-09-13 20:56 UTC] spam2 at rhsoft dot net
and with PHP7 and catch(Throwable) you can even catch parse errors of includes, calls to functions which don't exist and so on - so please don't edcuate me instead fix the remainin crap which is still not catchabale like WSDL/SOAP
 [2017-09-13 21:44 UTC] cmb@php.net
> no idea what you are talking about - you can catch it - PERIOD

I'm talking about the distinction between Throwables and fatal
(i.e. unrecoverable) errors. The latter can't be caught, and never
will, because they left the engine in a broken state (for
instance, memory errors). There are most likely still cases where
an extension raises a fatal error instead of throwing a Throwable,
even though that could be changed. This has to be addressed on a
case-by-case basis unless somebody takes the time to manually
inspect the complete PHP sources.

> […] instead fix the remainin crap […]

I suggest to read <https://bugs.php.net/how-to-report.php>. :)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 12:01:27 2024 UTC