php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #64709 Get a PHP stack trace on process signal
Submitted: 2013-04-25 16:22 UTC Modified: 2013-04-26 18:32 UTC
From: williama_lovaton at coomeva dot com dot co Assigned:
Status: Wont fix Package: Performance problem
PHP Version: Irrelevant OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2013-04-25 16:22 UTC] williama_lovaton at coomeva dot com dot co
Description:
------------
I'm not sure if this is possible to implement or if it's implemented now but I'd like a way to get a PHP stack trace of a running process on any given time (may be using a process signal with kill).

This would be very similar to what you can do with Java, you do a "kill -3 <pid>" but the process doesn't die, instead it outputs a full backtrace of Java code of every thread and the current state.

You can do something similar now using the gstack command from GDB but you'll get a stack trace from the C code.  I'd like to be able to get a stack trace but from the PHP code so that I can analyze where is the exact point in the program where my web app is running slow or getting stuck.

My web app is instrumented and I can get logs from slow functions but this is information I get after the fact.  With this feature request it would be possible to get the information exactly when it is happening.

Is this possible?  If so, would it be possible to make it work if PHP is being run as an Apache module?

Thanks a lot for your time.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-04-25 17:19 UTC] ab@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.
 [2013-04-25 19:11 UTC] sixd@php.net
Also review XHProf & XHGui
 [2013-04-25 20:29 UTC] 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-26 02:04 UTC] rasmus@php.net
-Status: Open +Status: Wont fix
 [2013-04-26 02:04 UTC] rasmus@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-26 13:59 UTC] 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 18:32 UTC] rasmus@php.net
I put the link to the gdbinit right in my reply. That explanation should be all 
you need.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Apr 15 02:01:24 2021 UTC