Debugging php functions using phpdbg, as an alternative to Xdebug via IDE
Sometimes you have to work with the server through a “bunch” of firewalls, with a local IP with a repository, etc., and for this reason it is quite difficult to configure XDebug to work through NetBeans IDE (and other IDEs). It’s easier to pick up a locally virtual machine. And if XDebug is only needed to quickly get acquainted with a large new project (with a bunch of legacy code) and then debug it through error_log, then debugging individual scripts is not always convenient in it.
The breakpoint, the extra stack of calling connected scripts, etc., do not work correctly. Alternatively, to get acquainted with the new project, you can also configure xhprof and quickly view the stack of function calls on the charts when you call this or that script. In this case, it is good to catch errors of unnecessary function heap calls in loops in which there is no variable initialization inside static. In particular, calls to the same setting from the database inside the loop (foreach, for, while, do-while). Phpdbg differencefrom the above tools in that it allows you to debug a specific function in the logic for a rare bug. Phpdbg is roughly a command-line (console) debugging interface similar to NetBeans (xdebug). If in the IDE we click the mouse points to breakpoints (breakpoints), then in Phpdbg you need to do this in the form of commands.
Let me give you an example of simple code.
For the above PHP code, in order to start debugging the EugeneKurilov () function, you need to run the command:
And then,
Pressing the s (step) command, we go through the body of the function, in order to see how the variable $ j changes, you need to run the watch $ j command:
That is, it’s quite simple in this way to see in live how the value of the variable changes and you do not need to add code like error_log (when viewing in the log) or echo in the browser.
Phpdbg is quite simple (you need to enter help to study the functionality) and for this reason it makes no sense to describe in detail all the points. Starting with PHP 5.6, it is enabled by default. My goal in this post was to show an alternative way to debug code. As my practice shows, the passage of various debug tools for a new project allows you to quickly understand its architecture for the case when there is no documentation, and the project was developed simultaneously by a large number of employees.
The breakpoint, the extra stack of calling connected scripts, etc., do not work correctly. Alternatively, to get acquainted with the new project, you can also configure xhprof and quickly view the stack of function calls on the charts when you call this or that script. In this case, it is good to catch errors of unnecessary function heap calls in loops in which there is no variable initialization inside static. In particular, calls to the same setting from the database inside the loop (foreach, for, while, do-while). Phpdbg differencefrom the above tools in that it allows you to debug a specific function in the logic for a rare bug. Phpdbg is roughly a command-line (console) debugging interface similar to NetBeans (xdebug). If in the IDE we click the mouse points to breakpoints (breakpoints), then in Phpdbg you need to do this in the form of commands.
Let me give you an example of simple code.
For the above PHP code, in order to start debugging the EugeneKurilov () function, you need to run the command:
prompt> break EugeneKurilov
[Breakpoint #0 added at EugeneKurilov]
And then,
prompt> run
[Breakpoint #0 in EugeneKurilov() at /root/dbg.php:3, hits: 1]
>00003: function EugeneKurilov() {
00004: $i = 10;
00005: for($j=0;$j<$i;$j++) {
Pressing the s (step) command, we go through the body of the function, in order to see how the variable $ j changes, you need to run the watch $ j command:
[Breakpoint #0 in EugeneKurilov() at /root/dbg.php:3, hits: 1]
>00003: function EugeneKurilov() {
00004: $i = 10;
00005: for($j=0;$j<$i;$j++) {
prompt> watch $j
[Set watchpoint on $j]
[Breaking on watchpoint $j]
Old value:
New value: 0
>00005: for($j=0;$j<$i;$j++) {
00006: //echo $j;
00007: }
prompt>
Old value: 0
New value: 1
>00005: for($j=0;$j<$i;$j++) {
00006: //echo $j;
00007: }
Old value: 9
New value: 10
>00005: for($j=0;$j<$i;$j++) {
00006: //echo $j;
00007: }
prompt> s
[L5 0x7f9d0c088100 IS_SMALLER $j $i ~3 /root/dbg.php]
[L5 0x7f9d0c088120 EXT_STMT /root/dbg.php]
[L5 0x7f9d0c088140 JMPNZ ~3 J6 /root/dbg.php]
[L9 0x7f9d0c088160 EXT_STMT /root/dbg.php]
>00009: }
prompt> s
[L11 0x7f9d0c0735e0 RETURN 1 /root/dbg.php]
[Script ended normally]
That is, it’s quite simple in this way to see in live how the value of the variable changes and you do not need to add code like error_log (when viewing in the log) or echo in the browser.
Phpdbg is quite simple (you need to enter help to study the functionality) and for this reason it makes no sense to describe in detail all the points. Starting with PHP 5.6, it is enabled by default. My goal in this post was to show an alternative way to debug code. As my practice shows, the passage of various debug tools for a new project allows you to quickly understand its architecture for the case when there is no documentation, and the project was developed simultaneously by a large number of employees.