你是说一个普通的 pyqt5 应用程序崩溃还是一个普通的 qtvcp 应用程序崩溃？

两个都？

我把它从课堂上拿下来并有一个脚本版本可以工作

#! /usr/bin/python3
from PyQt5 import QtWidgets
import linuxcnc
import hal

s = linuxcnc.stat()
c = hal.component("c")
c.ready()

app = QtWidgets.QApplication([])
label = QtWidgets.QLabel(f"s.actual_position[0]")
label.show()
app.exec()

出现在 pi 特定的线程库中。
https://code.woboq.org/userspace/glibc/nptl/pthread_mutex_lock.c.html#431

python3: pthread_mutex_lock.c:433: __pthread_mutex_lock_full: Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robust' failed.

嗯，看起来像是我忘记从加载的 OriginOffsetDialog 的 ini 文件中删除的额外窗口。现在删除该引用允许它加载，但一旦我加载 OriginOffsetDialog，app.exec() 就会导致段错误。我能找到的最后一件事是在段错误之前执行的：

    rtn = self.app.exec()
  File "/usr/lib/python3/dist-packages/hal_glib.py", line 703, in update
    self.emit('periodic')
  File "/usr/lib/python3/dist-packages/qtvcp/qt_tstat.py", line 367, in periodic_check
    traceback.print_stack()

来自狼剑

    def periodic_check(self, w):
        print("periodic")
        if self._delay < 9:
            traceback.print_stack()
            self._delay += 1
            return

想知道它是否是 PyQt5 和 GLib 事件循环之间的冲突。这可以解释偶尔的 Mutex 错误

这就是我要建议你测试它是否只是一个 qtvcp 问题。
qt/glib 是 x86 上的一个敏感问题。
你可以在 core.py 中看到，类 STATUS，函数 set_timer。

我会注释掉计时器，看看它是否有效果。

注释掉这两行并替换为 pass 似乎没有太大效果。在 hal_glib 的两个位置注释掉 emit(‘periodic’) 似乎允许它“加载”，但一切都非常冻结。

院子里的工作在召唤，所以我今天不得不放弃它。

作为基准，尝试加载 sim/qtvcp_screens/tester 和 sim/axis/qtvcp/qtvcp_tab ，这两个加载应该没有错误，没有做任何花哨的事情。那些不使用 qt5_graphics，所以如果那些不加载是错误的。我刚刚在 py3 和旧的 py2 主版本上都没有问题地进行了测试。我使用带有 originoffset 小部件的轴的自定义偏移选项卡，它在 py2 中也仍然有效。当我一直在积极使用 qt5 安装标志/rpi4 图形驱动程序以尝试解决 qt5_graphics 问题时，我只遇到了每个分段错误
图形未加载过去不是一个进程终止严重错误，但由于某种原因它又一次出现。我定期删除 creator 中的图形，没有它们大多数 guis 运行良好。

当前状态：OriginOffsetDialog 和图形是仅有的两个未加载并导致段错误的东西。

对我来说，图形并不是非常关键，我们的大多数工厂都制作了一个平面简版“将其推到家”和“将其推到运行程序”界面。我们的操作员喜欢没有额外功能的基本功能。我通常只在模拟中使用图形。

我在想如果它是一个已知的 glib 和 qt 冲突问题，我可能只是暂时删除 Originoffsetdialog 的问题代码，并关闭这个问题。

它是 Originoffset 小部件还是只是 Originoffsetdialog ？我刚刚为 py3 做了我的 originoffset 选项卡，它没有任何问题，但我只是使用 originoffset，而不是 originoffsetdialog

编辑，你能从你得到的 qterror 日志中发布你的错误以及一些更多的设置信息，比如 qtversion 吗？从我自己和其他几个用户从预制图像中观察到的情况来看，您从图形中获得分段错误的事实并不是典型的常规安装

如果问题是“周期性”被调用，而不是实际的 Gobject 计时器，那么这是一个新问题。
当我说 glib/qt 在 x86 中是一个问题时，我的意思是它们必须正确排序。
序列与pyqt4不同

将来我可能需要切换到 qt 信号而不是 glib。

但我仍然不确定这是您的实际失败案例。

旧的，但这可能是相关的吗？https://www.qt.io/blog/2006/02/24/qt-and-glib

40 几个小时后，从头开始编译 QT，gcodegraphics 现在似乎可以与 QT5.15 一起使用。

Origin Offset Dialogue 仍然会崩溃，我不知道我们的机械师是否真的在使用它而不只是输入 gcode，所以我对这个项目并不担心。如果我有时间，我会回来做更多的调查。