On the Hackernoon.com site there's a recent post from Paolo Agostinetto showing you how to debug your PHP application with a different tool that most might use: strace.

Every once in a while it happens that you have a tricky bug, and when it does you risk to lose hours or even days fixing it.

[...] Yet, sometimes there is that one bug that makes you lose your shit after a whole afternoon spent looking for the root cause. In my experience, bugs that I introduce are generally very quick and easy to spot and fix. But the real challenge is finding bugs in other people’s code like third party libraries, PHP extensions or even PHP itself.

He then talks about a time when his situation was a bit different - he was getting 500 errors from his code that weren't being caught correctly by error handling. He found that Apache was out-of-memory-ing but debugging the exact cause (a suspect Doctrine query) would take more time. Instead he turned to strace and, with a bit of hunting in the resulting output, he tracked the issue down to XDebug being enabled (and a setting that was generating a memory leak).

On the Speedemy.com site there's a post showing you how to get down to a seriously low level of processing and identify performance issues with strace, the debugging tool that helps monitor interactions between processes, the kernel, system calls, etc.

What do you do when your Linux web app starts acting out? You troubleshoot it, of course! Me too. And today I would like to talk to you about one tool that works really well with all sorts of applications and application servers – ranging from apache http server running modules (mod_php, mod_perl, etc.), to applications running in fast cgi setting or even simple single-threaded programs.

The tool I’m talking about is strace, and if you’re not familiar with it, it will be my pleasure to introduce you two.

They start off by answering the question of when you shouldn't use strace for testing (like when an application can actually be profiled properly) before shows where it can actually help. The post then briefly introduces strace and what it can do, pointing out what kind of information it can provide. From there they start in on using it to do the debugging and show examples of the output it can provide. They help you use some other command line options to refine this output into something a bit more useful and even include an awk command to narrow it down even more .

Derick Rethans has a new post to his blog showing how you can, using a few simple unix tools, figure out what PHP is doing when your scripts are executing.

Sometimes when you have a long running PHP script, you might wonder what the hell it is doing at the moment. There are a few tools that can help you to find out, without having to stop the script. Some of these work only on Linux.

He shows you how to use the following commands to track down exactly what your process is working on: strace, ltrace and gdb (a handy debugger that will probably give you more information than you're looking for). He includes some sample output for the commands and gives an example of a PHP script-to-gdb output relationship.