|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #24214 debug_backtrace() fails to report __FILE__, __LINE__
Submitted: 2003-06-16 19:33 UTC Modified: 2017-10-24 01:52 UTC
Avg. Score:3.3 ± 1.1
Reproduced:4 of 5 (80.0%)
Same Version:1 (25.0%)
Same OS:2 (50.0%)
From: gk at proliberty dot com Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.3.2 OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: gk at proliberty dot com
New email:
PHP Version: OS:


 [2003-06-16 19:33 UTC] gk at proliberty dot com
debug_backtrace() should behave consistently in order to be useful in all contexts: inside classes, functions and from top level of script file.

However, when exectuted from top level, it returns an empty array.

According to the documentation, it should return an array with minimal info including __LINE__, __FILE__
>debug_backtrace() generates a PHP backtrace and returns this information as an associative array. The possible returned elements are listed in the following table: 
line integer The current line number. See also __LINE__.  
file string The current file name. See also __FILE__.  

Reproduce code:
<?php print_r(debug_backtrace()); ?>

Expected result:
[greg@p3 xobj]$ php /tmp/a.php
array(1) {
    array(4) {
        ["file"] => string(10) "/tmp/a.php"
        ["line"] => int(1)
        ["function"] =>

Actual result:
[greg@p3 xobj]$ php /tmp/a.php


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-17 11:40 UTC]
Can you show an example where this could somehow be useful?
(you can always use __FILE__ and __LINE__ :)

 [2003-06-17 13:30 UTC] gk at proliberty dot com
Yes, below is an example of how I'm using it. 
The purpose is to work around the limited arguments passed to custom error handlers, installed with set_error_handler(), which do not receive class and function information. 

The following function replaces trigger_error() by talking directly to my custom error handler ('phpc_error_handler', omitted for brevity below), using debug_backtrace() to pass class and function info for prepending to error messages.

  phpc_trigger_error( $errorMessage,$errorCode,$debugBacktrace=NULL )
    same as PHP built-in trigger_error, with optional parameter
    generate error message including debugging information
  phpc_trigger_error( $errorMessage,$errorCode,debug_backtrace() );
function phpc_trigger_error( $errorMessage,$errorCode,$debug_backtrace=NULL ){ 

	if (isset($debug_backtrace[0])){
	if (!empty($errclass)) $errclass.='::';
	if (!empty($errfunction)) $errfunction.='(): ';
    $errorMessage=$errclass.$errfunction.$errorMessage.' ';
    phpc_error_handler ($errorCode,$errorMessage,$errfile,$errline);
} // phpc_trigger_error()
 [2003-06-17 14:32 UTC] gk at proliberty dot com
I forgot to point out why the phpc_trigger_error() example is not an adequate workaround for the lack of consistency in debug_backtrace().

Although I use __LINE__ and __FILE__ when $debug_backtrace[0] is not set, these values are pretty useless since they are set from the context of the phpc_trigger_error function, NOT from the place where it was called from; where the error occured. If debug_backtrace() always returned __LINE__ and __FILE__ we would have everything we need.
 [2003-06-18 14:38 UTC]
Just pass the __FILE__ and __LINE__ to your phpc_trigger_error() function, problem solved.


phpc_trigger_error( $errorMessage,$errorCode,__FILE__, __LINE__, debug_backtrace() );

 [2003-06-18 15:12 UTC] gk at proliberty dot com
Your solution is not elegant: adding extra parameters when debug_backtrace() would be enough if it behaved consistently in all cases.

This is also a documentation bug. Please do not set to 'bogus'. How can a feature request be 'bogus'?
 [2003-06-18 15:17 UTC]
fwiw, I also feel this is a valid (and worthy) feature request and assumed debug_backtrace() behaved as such.
 [2003-06-19 17:43 UTC] gk at proliberty dot com
I just realized that the expected result I entered is not consistent with how debug_backtrace() works: function debug_backtrace must also be listed. Here's a revision.

Expected result:
[greg@p3 xobj]$ php /tmp/a.php
    [0] => Array
            [file] => /tmp/a.php
            [line] => 1
            [function] => debug_backtrace
            [args] => Array
 [2003-06-23 17:35 UTC]
Here's quickie patchie which doesn't drop the debug_backtrace() call itself out of the result array.

We could add an optional parameter to debug_backtrace()
which makes it include itself in the result too. Leaving 
open for discussion, I don't need this myself, but if 
enough people think it's useful.... :)


diff -u -r1.124.2.9 zend_builtin_functions.c
--- Zend/zend_builtin_functions.c       16 Jun 2003 15:55:07 -0000
+++ Zend/zend_builtin_functions.c       23 Jun 2003 22:32:13 -0000
@@ -1210,11 +1210,6 @@
        ptr = EG(current_execute_data);
-       /* skip debug_backtrace() */
-       ptr = ptr->prev_execute_data;
-       cur_arg_pos -= 2;
-       frames_on_stack--;
        while (ptr) {

 [2014-04-28 14:34 UTC]
-Package: Feature/Change Request +Package: *General Issues -Operating System: linux ; kernel 2.4.18 +Operating System: Irrelevant
 [2014-04-28 14:34 UTC]
This is still present in 5.5 and in the 5.6 betas.
 [2017-10-24 01:52 UTC]
-Status: Open +Status: Analyzed
 [2017-10-24 01:52 UTC]
-Package: *General Issues +Package: Scripting Engine problem
 [2021-06-06 06:37 UTC]
Automatic comment on behalf of krakjoe
Log: Fix bug #24214 implement access to skip_last in user API for backtrace
 [2021-06-06 06:37 UTC]
-Status: Analyzed +Status: Closed
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Oct 16 22:03:34 2021 UTC