Home PHP GUI for xdebug trace files

GUI for xdebug trace files

by admin

Have you ever had to deal with confusing code without clear documentation? Like what happens when creating a page in some CMS, or why and where exactly someone else’s code sends an email or does something else?
There are many tricks for diving into someone else’s code. You can use var_dump(), which requires you to run the same script multiple times. You can set up a debugger but then you have to step into a lot of functions which don’t belong to what you’re looking for and if you miss (Step Over) an important call you have to start all over again. Modern IDEs provide good tools for static code analysis, but even with their support it can be hard to understand what’s going on at runtime.
For a long time I was attracted to the possibilities of xdebug tracing But I have not found any GUI for *.txt files and I can’t find any way to manually track something in my multi-megabyte log. That’s why I decided to write my own visualizer, which I would like to tell you about.
Maybe I didn’t look too hard and wasted my time with my own bicycle. If you know a good GUI for xdebug trace, then you don’t have to read further but don’t forget to leave a link in the comments. I wrote my GUI in php as a web project. Ideally, it should be a plugin for PHPStorm, Eclipse or another IDE, but I could not make it. I will immediately share a link to the source : github.com/vtk13/xdebug-trace-viewer The GUI is quite resource demanding, so there is no online demo. You will have to install it on your server if you want to try it live.
Here I will tell you what you can learn from trace on Joomla example. Let’s assume you already know what xdebug is and how xdebug differs from profiling Otherwise why do you need such a GUI? Here are the recommended ini parameter values :

  • xdebug.auto_trace="0" – I think you should turn off tracing all the scripts in a row, so as not to clutter up the folder with trace files.
  • xdebug.trace_enable_trigger="1" – with this option you can trace only the queries you are interested in, using GET parameter XDEBUG_TRACE=1
  • xdebug.trace_output_dir="…" – as you wish
  • xdebug.collect_assignments="0" – if "1", xdebug has a segmetation fault.
  • xdebug.trace_format="1" – this is the only parameter that must be set for xdebug to create trace files in CSV format.
  • xdebug.collect_params="3" – for more information, I advise to write the values of the parameters into the log. If the GUI can not cope with the trace file, you should first reduce xdebug.var_display_max_data, xdebug.var_display_max_depth, xdebug.var_display_max_children and if this does not help, then already put xdebug.collect_params="0". In my experience GUI is quite capable to handle files in tens of megabytes.

So, suppose you write your own extension for Joomla which should create new articles and want to know how article creation is done in Joomla. First, let’s get the file. In joomla admin, add XDEBUG_TRACE=1 to the article creation form action :
GUI for xdebug trace files
After creating an article in xdebug.trace_output_dir you should get a *.txt file which should also show up on the main GUI page:
GUI for xdebug trace files
Since we are analyzing the creation of the article, but probably we should start our research with mysql functions. We select the file we want and search for "mysql" by the names of the functions we execute :
GUI for xdebug trace files
In our example, there are two places with calls to mysqli_query() in the results: mysqli.php:123 and mysqli.php:382. Each of the calls may be executed multiple times during the script execution, but this case displays only information about the executed lines. Let me say right away that one of the calls (line 123 in file mysqli.php) is executed only once on connection and is of no interest. But the second search result – "mysqli.php:382 mysqli_query()" is more interesting.
The link "mysqli.php:382" in the search results will take you to the source code display :
GUI for xdebug trace files
The lines which were executed are highlighted in the source code. It is worth to say that not absolutely all executed lines are highlighted. Xdebug only trace records the function calls so strings e.g. with assignment of variables are not present in the trace file and therefore they are not highlighted in the GUI.
A small menu is attached to each executed line, accessible by clicking on the line number :
GUI for xdebug trace files
In our example, I am interested in all calls to the mysqli_query() function, which is done by clicking the "View all calls" link in the 382nd line menu. In the list of all mysqli_query function calls, you can find 2 calls with INSERT query :
GUI for xdebug trace files
Just two INSERTs to create an article doesn’t look bad – in the worst case, your plugin can create an article directly in the database if you can’t find any internal API for that. But it’s too early to despair. By link #11191 in the line with INSERT you can open stacktrace for this call (numbers in the link are not of special interest, they are id of function call from *.tx file):
GUI for xdebug trace files
This stacktrace contains a call to ContentModelArticle-> save(). Whether this class can be used in your extension is another story. Nonetheless, it’s already a good lead.

You may also like