Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127101
Feedback-ID: id5114917:Fastmail
Message-ID: <ab57e3c7-d744-4a2b-bdcf-54e8f14cccc1@rwec.co.uk>
Date: Sun, 13 Apr 2025 12:53:58 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Discussion] Change default for
 zend.exception_ignore_args INI setting
To: internals@lists.php.net
References: <CAObMQFcUB48LEusdtYNS2hnr_qyKJppC11qfbGxkOkuKQtqmEg@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAObMQFcUB48LEusdtYNS2hnr_qyKJppC11qfbGxkOkuKQtqmEg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 09/04/2025 03:00, Andrew Lyons wrote:
> Hi everyone,
>
> I've been working on a new RFC which proposes changing the default 
> value for the zend.exception_ignore_args INI setting from Off to On.
>
> The intent of this change is to make PHP installations safer by 
> default and prevent the accidental release of sensitive information in 
> stack traces.
>
> * RFC: https://wiki.php.net/rfc/exception_ignore_args_default_value
> * Implementation: https://github.com/php/php-src/pull/18215


This discussion seems to have overlooked that the setting doesn't just 
restrict the *display* of arguments, it restricts the *collection* of 
those arguments into the Exception object, which has visible effects on 
the behaviour and performance of the program.

Because of PHP's reference counting memory model, programmers can 
usually rely on memory being freed and destructors being called when a 
local variable goes out of scope. Without zend.exception_ignore_args=1, 
the lifetime of any zval which happened to be involved in a parameter 
anywhere on the stack, is extended to last until the Exception object is 
destructed. That can mean holding onto large amounts of memory, holding 
open file handles and network connections, or firing "RAII" destructors 
in an unexpected order.

Note that this is tied to the lifetime of the exception object, not when 
it is thrown and caught; and it is recursive - an array containing an 
object with a property pointing to another object keeps all those arrays 
and objects alive, just in case you want to inspect them in the error trace.

Another edge case I encountered a few years ago is when I wrote some 
code that serialized an exception (to propagate it from a worker process 
to its parent): the exception itself was serializable, but a completely 
unrelated change caused an unserialized object to show up as a parameter 
somewhere on the call stack, causing the whole exception to become 
unserializable.


On the other side, PHP is not a Functional Programming language, so 
knowing the arguments that were passed into a function is rarely enough 
to reconstruct the state that led to the exception. Manual backtraces 
can also collect a copy of $this for method calls, with the 
DEBUG_BACKTRACE_PROVIDE_OBJECT option, but the exception constructor 
never passes that. Nor does it collect a snapshot of static and global 
variables, or the state of opaque objects and resources like file/stream 
handles.

Collecting arguments seems like a special case which could be handled by 
debug or APM extensions, rather than something that most users will ever 
need.


-- 
Rowan Tommins
[IMSoP]