Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87524
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
To: PHP Internals <internals@lists.php.net>
References: <550FA2ED.6080000@gmail.com>
 <CADR=R-gtCy7Vi7Y15jx+SYWX3aEB6TN3WGJPAqqQ4tO__SWqQw@mail.gmail.com>
 <CAF+90c8c8_Vth3vVaYF1N1u68JANTbGDq-QUTvG44X+Wr+oe0A@mail.gmail.com>
 <55B7B08E.7070700@gmail.com>
 <CAH-PCH7Yw8KWZa5oLguUjD2-3DrSsH0Kb7cO9yLKYy4UNETWCQ@mail.gmail.com>
 <55BBD2EE.2070008@gmail.com> <B0DD7401-6FCA-41E5-AC24-B5C273CED742@gmail.com>
 <55BC069A.6000402@gmail.com> <C3727D98-80CA-4006-9ED1-FB679465B350@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>
Message-ID: <55BE587A.5050901@gmail.com>
Date: Sun, 2 Aug 2015 18:50:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <C3727D98-80CA-4006-9ED1-FB679465B350@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Serializing exceptions
From: rowan.collins@gmail.com (Rowan Collins)

On 01/08/2015 01:06, Rowan Collins wrote:
> On 1 August 2015 00:36:58 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>
>>> DEBUG_BACKTRACE_IGNORE_ARGS in a debug_backtrace() call. IIRC the
>>> object of called methods is already excluded (equivalent to masking
>>> out DEBUG_PROVIDE_OBJECT) so what's left is all strings.
>> I'm not sure how you arrived at the conclusion that all arguments in
>> backtrace are strings. Arguments can be of any type. When printed, they
>> are converted to strings, but they are not strings when stored.
> I'll have to recheck when I have more time, and something better than a phone to type on, but from memory, the backtrace which can be retrieved from an exception includes the same  information as debug_backtrace(false), that is:
> - function: string
> - line: integer
> - file: string
> - class: string
> - type: string
> - args: array
>
> Of these 6 items, it is only 'args' that can contain an object of any kind, so without this item, the data would be  serializable. This would be equivalent to debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS).
>
> If any of these items (other than args) are stored in memory in a different form (which doesn't seem likely to me), that form is completely inaccessible to the user, so converting to string during serialization would effectively be lossless. (Or, pre-converting would have zero BC break.) Similarly, if additional details are stored, those details are inaccessible, so removing them has no impact on any existing (userland) code.

I just double-checked this. You can see that there is not even an 
internal reference to objects which were $this in the stack trace, 
because the object can be garbage collected separately from the 
exception. http://3v4l.org/hOYb9

So, as I said, no object will be implicitly attached to the exception 
anywhere other than the 'args' key of the backtrace. Obviously, people 
can attach object references wherever they like, but without this 
implicit gathering of objects from the entire environment, 
"serialize(new Exception)" would be a safe operation.

Slightly abbreviated version:

class Example {
     private $label;
     public function __construct($label) {
         $this->label = $label;
     }
     public function __sleep() {
         echo "Attempt to serialize object with label $this->label\n";
         return array('label');
     }
     public function __destruct() {
         echo "Refcount reached zero for object with label $this->label\n";
     }
     public function throwSomething($unused_parameter) {
         throw new Exception;
     }
}

$target = new Example('Target of method call');
$parameter = new Example('Parameter passed but never actually used');
try {
     $target->throwSomething($parameter);
}
catch ( Exception $e ) {
     // Serialize exception, will attempt to serialize $parameter but 
not $target
     var_dump(serialize($e));
     // Destroy $target, as there are no other references to it
     unset($target);
     // Attempt to do the same for $parameter, but Exception holds a 
reference
     unset($parameter);
}
echo "-- PHP process cleanup begins here --\n";
// $parameter will have its destructor fired once $e goes out of scope 
and relinquishes its reference

Regards,

-- 
Rowan Collins
[IMSoP]