Question

我有一个自定义管道，大致类似于gstreamer的简写：

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

任何接收器都没关系，可以是假接收器，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输出实际上可以引导我获得更好的调试信息？。如何跟踪这些泄漏的真正来源并阻止它们？有更好的方法...对吗？

我怀疑rtspsrc gstreamer管道元素与此有关，但是rtspsrc本身是底层gstreamer实现的麻烦（udpsrcs，多路分解器等），我不认为这是一个错误在rtspsrc内，因为有太多其他人似乎在使用该程序而不复制同一件事。我可以在我的应用程序代码中做一些事情，以一种非显而易见的方式实现这种行为吗？

非常感谢您的帮助！

Answer 1

精心研究且有趣的问题！

根据lsof输出，泄漏的文件描述符似乎源自套接字对syscall。您通过strace确认这一点：

strace -fe socketpair myGstApplication

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

下一个尝试将是gdb：

gdb -ex'break socketpair'-ex运行myGstApplication

当它在断点处停止时，使用 bt 命令查看堆栈跟踪。可能安装gstreamer的调试软件包是获取更易理解的堆栈跟踪的好主意。

HTH：）

如何在gst_object_unref（）之后泄漏文件描述符来调试gstreamer管道？

1 个答案: