Edit report at https://bugs.php.net/bug.php?id=64709&edit=1

 ID:                 64709
 Updated by:         ras...@php.net
 Reported by:        williama_lovaton at coomeva dot com dot co
 Summary:            Get a PHP stack trace on process signal
 Status:             Wont fix
 Type:               Feature/Change Request
 Package:            Performance problem
 Operating System:   Linux
 PHP Version:        Irrelevant
 Block user comment: N
 Private report:     N

 New Comment:

I put the link to the gdbinit right in my reply. That explanation should be all 
you need.


Previous Comments:
------------------------------------------------------------------------
[2013-04-26 13:59:48] williama_lovaton at coomeva dot com dot co

Fair enough, I was thinking exactly the same that running as an Apache module 
PHP would not be in charge of the signal handling and the result could be 
unexpected at best.

Is there some kind of documentation that explains in more detail what you are 
saying?  I wonder where can I get the .gdbinit you are referring to.  The thing 
is that I am using PHP 5.3.3 as packaged by Red Hat Enterprise Linux so I guess 
I can't use the one you linked in the comment.

Thanks a lot for your help.

------------------------------------------------------------------------
[2013-04-26 02:04:00] ras...@php.net

Why not just attach gdb to the process and do a bt? I do that all the time. If 
it is in an internal PHP function you will see zif_funcname where zif = zend 
internal function. If it is in a userspace function it is slightly harder. You 
need to install the .gdbinit gdb macros from https://raw.github.com/php/php-
src/master/.gdbinit in your home directory and you can then type zbacktrace and 
you get the entire PHP call stack.

The problem with adding a signal handler is that PHP is often not a standalone 
thing. It is embedded inside Apache or other mechanisms that own the signal 
handling layer. Any signal we pick would conflict with something at the server 
level and this is a rather low-level feature for developers who know what they 
are doing anyway. If they know what they are doing they should be able to 
navigate gdb.

------------------------------------------------------------------------
[2013-04-25 20:29:27] williama_lovaton at coomeva dot com dot co

Thanks for your comments.  I'm using both tools (xdebug and XHProf), they are 
excellent but xdebug has a big performance impact even if you are not using it 
and right now I can't afford that on production, I use it in my development 
environment though.  XHProf is enabled on production and it is really great but 
as far as I know it can only show me the data after the fact.

The specific thing about this feature request is that I want to see where a 
given process is stuck while it's still serving the request.  For example, with 
gstack I can see the process is stuck in the OCIExecute() function executing a 
query or in OCIStmtFetch() function fetching the data (I'm using an Oracle 
database).  But I can't see which PHP function, and hence the query, is causing 
the slowness.

This have been asked before by other people under different scenarios:
http://stackoverflow.com/questions/14261821/get-a-stack-trace-of-a-hung-php-script

But there is no satisfying answer.

I was just wondering if this feature is at all doable.

------------------------------------------------------------------------
[2013-04-25 19:11:18] s...@php.net

Also review XHProf & XHGui

------------------------------------------------------------------------
[2013-04-25 17:19:16] a...@php.net

With performance - what about profiling with xdebug or zend? 

The other were for sure possible catching some signal. Though dunno yet if the 
same gdb functionality is available on windows.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=64709


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64709&edit=1

Reply via email to