php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #63188 Display class name when debugging with gdb macro zbacktrace
Submitted: 2012-09-29 19:17 UTC Modified: 2012-10-01 03:32 UTC
From: reeze@php.net Assigned: stas (profile)
Status: Closed Package: Unknown/Other Function
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: reeze@php.net
New email:
PHP Version: OS:

 

 [2012-09-29 19:17 UTC] reeze@php.net
Description:
------------
For example, an uncatched exception backtrace and debug_backtrace()
 have class name if it's an method. but when debugging with gdb,
the macro zbacktrace and dump_bt didn't display it.

it would be easier to debug if the class name displayed

just like:
Fatal error: Uncaught exception 'Exception' with message 'NO' in 
/Users/reeze/Opensource/php-test/php-src-5.4/b.php:5
Stack trace:
#0 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(9): A::bar()
#1 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(15): A->foo(1)
#2 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(20): B->foo(1)
#3 {main}
  thrown in /Users/reeze/Opensource/php-test/php-src-5.4/b.php on line 5

Test script:
---------------
<?php

class A {
    static function bar() {
        core_me('127.0.0.1'); // it will core
    }
    function foo($param) {
        self::bar();
    }
}

class B extends A {
    function foo($param) {
        parent::foo($param);
    }
}

$b = new B();
$b->foo(1);


Expected result:
----------------
[0x100ca4490] core_me("127.0.0.1") /Users/reeze/Opensource/php-test/php-src-
5.4/b.php:5 
[0x100ca43a8] A::bar() /Users/reeze/Opensource/php-test/php-src-5.4/b.php:8 
[0x100ca42b8] A->foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:14 
[0x100ca40e8] B->foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:19 

Actual result:
--------------
[0x100ca4490] core_me("127.0.0.1") /Users/reeze/Opensource/php-test/php-src-
5.4/b.php:5 
[0x100ca43a8] bar() /Users/reeze/Opensource/php-test/php-src-5.4/b.php:8 
[0x100ca42b8] foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:14 
[0x100ca40e8] foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:19 

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-09-29 19:22 UTC] reeze@php.net
A patch was sent here: 
https://github.com/php/php-src/pull/209
 [2012-09-30 15:51 UTC] laruence@php.net
1. it's not a good idea to make 'zbacktrace' require a running process.
2. and why need this? there are file/line/method already
 [2012-09-30 17:54 UTC] reeze@php.net
Hi Laruence,

1. Hmm, it is, if build with zts zbacktrace need running process,
   I know it's another problem:) dump_bt didn't before, that could be fixed
   I will update that to not require running process.

2. It would be easier to debug, such as test script, if there are inherent
   or the same function/method name, method's backtrace are the same as normal
   function. if there are class name, we will not need to check them one by one:)
 [2012-10-01 03:32 UTC] stas@php.net
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.


 [2012-10-01 03:32 UTC] stas@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: stas
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Mon May 05 03:01:31 2025 UTC