Как отладить конвейер gstreamer с утечкой файловых дескрипторов после gst_object_unref ()? - PullRequest
Новая
       27

Как отладить конвейер gstreamer с утечкой файловых дескрипторов после gst_object_unref ()?

0 голосов
/ 09 октября 2018

У меня есть собственный конвейер, который выглядит примерно так в краткой записи gstreamer: 

gst-launch-1.0 rtspsrc location=rtsp://<url-for-stream> ! rtph264depay ! h264parse ! imxvpudec ! *any-sink*
  • любой сток не имеет значения, может быть fakesink, imxipusink или чем-то еще (я нахожусь наПлатформа imx6 с использованием бесплатных плагинов imx).Я могу вывести на тот приемник, который захочу, и проблема та же.

Этот тип конвейера отлично работает в gst-launch-1.0, потому что ему не нужно очищать себя должным образом, но янужно использовать его в моем приложении C ++, используя прямой GST API.Это означает, что я использую myPipeline = gst_pipeline_new("custom-pipeline"), затем назначаю каждый плагин по имени, связываю их и запускаю конвейер.Позже у меня есть требование остановить конвейер и вызвать gst_object_unref(myPipeline).При этом я наблюдаю, как дескрипторы файлов остаются позади.Позже мне нужно снова начать конвейер, и утечка накапливается.Это должно происходить достаточно часто, чтобы дескрипторы утечки давали мне исключение:

GLib-ERROR **: Creating pipes for GWakeup: Too many open files

Я могу профилировать открытые файлы с помощью lsof ... 

lsof +E -aUc myGstApplication        
lsof: netlink UNIX socket msg peer info error
COMMAND    PID USER   FD   TYPE     DEVICE SIZE/OFF     NODE NAME
myGstApplication 5943 root    3u  unix 0xabfb6c00      0t0 11200335 type=STREAM
myGstApplication 5943 root   11u  unix 0xd9d47180      0t0 11207020 type=STREAM

... еще много, в зависимости от того, как долго это выполняется ... 

myGstApplication 5943 root   50u  unix 0xabe99080      0t0 11211987 type=STREAM

Кажется, я получаю два новых файловых дескриптора 'type = STREAM' каждый раз, когда я отменяю () и перестраиваю конвейер.

Это прекрасно и замечательно видеть дескрипторы в lsof, но я не знаю, как отследить, откуда эти файлы поступают в коде.Может ли какой-нибудь вывод lsof привести меня к лучшей отладочной информации, например?,Как я могу отследить, откуда на самом деле происходят эти утечки, и остановить их?Должен быть лучший путь ... верно?

Я подозреваю, что rtspsrc элемент конвейера gstreamer как-то связан с этим, но rtspsrc сам по себе является болотом базовой реализации gstreamer (udpsrcs, demuxers и т. Д. И т. Д.). Я не уверен, что этоошибка в rtspsrc, потому что многие другие люди используют его, не воспроизводя то же самое.Могу ли я сделать что-то в своем коде приложения, которое может вызвать такое поведение неочевидным способом?

Любая помощь очень ценится, спасибо!

1 Ответ

0 голосов
/ 15 октября 2018

Хорошо изученный и интересный вопрос!

Согласно выводу lsof, утечка файловых дескрипторов, похоже, происходит от системных вызовов socketpair.Вы подтверждаете это с помощью strace:

strace -fe socketpair myGstApplication

После этого вы можете пропустить фильтрацию для sycall сокет-пары и просмотреть полный вывод strace,пытаясь понять, для чего используются эти FD.Я попробовал это с gst-launch-1.0, с неубедительными результатами.Похоже, что эти FD установлены на обоих концах только для чтения, и ничего не передается ... поэтому они должны использоваться для контроля / совмещения между несколькими потоками / подпроцессами только одного и того же приложения.

Следующей попыткой будет gdb:

gdb -ex 'break socketpair' -ex run myGstApplication

Когда он остановится в точке останова, посмотрите на трассировку стека с помощью команды bt ,Вероятно, установка пакетов отладки gstreamer - хорошая идея, чтобы получить более читаемые трассировки стека.

HTH:)

...