Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130471
Precedence: list
MIME-Version: 1.0
Date: Fri, 27 Mar 2026 20:20:50 +0100
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Debug information output in the PHP debug build
In-Reply-To: <CAMW7n8AeJu6Ofc3Ke=Tg2UwMdmt9DW6Ef6Svb_wq2z-GQY8JVg@mail.gmail.com>
References: <CAMW7n8AeJu6Ofc3Ke=Tg2UwMdmt9DW6Ef6Svb_wq2z-GQY8JVg@mail.gmail.com>
Message-ID: <4bebe57bbfc9c56b6b81147a72452690@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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