# Debug information output in the PHP debug build

- Thread: https://externals.io/message/130466
- Original archive: https://news-web.php.net/php.internals/130466
- Started by Edmond Dantes on 2026-03-27T09:35:18+00:00
- Messages: 2
- 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

---

## #130466 — Edmond Dantes — 2026-03-27T09:35:18+00:00

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

Hello all

I would like to share an idea regarding improving debug information
for ZEND_ASSERT and exceptions.

Why has this become relevant to me? At this stage of development,
asynchronous core code tends to expose hidden bugs that are not
detected in the usual way. I am considering adding a telemetry service
to PHP with the ability to collect information, since in such cases
logging is the only reliable solution.
But this post is not about that.

## The idea

When a regular PHP exception or ASSERT is triggered, output two
backtraces: one for PHP and one for C.
To avoid breaking existing tests, this output could be optionally
suppressed via `php.ini`.

To achieve this, https://github.com/ianlancetaylor/libbacktrace is
used — almost an industry standard!

## How it looks:

```text
edmond@Edmond:~/php-src$ ./sapi/cli/php -d
zend.exception_c_backtrace=1 -r 'throw new RuntimeException("test");'

> > […]
    at /home/edmond/php-src/Zend/zend_exceptions.c:178

--- C backtrace ---
  #0  zend_throw_exception_internal
/home/edmond/php-src/Zend/zend_exceptions.c:178
  #1  zend_throw_exception_object
/home/edmond/php-src/Zend/zend_exceptions.c:1043
  #2  ZEND_THROW_SPEC_TMP_HANDLER
/home/edmond/php-src/Zend/zend_vm_execute.h:17281
  #3  execute_ex
/home/edmond/php-src/Zend/zend_vm_execute.h:112392
  #4  zend_execute
/home/edmond/php-src/Zend/zend_vm_execute.h:115483
  #5  zend_eval_stringl
/home/edmond/php-src/Zend/zend_execute_API.c:1491
  #6  zend_eval_stringl_ex
/home/edmond/php-src/Zend/zend_execute_API.c:1533
  #7  zend_eval_string_ex
/home/edmond/php-src/Zend/zend_execute_API.c:1543
  #8  do_cli                         /home/edmond/php-src/sapi/cli/php_cli.c:988
  #9  main
/home/edmond/php-src/sapi/cli/php_cli.c:1369
  #10 __libc_start_call_main         ../sysdeps/nptl/libc_start_call_main.h:58
  #11 __libc_start_main_impl         ../csu/libc-start.c:360
  #12 0x55c9f5e0b444                ??:0
  #13 0xffffffffffffffff            ??:0

--- PHP backtrace ---
  #0  Command line code:1 {main}()

Fatal error: Uncaught RuntimeException: test in Command line code:1
Stack trace:
#0 {main}
  thrown in Command line code on line 1

For Windows, a different library will be required. Maybe someone has ideas?

Thanks

---

## #130471 — tim@bastelstu.be — 2026-03-27T19:20:50+00:00

URL: https://externals.io/message/130466#130471 · In reply to: #130466

Hi

Am 2026-03-27 10:35, schrieb Edmond Dantes:
> When a regular PHP exception or ASSERT is triggered, output two
> backtraces: one for PHP and one for C.
> To avoid breaking existing tests, this output could be optionally
> suppressed via `php.ini`.

I don't think having a C-level backtrace for a PHP-level Exception is 
particularly useful. It will usually just point towards the ZEND_THROW 
opcode.

For failed assertions, PHP will already abort, which (when properly 
configured) will result in a coredump that can be investigated with gdb 
- and if it's reproducible you can just run in gdb directly and don't 
need to rely on coredumps. PHP also includes a `.gdbinit` script that 
provides a `zbacktrace` helper to generate a PHP-level stacktrace from 
within gdb.

So I don't quite see how including C-level backtrace generation within 
PHP itself will make things easier vs. just adding complexity. When 
developing PHP you can just use gdb, which will also allow you to step 
through the code.

Best regards
Tim Düsterhus