Everything

php

Debug information output in the PHP debug build

php.internals

Edmond Dantes

158 days ago

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");'

>>> RuntimeException

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

Tim Düsterhus

158 days ago

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