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

我有一个自定义管道，在gstreamer速记中大致如下所示：

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

。。。更多，取决于它运行的时间

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

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

在lsof中看到描述符是很好的，但是我不知道如何在代码中跟踪这些文件的来源。例如，是否有任何lsof输出实际上会使我获得更好的调试信息。我如何追踪这些泄漏的真正来源并阻止它们？有更好的方法。。。对吧?

我怀疑

rtspsrc

gstreamer管道元素与此有关，但rtspsrc本身就是一个底层gstreamer实现（udpsrcs、demuxers等）的泥潭。我不相信这是rtspsrc中的一个bug，因为很多其他人似乎都在使用它而没有复制相同的东西。我是否可以在应用程序代码中做一些不明显的行为

---

非常感谢您的帮助，谢谢

研究得很好，问题也很有趣

根据lsof输出，泄漏的文件描述符似乎来自socketpair系统调用。您可以向strace确认这一点：

strace-fe承插副MYGST应用

在此之后，您可以省去socketpair sycall的过滤，查看完整的strace输出，试图了解这些FD的用途。我用gst-launch-1.0试过这个，结果没有定论。这些FD似乎在两端都设置为只读，并且从未传输任何内容。。。因此，它们只能用于同一应用程序的多个线程/子进程之间的控制/协调

下一次尝试是gdb：

gdb-ex“break socketpair”-ex run myGstApplication

当它在断点处停止时，使用bt命令查看stacktrace。安装gstreamer的调试包可能是一个好主意，可以获得更易于阅读的stacktrace

---

HTH:）

您是否尝试过使用

GST\u DEBUG

选项，该选项为管道中的每个元素提供调试相关信息。是，我看到的唯一一件事是：

0:00:57.383872340 6101 0x69b34fb0警告GST_pad gstpad.c:3990:GST_pad_peer_查询：无法发送粘性事件0:00:57.389069340 6101 0x69b34830警告GST_pad gstpad.c:3990:GST_pad_peer_查询：无法发送粘性事件

的情况完全相同。我的原因是在释放管道时没有移除bus watch-请记住，如果您以前执行过

gst\u bus\u remove\u watch，请执行
gst\u bus\u add\u watch
。谢谢micha-我已经开始玩strace了，但您给了我更多的上下文来玩。我们将再次跟进！我发现一个调用socketpair的gst func正在泄漏。调用
gst_poll_new_timer（）
似乎是创建socketpair的调用，如GDB所示，但我没有成功获取堆栈跟踪：线程1在gst_poll_new_timer（）中从目标：/usr/lib/libgstreamer-1.0.so.0（GDB）bt在gst_poll_new_timer（）中命中断点1，0x6b07b0bc从目标：/usr/lib/libgstreamer-1.0.so.0#1 0x6b096960英寸？？（）来自目标：/usr/lib/libgstreamer-1.0.so.0回溯停止：前一帧与此帧相同（堆栈损坏？）…使用调试包AFAIKscratch我的上一条评论-我需要根据与“yocto”的打球来重新配置我的gdb环境，因为如果不按他们的方式执行，我认为我得到了错误信息。仍在致力于那些可读的堆栈跟踪。。。这是一个可怕的痛苦，只需对后代进行一次更新-这种方法非常有效，我可以找到问题的根源--
gst\u元素\u get\u总线（my\u管道）
的使用在引用计数机制中没有正确减少。拆下管道后，我还必须细化代码，以便在通过
gst\u object\u unref（gst\u object（m\u bus））
创建新管道时减少总线引用
myGstApplication 5943 root   50u  unix 0xabe99080      0t0 11211987 type=STREAM