# Making the hardcoded string length limit of Throwable->getTraceAsString() configurable

- Thread: https://externals.io/message/110717
- Original archive: https://news-web.php.net/php.internals/110717
- Started by tyson andre on 2020-06-24T19:22:13+00:00
- Messages: 6
- RFC: Configurable string length in getTraceAsString() (Implemented (PHP 8.0)) — https://externals.io/rfc/throwable_string_param_max_len.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #110717 — tyson andre — 2020-06-24T19:22:13+00:00

URL: https://externals.io/message/110717#110717

Hi internals,

By default, strings in parameter lists are truncated to 15 bytes by default in Throwable->getTraceAsString()
(and Throwable->__toString() as a consequence).
(in Zend/zend_exception.c in `static void _build_trace_args(zval *arg, smart_str *str)`)

This limit is too short to see relevant information such as file paths, full urls, etc, which makes reporting bugs in applications inconvenient.

Would there be any interest in an ini setting such as `exception_string_length_limit` as a non-negative value to raise this (either allowed to be 0 or more or 15 or more, defaulting to 15)

It's possible to manually work around it by calling Throwable->getTrace(), but inconvenient,
and there's always a concern about the user-space trace generation having its own issues
(e.g. https://github.com/phan/phan/blob/3.0.3/src/Phan/Debug/Frame.php#L25-L132)

In applications that don't have a custom exception handler, users could raise this to make creating bug reports easier.

```
php > test('12345678901234567890');
Warning: Uncaught Exception in php shell code:1
Stack trace:
#0 php shell code(1): test('123456789012345...')
#1 {main}
  thrown in php shell code on line 1
```

Thanks,
- Tyson

---

## #110719 — Alex — 2020-06-24T19:56:42+00:00

URL: https://externals.io/message/110717#110719

>
> By default, strings in parameter lists are truncated to 15 bytes by default in Throwable->getTraceAsString()
> (and Throwable->__toString() as a consequence).
> (in Zend/zend_exception.c in `static void _build_trace_args(zval *arg, smart_str *str)`)
>
> This limit is too short to see relevant information such as file paths, full urls, etc, which makes reporting bugs in applications inconvenient.
>
> Would there be any interest in an ini setting such as `exception_string_length_limit` as a non-negative value to raise this (either allowed to be 0 or more or 15 or more, defaulting to 15)

Just as a suggestion, might it not be simpler just to increase the
limit to something a bit higher than 15?

(Personally, I view the growth of things like .INI parameters with
suspicion. I feel each one should really "carry its weight". But if
this one does, that is fine.)

Alex

---

## #110721 — Ryan Jentzsch — 2020-06-25T02:17:18+00:00

URL: https://externals.io/message/110717#110721 · In reply to: #110717

Why is there a 15 byte limit in the first place?



>
> Hi internals,
>
> By default, strings in parameter lists are truncated to 15 bytes by
> default in Throwable->getTraceAsString()
> (and Throwable->__toString() as a consequence).
> (in Zend/zend_exception.c in `static void _build_trace_args(zval *arg,
> smart_str *str)`)
>
> This limit is too short to see relevant information such as file paths,
> full urls, etc, which makes reporting bugs in applications inconvenient.
>
> Would there be any interest in an ini setting such as
> `exception_string_length_limit` as a non-negative value to raise this
> (either allowed to be 0 or more or 15 or more, defaulting to 15)
>
> It's possible to manually work around it by calling Throwable->getTrace(),
> but inconvenient,
> and there's always a concern about the user-space trace generation having
> its own issues
> (e.g.
> https://github.com/phan/phan/blob/3.0.3/src/Phan/Debug/Frame.php#L25-L132)
>
> In applications that don't have a custom exception handler, users could
> raise this to make creating bug reports easier.
>
> ```
> php > test('12345678901234567890');
> Warning: Uncaught Exception in php shell code:1
> Stack trace:
> #0 php shell code(1): test('123456789012345...')
> #1 {main}
>   thrown in php shell code on line 1
> ```
>
> Thanks,
> - Tyson
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

---

## #110722 — Alex — 2020-06-25T06:51:42+00:00

URL: https://externals.io/message/110717#110722 · In reply to: #110721

> Why is there a 15 byte limit in the first place?

Presumably it might be so that multi-megabyte strings are not dumped
to the console when printing out a stack trace. (Disclaimer: I have
not touched the relevant code and am just guessing.)

---

## #110723 — Thomas Lamy — 2020-06-25T07:26:32+00:00

URL: https://externals.io/message/110717#110723 · In reply to: #110717

Am 24.06.20 um 21:22 schrieb tyson andre:
> Hi internals,
>
> By default, strings in parameter lists are truncated to 15 bytes by default in Throwable->getTraceAsString()
> (and Throwable->__toString() as a consequence).
> (in Zend/zend_exception.c in `static void _build_trace_args(zval *arg, smart_str *str)`)
>
> This limit is too short to see relevant information such as file paths, full urls, etc, which makes reporting bugs in applications inconvenient.
>
> Would there be any interest in an ini setting such as `exception_string_length_limit` as a non-negative value to raise this (either allowed to be 0 or more or 15 or more, defaulting to 15)
>
> (....)
>
> Thanks,
> - Tyson

+1, wanted this for years but never got around to tackle it


Thomas

---

## #110727 — tyson andre — 2020-06-25T13:34:10+00:00

URL: https://externals.io/message/110717#110727 · In reply to: #110722

> > […]
> 
> Presumably it might be so that multi-megabyte strings are not dumped
> to the console when printing out a stack trace. (Disclaimer: I have
> not touched the relevant code and am just guessing.)

It apparently dates back to 2003, when exception::getTraceAsString() was first added.
https://github.com/php/php-src/commit/c80eb4573f8cbc268463c7ec233b467bd9b36b0f#diff-16cc0fb22dbf90c4c465180255880ea0R167
Arguably, computers have more disk space and better processors.

The reasons I can think of to keep a low default limit:
- Syslogs might use udp for async logging, which has a limit of 4096 bytes or so, which hasn't changed
- Code might truncate before logging an exception, and shorter argument representations would allow logging more frames of the stack trace
- Code might log exceptions to disk during abnormal events (e.g. network outages), and too high of a default would fill up disks faster
- CLI apps might fill up the entire screen or terminal scrollback buffer with megabyte-long strings (e.g. `string $file_contents`)

- Tyson