Derick Rethans has shared a post on his site with an experience he had with a mystery of missing breakpoints and some issues he commonly is asked about regarding Xdebug's breakpoint functionality.

Occasionally I see people mentioned that Xdebug does not stop at certain breakpoints. This tends to relate to multi-line if conditions, or if/else conditions without braces ({ and }).

f you set a breakpoint at either line 7, 11, or 12, you'll find that these are ignored. But why is that?

To help explain, he uses the vld tool to show the opcode behind the language's processing. In its results you can see that a EXT_STMT code is missing for the lines where the breakpoints were set. Xdebug doesn't see the marker it's expecting so the breakpoint isn't recognized and execution isn't halted as expected. He offers some suggestions you can use of other tools and functions to make sure the location you've selected can actually accommodate a breakpoint.

On the JetBrains site there's a recent post showing you how to use just-in-time debugging and breakpoints in their PHPStorm IDE combined with the popular PHP debugging tool Xdebug.

In every project comes a moment where code stabilizes and we don’t want to keep the debugger attached to our code all the time. Or maybe we just want to run our code and only attach the debugger when an error occurs or an exception is thrown. Meet Xdebug’s just-in-time (jit) mode and PHP Exception Breakpoints in PhpStorm!

This feature makes use of the "jit" setting for the "remote_mode" setting that Xdebug offers to only send debugging information back to the remote debugger with an error occurs. They show you how to set up PHPStorm for these debugger connections and some example screenshots of it in action. The breakpoints feature compliments this functionality by allowing you to set breakpoints on which kind of errors you want to see information about (ex. warning, notice or deprecated issues).

Derick Rethans has posted a shootout of a few of the debugging protocols out there, really a comparison between the debugger that Zend is using in its Eclipse PHP IDE and the DBGp package.

He talks about some of the controversy that's surrounded Zend's choice and methods for their debugger and how it compares on various levels to DBGp (the debugger used in Komodo and various other places).

The topics he compares them under include:

• Protocol Communication
• Session Initialization
• Transporting Variables
• Breakpoint Support
• Output Capturing

Under each, there's mentions of how they are supported (or not supported, as the case my be) and what kind of options each has to offer.

Derick Rethans has posted a shootout of a few of the debugging protocols out there, really a comparison between the debugger that Zend is using in its Eclipse PHP IDE and the DBGp package.

He talks about some of the controversy that's surrounded Zend's choice and methods for their debugger and how it compares on various levels to DBGp (the debugger used in Komodo and various other places).

The topics he compares them under include:

• Protocol Communication
• Session Initialization
• Transporting Variables
• Breakpoint Support
• Output Capturing

Under each, there's mentions of how they are supported (or not supported, as the case my be) and what kind of options each has to offer.