# Optional $limit argument for debug_backtrace() - Thread: https://externals.io/message/51811 - Original archive: https://news-web.php.net/php.internals/51811 - Started by Sebastian Bergmann on 2011-04-04T15:22:41+00:00 - Messages: 16 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #51811 — Sebastian Bergmann — 2011-04-04T15:22:41+00:00 URL: https://externals.io/message/51811#51811 https://gist.github.com/901579 is a patch against trunk that adds an optional $limit argument to `debug_backtrace()` to limit the number of frames returned. Any thoughts? -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #51812 — Patrick ALLAERT — 2011-04-04T17:37:44+00:00 URL: https://externals.io/message/51811#51812 · In reply to: #51811 2011/4/4 Sebastian Bergmann : >  https://gist.github.com/901579 is a patch against trunk that adds an >  optional $limit argument to `debug_backtrace()` to limit the number of >  frames returned. > >  Any thoughts? I would then add the same option to `debug_print_backtrace()`. It could also make sense to test it with a limit greater than the actual depth. Cheers, Patrick --- ## #51813 — Ben Schmidt — 2011-04-05T01:56:43+00:00 URL: https://externals.io/message/51811#51813 · In reply to: #51811 Good idea. Have you considered how Xdebug does this kind of thing (through configuration directives, IIRC--I know it uses such things for var_dump) and whether that might suggest a better or more future-proof approach? Ben. > https://gist.github.com/901579 is a patch against trunk that adds an > optional $limit argument to `debug_backtrace()` to limit the number of > frames returned. > > Any thoughts? --- ## #51814 — Sebastian Bergmann — 2011-04-05T05:34:37+00:00 URL: https://externals.io/message/51811#51814 · In reply to: #51812 > I would then add the same option to `debug_print_backtrace()`. Not sure I want to touch `debug_print_backtrace()` as it does not use zend_fetch_debug_backtrace(). > It could also make sense to test it with a limit greater than the > actual depth. The patch has been updated with an extended test. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #51815 — Patrick ALLAERT — 2011-04-05T09:17:03+00:00 URL: https://externals.io/message/51811#51815 · In reply to: #51814 2011/4/5 Sebastian Bergmann : > > > […] > >  Not sure I want to touch `debug_print_backtrace()` as it does not use >  zend_fetch_debug_backtrace(). > > > […] > >  The patch has been updated with an extended test. Don't also forget to change in the test: [file] => /usr/local/src/php/src/trunk/Zend/tests/debug_backtrace_limit.php to something like: [file] => %s/Zend/tests/debug_backtrace_limit.php Patrick -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor --- ## #51816 — Sebastian Bergmann — 2011-04-05T09:20:52+00:00 URL: https://externals.io/message/51811#51816 · In reply to: #51815 > Don't also forget to change in the test: > > [file] => /usr/local/src/php/src/trunk/Zend/tests/debug_backtrace_limit.php > > to something like: > > [file] => %s/Zend/tests/debug_backtrace_limit.php Accidentally reverted that, thanks. Fixed again. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #51817 — Patrick ALLAERT — 2011-04-05T10:39:04+00:00 URL: https://externals.io/message/51811#51817 · In reply to: #51814 2011/4/5 Sebastian Bergmann : > > > […] > >  Not sure I want to touch `debug_print_backtrace()` as it does not use >  zend_fetch_debug_backtrace(). They share nothing in terms of code, but well in terms of function definition: ZEND_FE(debug_backtrace, arginfo_debug_backtrace) ZEND_FE(debug_print_backtrace, arginfo_debug_backtrace) [snip] ZEND_BEGIN_ARG_INFO_EX(arginfo_debug_backtrace, 0, 0, 0) ZEND_ARG_INFO(0, options) ZEND_ARG_INFO(0, limit) ZEND_END_ARG_INFO() I think that the feature will be asked soonish if implemented for `debug_backtrace()` and not for `debug_print_backtrace()`. I've implemented it in a gist fork: https://gist.github.com/903309. Patrick --- ## #51818 — Sebastian Bergmann — 2011-04-05T10:46:57+00:00 URL: https://externals.io/message/51811#51818 · In reply to: #51817 > They share nothing in terms of code Question is: should `debug_print_backtrace()` not be refactored to reuse code from zend_fetch_debug_backtrace()? That is why did not touch it yet. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #51819 — Patrick ALLAERT — 2011-04-05T11:12:53+00:00 URL: https://externals.io/message/51811#51819 · In reply to: #51818 2011/4/5 Sebastian Bergmann : > > > […] > >  Question is: should `debug_print_backtrace()` not be refactored to reuse >  code from zend_fetch_debug_backtrace()? That is why did not touch it >  yet. +1 I greatly share the refactoring need, I will see how this could be done while providing as much internal API as possible so that extension can benefit of. I would, however, refrain from providing erroneous reflection information: php --rf debug_print_backtrace Function [ function debug_print_backtrace ] { - Parameters [2] { Parameter #0 [ $options ] Parameter #1 [ $limit ] } } Patrick --- ## #51820 — Sebastian Bergmann — 2011-04-05T11:57:29+00:00 URL: https://externals.io/message/51811#51820 · In reply to: #51819 > I would, however, refrain from providing erroneous reflection information: > > php --rf debug_print_backtrace > Function [ function debug_print_backtrace ] { > > - Parameters [2] { > Parameter #0 [ $options ] > Parameter #1 [ $limit ] > } > } I did not touch `debug_print_backtrace()`. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #51821 — Christer Edvartsen — 2011-04-05T12:07:12+00:00 URL: https://externals.io/message/51811#51821 · In reply to: #51820 From the ChangeLog: 2004-04-13 Zeev Suraski * zend_builtin_functions.c: Fix debug_backtrace to show arguments again We need to merge code from debug_backtrace & debug_print_backtrace at some point! About time! ;) > > > […] > > I did not touch `debug_print_backtrace()`. > -- Christer Edvartsen cogo@starzinger.net http://cogo.wordpress.com/ --- ## #51822 — Patrick ALLAERT — 2011-04-05T13:23:49+00:00 URL: https://externals.io/message/51811#51822 · In reply to: #51820 2011/4/5 Sebastian Bergmann : > > > […] > >  I did not touch `debug_print_backtrace()`. Yes, you did (or plan to) :) Both `debug_backtrace()` and `debug_print_backtrace()` uses arginfo_debug_backtrace which you modified to include the "limit" parameter: ZEND_BEGIN_ARG_INFO_EX(arginfo_debug_backtrace, 0, 0, 0) ZEND_ARG_INFO(0, options) + ZEND_ARG_INFO(0, limit) ZEND_END_ARG_INFO() Patrick --- ## #51823 — Sebastian Bergmann — 2011-04-05T13:32:55+00:00 URL: https://externals.io/message/51811#51823 · In reply to: #51822 > Both `debug_backtrace()` and `debug_print_backtrace()` uses > arginfo_debug_backtrace Had not noticed that "optimization", thanks. Patch updated. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #51824 — Sebastian Bergmann — 2011-04-06T07:12:42+00:00 URL: https://externals.io/message/51811#51824 · In reply to: #51813 > Good idea. Have you considered how Xdebug does this kind of thing (through > configuration directives, IIRC--I know it uses such things for var_dump) > and whether that might suggest a better or more future-proof approach? I do not want to add any INI directive. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #51845 — Sebastian Bergmann — 2011-04-08T17:58:22+00:00 URL: https://externals.io/message/51811#51845 · In reply to: #51811 Am 04.04.2011 17:22, schrieb Sebastian Bergmann: > Any thoughts? Are there any objections to applying the latest version of the patch [1] to trunk? I still think that debug_backtrace and debug_print_backtrace are in need of refactoring but that should be kept separate, I think. -- [1] https://gist.github.com/901579 -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #51847 — Patrick ALLAERT — 2011-04-08T20:02:49+00:00 URL: https://externals.io/message/51811#51847 · In reply to: #51845 2011/4/8 Sebastian Bergmann : > Am 04.04.2011 17:22, schrieb Sebastian Bergmann: > > […] > >  Are there any objections to applying the latest version of the patch [1] >  to trunk? I still think that debug_backtrace and debug_print_backtrace >  are in need of refactoring but that should be kept separate, I think. Not that this is a true blocker, but as said previously, and considering the very few changes it introduces (https://gist.github.com/910580), I'm not really in favor to introduce it only in debug_bactrack() and not in `debug_print_backtrace()`. Both should be refactored, true, but I don't see the point to make them diverge. I would even say that there is more benefit in terms of maintenance to make them common now than introducing new feature to them. Regards, Patrick