GUI for xdebug trace files
Have you ever understood confusing code without clear documentation? For example, what happens when a page is created in a CMS, or why and from where does someone else's code send an email, or do something else?
There are many techniques for diving into someone else's code. You can use var_dump (), for which you will have to run the same script many times. You can set up a debugger, but then you have to go (Step Into) to many functions that do not relate to what you are looking for, and if you miss (Step Over) an important challenge, you will have to start all over again. Modern IDEs provide good static code analysis tools, but with their support it can be difficult to understand what happens at runtime.
For a long time, I was attracted by the xdebug tracing capabilities , but it’s completely unrealistic to track something in the multi-megabyte log, and I never found any intelligible GUI for * .xt files. So I decided to write my own visualizer, which I want to talk about.
')
Maybe I was looking bad and wasted my time on my own bike. If you know a good GUI for xdebug traces, then you can not read further, just do not forget to leave the link in the comments. I wrote my GUI in php as a web project. Ideally, this should be a plugin for PHPStorm, Eclipse or another IDE, but I would not master it. Immediately share a link to the source: github.com/vtk13/xdebug-trace-viewer . The GUI is quite resource intensive, so no online demo is provided. You will have to install it on your server if you want to try it live.
Here I will tell you what can be learned from the treys by the example of Joomla. Suppose you already know what xdebug is and how tracing differs from profiling in xdebug . Otherwise, why do you need a similar GUI? Here are the recommended ini parameter values:
So, let's say you are writing your own extension for Joomla, which should create new articles and want to find out how article creation is organized in Joomla. First we get a trace file. In the joomla admin panel, we add & XDEBUG_TRACE = 1 in the action of the article creation form:
After creating an article in xdebug.trace_output_dir, you should get a * .xt file, which should also be displayed on the main GUI page:
Since we are analyzing the creation of an article, we should probably start researching with mysql functions. Select the desired trace file and look for “mysql” by the names of the executed functions:
In our example, there are two places in the results with the call to the mysqli_query () function: mysqli.php: 123 and mysqli.php: 382. Each of the calls can be executed many times during the execution of the script, but in this case only information about the executed lines is displayed. Immediately I will say that one of the calls (in the file mysqli.php line 123) is executed only once when connected 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 can be used to display the source code:
In the source code, the lines that were executed are highlighted. It is worth saying that not all the executed lines are highlighted. Xdebug writes only function calls to trace, so strings, for example, with assignment of variables are absent in the trace file, and therefore they are not highlighted in the GUI.
Each executed line has a small menu attached by clicking on the line number:
In our example, I am interested in all the mysqli_query () function calls, for which I need to follow the “View all calls” link in the 382nd line menu. In the list of all calls to the mysqli_query function, you can find 2 calls with an INSERT request:
Just two INSERT for creating an article does not look bad - in the worst case, your plugin will be able to create an article directly in the database, if you cannot find any internal API for this. But it is too early to despair. The link # 11191 in the line with INSERT can open the stacktrace for this call (the numbers in the link are of no particular interest, these are the id of the function call from the * .tx file):
The resulting stacktrace contains a call to ContentModelArticle-> save (). Whether it will turn out to use this class in its extension is another story. However, this is a good lead.
There are many techniques for diving into someone else's code. You can use var_dump (), for which you will have to run the same script many times. You can set up a debugger, but then you have to go (Step Into) to many functions that do not relate to what you are looking for, and if you miss (Step Over) an important challenge, you will have to start all over again. Modern IDEs provide good static code analysis tools, but with their support it can be difficult to understand what happens at runtime.
For a long time, I was attracted by the xdebug tracing capabilities , but it’s completely unrealistic to track something in the multi-megabyte log, and I never found any intelligible GUI for * .xt files. So I decided to write my own visualizer, which I want to talk about.
')
Maybe I was looking bad and wasted my time on my own bike. If you know a good GUI for xdebug traces, then you can not read further, just do not forget to leave the link in the comments. I wrote my GUI in php as a web project. Ideally, this should be a plugin for PHPStorm, Eclipse or another IDE, but I would not master it. Immediately share a link to the source: github.com/vtk13/xdebug-trace-viewer . The GUI is quite resource intensive, so no online demo is provided. You will have to install it on your server if you want to try it live.
Here I will tell you what can be learned from the treys by the example of Joomla. Suppose you already know what xdebug is and how tracing differs from profiling in xdebug . Otherwise, why do you need a similar GUI? Here are the recommended ini parameter values:
- xdebug.auto_trace = "0" - I think it is worth turning off the tracing of all the scripts in a row so as not to clutter up the folder with the trace files.
- xdebug.trace_enable_trigger = "1" - with this option you can trace only the queries you are interested in using the GET parameter XDEBUG_TRACE = 1
- xdebug.trace_output_dir = "..." - according to your desire
- xdebug.collect_assignments = "0" - in the case of "1" for xdebug a segmetation fault occurs.
- xdebug.trace_format = "1" is the only parameter that must be set in order for xdebug to create trace files in CSV format.
- xdebug.collect_params = "3" - for more information I advise you to write parameter values ​​to the log. If the GUI does 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 set xdebug.collect_params = "0". In my experience, the GUI copes well with trace files of ten megabytes.
So, let's say you are writing your own extension for Joomla, which should create new articles and want to find out how article creation is organized in Joomla. First we get a trace file. In the joomla admin panel, we add & XDEBUG_TRACE = 1 in the action of the article creation form:
After creating an article in xdebug.trace_output_dir, you should get a * .xt file, which should also be displayed on the main GUI page:
Since we are analyzing the creation of an article, we should probably start researching with mysql functions. Select the desired trace file and look for “mysql” by the names of the executed functions:
In our example, there are two places in the results with the call to the mysqli_query () function: mysqli.php: 123 and mysqli.php: 382. Each of the calls can be executed many times during the execution of the script, but in this case only information about the executed lines is displayed. Immediately I will say that one of the calls (in the file mysqli.php line 123) is executed only once when connected 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 can be used to display the source code:
In the source code, the lines that were executed are highlighted. It is worth saying that not all the executed lines are highlighted. Xdebug writes only function calls to trace, so strings, for example, with assignment of variables are absent in the trace file, and therefore they are not highlighted in the GUI.
Each executed line has a small menu attached by clicking on the line number:
In our example, I am interested in all the mysqli_query () function calls, for which I need to follow the “View all calls” link in the 382nd line menu. In the list of all calls to the mysqli_query function, you can find 2 calls with an INSERT request:
Just two INSERT for creating an article does not look bad - in the worst case, your plugin will be able to create an article directly in the database, if you cannot find any internal API for this. But it is too early to despair. The link # 11191 in the line with INSERT can open the stacktrace for this call (the numbers in the link are of no particular interest, these are the id of the function call from the * .tx file):
The resulting stacktrace contains a call to ContentModelArticle-> save (). Whether it will turn out to use this class in its extension is another story. However, this is a good lead.
Source: https://habr.com/ru/post/242275/
All Articles