g_warning/g_debug

[serzh-z]

Есть ли возможность перехватить вывод функций g_warning/g_debug в чужом собранном приложении, использующем GLib или в релиз-сборке код вывода удаляется? Как всегда убогая G-документация, на этот вопрос как-то слабо отвечает. Цель: получить больше информации о работе плохо документированного опенсорсного приложения.

[/dev/random]

Есть ли возможность перехватить вывод функций g_warning/g_debug в чужом собранном приложении, использующем GLib или в релиз-сборке код вывода удаляется? Как всегда убогая G-документация, на этот вопрос как-то слабо отвечает. Цель: получить больше информации о работе плохо документированного опенсорсного приложения.

Не совсем понятен вопрос (в частности, что значит "перехватить"). Пожалуй, я опишу поведение log-функций в glib, а ты скажешь, содержался ли в этом описании ответ.

g_warning/g_debug - это просто обёртки (макросы или функции, в зависимости от обстоятельств), вызывающие функцию g_log (или g_logv) с указанием соответствующего уровня важности сообщения. g_log проверяет, установило ли приложение log-функцию для этого уровня, и если установило, то вызывает её и возвращает управление. Если нет, то вызывает дефолтный обработчик, который выводит сообщение в stderr и, если уровень важности помечен как фатальный, аварийно завершает процесс. При желании приложение может кроме установки обработчиков для выбранных уровней также заменить дефолтный обработчик. Так что поведение этих функций целиком и полностью зависит от того, перенастраивало ли их приложение.

Кстати, всё это указано в "убогой G-документации".

[serzh-z]

Не совсем понятен вопрос (в частности, что значит "перехватить").

Если прикинуться шлангом, то задача выглядит так: есть открытое приложение, скажем, colord, у которого нет поноценного мана, нет нужной документации и которое не выводит подробную информацию об ошибке. Но вся эта информация, судя по исходникам, явно выводится в g_warning и т.д. Как мне, обычному пользователю, увидеть эти предупреждения и отладочные сообщения, запустив colord из штатного пакета colord дистрибутива?

Пожалуй, я опишу поведение log-функций в glib, а ты скажешь, содержался ли в этом описании ответ.

Ок, спс. Это помогло найти код, настраивающий обработчик логирования и понять, что в GLib нет глобального механизма безусловного перехвата логов, навроде выставления переменной среды, кторую обнаружит GLib и проигнорирует обработчик приложения, явно установив свой. :(

Тогда второй вопрос: обработчик логирования в упомянутом приложении всё сваливает, в конце концов, в g_print. Само приложение запускается и активируется (не знаю, что именно делается в этом случае - возможно, что просто выставляются нужные переменные среды DBUS_*, после чего D-Bus просто выполняет приложение и отключает его от консоли) _системным_ демоном D-Bus. Как перехватить вывод приложения?

Есть мысль попробовать указать в .service-файле скрипт-обёртку (вместо явного пути к бинарю colord), который будет запускать colord и перенаправлять его вывод в файл. Но может есть более внятный способ отладки D-Bus-сервисов?

[Alxn1]

Я бы попробовал вот так вот перехватить g_log (или g_logv):

http://developers.sun.com/solaris/articles...nterposers.html

Это не сложно, на мой взгляд.

[serzh-z]

Я бы попробовал вот так вот перехватить g_log (или g_logv):

Именно какое-то подобное, но _готовое_ решение для Glib меня и интересовало. Тратить выходные на то, чтобы таким методом выяснить что же на самом деле означает сообщение клиента демона - это перебор.

К счастью - подстановка своего скрипта, с перенаправлением вывода, в описание D-Bus сервера, помогло.