Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100189
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
To: PHP Internals <internals@lists.php.net>
Message-ID: <acab7c00-f7b2-9188-a374-96f1dad45029@gmail.com>
Date: Fri, 11 Aug 2017 22:03:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Stop Exceptions capturing object references for trace arguments
From: rowan.collins@gmail.com (Rowan Collins)

Hi All,

This topic has been discussed a couple of times before:
- http://marc.info/?t=138118341600002&r=1&w=2
- http://marc.info/?t=142708828500001&r=1&w=2
- http://marc.info/?t=143798102800002&r=1&w=2
I was inspired to revive the topic by this bug report: 
https://bugs.php.net/bug.php?id=75056&edit=3

Currently, the backtrace of an Exception stores the following:

- function: string
- line: integer
- file: string
- class: string
- type: string
- args: array

This is effectively the same as debug_backtrace() with neither 
DEBUG_BACKTRACE_PROVIDE_OBJECT nor DEBUG_BACKTRACE_IGNORE_ARGS set.

The "args" part of this contains full object references to anything that 
happens to have been a function argument in the stack, and causes two 
problems:

- Serializing an exception can fail, because some of these referenced 
objects may be non-serializable (e.g. SimpleXMLElement, PDO).
- Destructors for these objects do not fire until the Exception is 
destructed, causing resources to be held open unexpectedly after the 
stack has been unwound. (The only other place I know of destructors 
being unreliable in PHP is if there are circular references, in which 
case the destructor will only fire when the GC detects the cycle.)

Both effects are almost entirely unpredictable, because it depends if 
the object happens to have been a parameter in the current stack, rather 
than a local variable or $this reference.

The simplest solution would be to simply remove this 'args' key from the 
backtraces, as when DEBUG_BACKTRACE_IGNORE_ARGS is set on 
debug_backtrace(). This would mean that any normal exception would hold 
no object references, so would not extend any lifetimes, and would not 
trigger any serialization errors.

Obviously, this has the downside of breaking any code that makes use of 
this array; if anyone has examples of practical uses for it I would be 
grateful to see them, and whether a compromise such as storing the class 
name but not the object would be useful.

Regards,

-- 
Rowan Collins
[IMSoP]