GUI для xdebug trace файлів

Чи доводилося вам розбиратися в заплутаному коді без виразної документації? Наприклад, що відбувається при створенні сторінки в якій-небудь CMS, або чому і звідки саме чужий код посилає email, або робить щось ще?

Є безліч прийомів для занурення в чужий код. Можна використовувати var_dump(), для чого вам доведеться запускати один і той же сценарій безліч разів. Можна налаштувати відладчик, але тоді вам доведеться заходити (Step Into) у безліч функцій, які не відносяться до того що ви шукаєте, а якщо ви пропустите (Step Over) якийсь важливий виклик, вам доведеться починати все спочатку. Сучасні IDE предоствляют хороші засоби статичного аналізу коду, але і з їх підтримкою буває складно зрозуміти, що відбувається під час виконання.

Довгий час мене приваблювали можливості трасування xdebug, але вручну відстежити що-небудь в многомегабайтном балці абсолютно не реально, а якого-небудь виразного GUI для *.xt файлів я так і не знайшов. Тому вирішив написати свій візуалізатор, про який і хочу розповісти.



Можливо я погано шукав і даремно витратив час на власний велосипед. Якщо ви знаєте хороший GUI для трейсов xdebug, то далі можете не читати, тільки не забудьте залишити посилання в коментарях. Свій GUI я написав на php у вигляді веб-проекту. В ідеалі це має бути плагін для PHPStorm, Eclipse або інший IDE, але я б таке не подужав. Відразу поділюся посиланням на джерело: github.com/vtk13/xdebug-trace-viewer. GUI досить вимоглива до ресурсів, тому ніякого онлайн демо не передбачено. Вам доведеться встановити її на свій сервер, якщо захочете спробувати в живу.

Тут я розповім, що можна дізнатися з трейса на прикладі Joomla. Припустимо, що ви вже знаєте, що таке xdebug і чим xdebug страссировка відрізняється від профілювання. Інакше навіщо вам подібний GUI? Ось рекоммендуемие значення ini параметрів:

  • xdebug.auto_trace=«0» — думаю варто відключити трасування всіх підряд скриптів, щоб не захаращувати сильно папку з trace файлами.
  • xdebug.trace_enable_trigger=«1» — з цією опцією ви зможете робити страссировку тільки цікавлять вас запитів за допомогою GET параметра XDEBUG_TRACE=1
  • xdebug.trace_output_dir="..." — за вашим бажанням
  • xdebug.collect_assignments=«0» — у випадку «1» у xdebug трапляється segmetation fault.
  • xdebug.trace_format=«1» — це едиственный параметр, який обов'язково повинен бути встановлений, щоб xdebug створював trace файли в CSV форматі.
  • xdebug.collect_params=«3» — для більшої інформативності раджу писати в лог значення параметрів. Якщо GUI не впорається з trace файлом, варто спочатку зменшити xdebug.var_display_max_data, xdebug.var_display_max_depth, xdebug.var_display_max_children, а якщо це не допоможе, то тоді вже ставити xdebug.collect_params=«0». З мого досвіду GUI цілком справляючись з trace файлами в декілька мегабайт.


Отже, припустимо, ви пишете своє розширення для Joomla, яке повинно створювати нові статті і хочете дізнатися як створення статей влаштовано в Joomla. Для початку одержимо trace файл. В адмінці joomla допишемо &XDEBUG_TRACE=1 action форми створення статті:



Після створення статті в xdebug.trace_output_dir ви повинні отримати *.xt файл, який повинен відображатися на головній сторінці GUI:



Раз ми аналізуємо створення статті, але напевно варто почати дослідження з mysql функцій. Вибираємо потрібний trace файл і шукаємо «mysql» по іменах виконувалися функцій:



У нашому прикладі, в результатах встрачаются два місця з викликом функції mysqli_query(): mysqli.php:123 і mysqli.php:382. Кожен з викликів може виконуватися безліч разів під час виконання скрипта, але в даному випадку отображенны тільки інформація про попередніх рядках. Відразу скажу, що один з викликів (у файлі mysqli.php рядку 123) виконується тільки один раз при підключенні і не представляє інтересу. А ось другий результат пошуку — «mysqli.php:382 mysqli_query()» — більш цікавий.

За посиланням «mysqli.php:382» в результатах пошуку можна перейти до відображення вихідного коду:



У вихідному коді підсвічені рядка які виконувалися. Варто сказати що підсвічуються не абсолютно всі исполненые рядка. Xdebug записує в trace тільки виклики функцій, тому рядка, наприклад, з присвоєнням змінних відсутні в trace файлі, і отже не вони не підсвічуються в GUI.

До кожної виконаної рядка прикріплено невелике меню доступне по кліку на номері рядки:



У нашому прикладі мене цікавлять всі виклики mysqli_query() функції, для чого потрібно перейти за посиланням «View all calls» в меню 382-го рядка. У списку усіх викликів функції mysqli_query можна знайти 2 виклику з INSERT запитом:



Всього два INSERT для створення статті виглядає не погано — у гіршому випадку ваш плагін зможе створити статтю напряму в базі, якщо не вийде знайти ніякого внутрішнього API для цього. Але поки рано впадати у відчай. За посиланням #11191 у рядку з INSERT можна відкрити stacktrace для даного виклику (цифри в посиланні особливого інтересу не становлять, це id виклику функції з *.tx файлу):



У полученом stacktrace фігурує виклик ContentModelArticle->save(). Чи вийде використовувати цей клас в своєму розширенні — це вже зовсім інша історія. Тим не менш, це вже добра зачіпка.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.