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:
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
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 viaphp.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.gdbinitscript that
provides azbacktracehelper 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