On 13/04/2025 15:07, Kamil Tekiela wrote:
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.
Oh, I didn't know that. I assumed the arguments wouldn't be freed
until the exception is destructed with it either on or off. In that
case, please ignore everything I said previously.
For reference, this is the code in question:
https://github.com/php/php-src/blob/1684c52a88d1429cf19d4927fe2edf7ff37c66be/Zend/zend_exceptions.c#L257
When the exception is created, it calls the internal implementation of
debug_backtrace, passing either DEBUG_BACKTRACE_IGNORE_ARGS or 0 (which
is why it never captures $this). The result is then stored in the
private $trace property, to be used by whatever wants it later.
zend.exception_string_param_max_len, on the other hand, is used only in
zend_trace_to_string - i.e. when converting the stored trace for
display, or on call to the getTraceAsString() method. It has no effect
if zend.exception_ignore_args was set to 1 when the exception was
created, because the 'args' key won't be there to display.
It might be useful to have a "middle way" for both debug_backtrace() and
exception traces which directly summarised the arguments in some way,
and stored only that summary, thus limiting the performance and
side-effects of capturing the original values. This wouldn't solve the
sensitive information problem, though, so I'm not sure how good an idea
it would be.
--
Rowan Tommins
[IMSoP]
