如何在 gst_object_unref() 之后调试带有泄漏文件描述符的 gstreamer 管道？

Question

我有一个自定义管道，在 gstreamer 简写中看起来大致如下：

gst-launch-1.0 rtspsrc location=rtsp://<url-for-stream> ! rtph264depay ! h264parse ! imxvpudec ! *any-sink*

• 任何接收器并不重要，可以是 fakesink、imxipusink 或其他什么（我在使用 freescale imx 插件的 imx6 平台上）。我可以输出到我想要的任何接收器，问题是一样的。

这种类型的管道在 gst-launch-1.0 中工作得很好，因为它不需要正确地自行清理，但我需要使用直接 GST API 在我的 C++ 应用程序中使用它。这意味着我使用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

每次我 unref() 并重建管道时，我似乎都会得到两个新的“type=STREAM”文件描述符。

在 lsof 中查看描述符一切都很好，但我不知道如何在代码中追踪这些文件的来源。例如，lsof 的输出是否真的能让我获得更好的调试信息？。我如何追踪这些泄漏的真正来源并阻止它们？一定有更好的方法......对吗？

我怀疑rtspsrcgstreamer 管道元素与此有关，但 rtspsrc 本身就是底层 gstreamer 实现（udpsrcs、解复用器等）的泥潭。我不相信这是 rtspsrc 中的错误，因为还有很多其他人似乎使用这个而不复制相同的东西。我是否可以在我的应用程序代码中做一些可以以不明显的方式带来这种行为的事情？

非常感谢任何帮助，谢谢！

Answer 1

研究充分且有趣的问题！

根据 lsof 输出，泄漏的文件描述符似乎源自套接字对系统调用。您可以使用 strace 确认这一点：

strace -fe 套接字对 myGstApplication

之后，您可以省略对套接字对系统调用的过滤，并查看完整的 strace 输出，尝试了解这些 FD 的用途。我用 gst-launch-1.0 尝试过，但结果不确定。这些 FD 似乎在两端都设置为只读，并且没有传输任何内容...因此它们必须仅用于同一应用程序的多个线程/子进程之间的控制/协调。

下一个尝试是 gdb：

gdb -ex '中断套接字对' -ex 运行 myGstApplication

当它在断点处停止时，使用bt命令查看堆栈跟踪。也许安装 gstreamer 的调试包是获得更具可读性的堆栈跟踪的好主意。

哈:)