Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <55BC069A.6000402@gmail.com>
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>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Sat, 01 Aug 2015 01:06:45 +0100
To: Stanislav Malyshev <smalyshev@gmail.com>
CC: PHP Internals <internals@lists.php.net>
Message-ID: <C3727D98-80CA-4006-9ED1-FB679465B350@gmail.com>
Subject: Re: [PHP-DEV] Re: Serializing exceptions
From: rowan.collins@gmail.com (Rowan Collins)

On 1 August 2015 00:36:58 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Hi!
>
>> As I have pointed out several times, it is only the 'args' section of
>> the backtrace that ever contains unserializable items. The solution
>
>previous could too. In fact, right now, since you can unserialize
>exceptions, previous can contain literally anything and so can any
>other
>members. Also, user code can modify any protected properties too.

By that  logic, *no* object should be Serializable, because attempting to do so might recurse to a property that can't be. That doesn't make any sense; what we're talking about here are the native properties of a standard exception, not random data stuffed into the data by a user.


>> 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.

Regards,
-- 
Rowan Collins
[IMSoP]