Python 使用PyGTK和PyGST的神秘segfault按照gdb中的预期运行

我正在尝试编写一个概念验证python程序，以在pyGTK DrawingArea对象中显示视频（使用gstreamer），最终目标是实现类似屏幕保护程序的行为，以循环方式运行视频并在鼠标活动时退出

然而，当我成功地将gstreamer输出连接到pygtk创建的X窗口时，我遇到了一个segfault。然而，在GDB中运行它通常会按预期工作（不是全屏，但我认为这是一个单独的问题），如果我在GDB中运行它，那么为了让事情变得更有趣，我在GDB之外的下一次运行也会成功，但随后会失败

这是我正在使用的代码：（python 2.7）

当我通过命令行运行它时：

user@kiosk:~$ ./vidtest.py
varea realized
Segmentation fault (core dumped)

鉴于在gdb中：

user@kiosk:~$ gdb python
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/python...Reading symbols from /usr/lib/debug/usr/bin/python2.7...done.
done.
(gdb) run vidtest.py
Starting program: /usr/bin/python vidtest.py
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe6dc9700 (LWP 740)]
[New Thread 0x7fffe65c8700 (LWP 741)]
varea realized
Traceback (most recent call last):
  File "vidtest.py", line 13, in on_new_decoded_pad
    self.demux.link(self.h264)
gst.LinkError: failed to link demux with h264
linked!
[New Thread 0x7fffe4aba700 (LWP 742)]
[Thread 0x7fffe4aba700 (LWP 742) exited]
^C
Program received signal SIGINT, Interrupt.
0x00007ffff6990d83 in poll () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)

user@kiosk：~$gdb python
GNU gdb（Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1）7.4-2012.04
版权所有（C）2012免费软件基金会。
许可证GPLv3+：GNU GPL版本3或更高版本
这是自由软件：您可以自由更改和重新发布它。
在法律允许的范围内，不存在任何担保。键入“显示复制”
和“显示保修”了解详细信息。
此GDB配置为“x86_64-linux-gnu”。
有关错误报告说明，请参阅：
...
从/usr/bin/python读取符号…从/usr/lib/debug/usr/bin/python2.7读取符号…完成。
完成。
（gdb）运行vidtest.py
启动程序：/usr/bin/python vidtest.py
警告：在0x7FFFF7FFA0000处添加的符号文件系统提供的DSO中找不到可加载的节
[已启用使用libthread_db的线程调试]
使用主机libthread_db library“/lib/x86_64-linux-gnu/libthread_db.so.1”。
[新螺纹0x7fffe6dc9700（LWP 740）]
[新螺纹0x7fffe65c8700（LWP 741）]
瓦雷亚意识到
回溯（最近一次呼叫最后一次）：
文件“vidtest.py”，第13行，在新解码的键盘上
self.demux.link（self.h264）
gst.LinkError:无法将解复用器链接到h264
链接！
[新螺纹0x7fffe4aba700（LWP 742）]
[线程0x7fffe4aba700（LWP 742）已退出]
^C
程序收到信号SIGINT，中断。
0x00007FF6990D83位于/lib/x86_64-linux-gnu/libc.so.6的轮询（）中
（gdb）

我不担心失败的链接（这是我不需要的音轨，尽管我最终必须处理它），但程序运行正常，然后用Ctrl-C终止

我成功地对其运行了strace，并发现segfault就发生在这附近：

user@kiosk:~$ strace ./vidtest.py
<Omitted for brevity...>
open("/home/user/TestMpeg4.mp4", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0664, st_size=10947268, ...}) = 0
lseek(6, 0, SEEK_END)                   = 10947268
lseek(6, 0, SEEK_SET)                   = 0
fstat(6, {st_mode=S_IFREG|0664, st_size=10947268, ...}) = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f4afe20e000
mprotect(0x7f4afe20e000, 4096, PROT_NONE) = 0
clone(child_stack=0x7f4afea0dff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f4afea0e9d0, tls=0x7f4afea0e700, child_tidptr=0x7f4afea0e9d0) = 863
futex(0x184a9b0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x118fed0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1851900, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1758500, FUTEX_WAKE_PRIVATE, 1) = 1
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
uname({sys="Linux", node="kiosk", ...}) = 0
fstat(1,  <unfinished ...>
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
user@kiosk:~$

user@kiosk：~$strace./vidtest.py
打开（“/home/user/TestMpeg4.mp4”，O_RDONLY）=6
fstat（6，{st_mode=S_IFREG | 0664，st_size=10947268，…}）=0
lseek（6，0，搜索结束）=10947268
lseek（6,0，SEEK_集）=0
fstat（6，{st_mode=S_IFREG | 0664，st_size=10947268，…}）=0
写入（5，“\1\0\0\0\0\0”，8）=8
mmap（NULL，8392704，保护读取，保护写入，映射私有，映射匿名，映射堆栈，-1，0）=0x7f4afe20e000
mprotect（0x7f4afe20e000，4096，无保护）=0
克隆（子堆栈=0x7f4afea0dff0，标志=clone|VM |克隆| FS |克隆|文件|克隆| SIGHAND |克隆| SYSVSEM |克隆|父设置TID |克隆|子清除TID |父tidptr=0x7f4afea0e9d0，tls=0x7f4afea0e700，子TIDR=0xF4AFEA0E863）=
futex（0x184a9b0，futex_WAKE_PRIVATE，1）=1
futex（0x118fed0，futex_WAKE_PRIVATE，1）=1
futex（0x1851900，futex_WAKE_PRIVATE，1）=1
futex（0x1758500，futex_WAKE_PRIVATE，1）=1
写入（5，“\1\0\0\0\0\0”，8）=8
写入（5，“\1\0\0\0\0\0”，8）=8
uname（{sys=“Linux”，node=“kiosk”，…}）=0
财政司司长（1，
+++被SIGSEGV杀死（堆芯倾倒）+++
分段故障（堆芯转储）
user@kiosk:~$

任何关于可能发生的情况的线索（鉴于这是一个segfault，我假设pygst或pygtk中存在某种内存问题，但我不确定是什么导致了它）或更多调试步骤都将不胜感激

user@kiosk:~$ strace ./vidtest.py
<Omitted for brevity...>
open("/home/user/TestMpeg4.mp4", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0664, st_size=10947268, ...}) = 0
lseek(6, 0, SEEK_END)                   = 10947268
lseek(6, 0, SEEK_SET)                   = 0
fstat(6, {st_mode=S_IFREG|0664, st_size=10947268, ...}) = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f4afe20e000
mprotect(0x7f4afe20e000, 4096, PROT_NONE) = 0
clone(child_stack=0x7f4afea0dff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f4afea0e9d0, tls=0x7f4afea0e700, child_tidptr=0x7f4afea0e9d0) = 863
futex(0x184a9b0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x118fed0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1851900, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1758500, FUTEX_WAKE_PRIVATE, 1) = 1
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
uname({sys="Linux", node="kiosk", ...}) = 0
fstat(1,  <unfinished ...>
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
user@kiosk:~$