非UI线程获取QML堆栈追踪频繁崩溃的原因与解决办法

我们的QML应用存在UI线程被QML脚本长时间阻塞的问题（最长可达20秒以上，甚至永久挂起）。为追踪该问题，我们通过后台线程向主线程发送事件并记录事件处理时间，以此判断UI是否完全无响应。

• 若卡顿源于原生代码，可通过线程堆栈追踪定位问题；但卡顿源于QML代码时，因UI线程冻结，无法从主线程获取QML堆栈追踪。
• 我们先尝试从后台线程调用qmlEngine.evaluate("console.trace()")，几乎每次都会崩溃。
• 随后改用调用extern "C" Q_QML_EXPORT char *qt_v4StackTraceForEngine(void *executionEngine)，查看其实现未发现事件处理或垃圾回收操作，但仍频繁在Qt6Qml.dll中崩溃。

我们的疑问：

1. 崩溃原因是什么？如何避免？由于仅在UI线程不可用时执行该代码，无法在UI线程中运行。
2. 是否存在可在不显著降低UI性能的前提下，阻止主线程在执行该函数时处理新事件的方法？

注：应用使用QTJambi，但认为这不会影响该问题。

附参考的qv4engine.cpp中函数实现：

/// !!! for demo only, do not copy it
StackTrace ExecutionEngine::stackTrace(int frameLimit) const
{
    Scope scope(const_cast<ExecutionEngine *>(this));
    ScopedString name(scope);
    StackTrace stack;

    CppStackFrame *f = currentStackFrame;
    while (f && frameLimit) {
        QV4::StackFrame frame;
        frame.source = f->source();
        frame.function = f->function();
        frame.line = f->lineNumber();
        frame.column = -1;
        stack.append(frame);
        if (f->isJSTypesFrame()) {
            if (static_cast<JSTypesStackFrame *>(f)->isTailCalling()) {
                QV4::StackFrame frame;
                frame.function = QStringLiteral("[elided tail calls]");
                stack.append(frame);
            }
        }
        --frameLimit;
        f = f->parentFrame();
    }

    return stack;
}

一、崩溃原因分析 #

1. QML引擎线程安全问题 #

QML引擎（包括V4执行引擎）并非线程安全组件，所有对引擎状态的访问（包括堆栈追踪）都必须在**UI线程（引擎所属线程）**中执行。后台线程直接调用引擎相关API时，会与UI线程的QML执行操作产生并发冲突：

• 即使qt_v4StackTraceForEngine看起来没有显式的事件处理或GC操作，它依然会访问引擎的currentStackFrame等内部状态。当UI线程正处于QML脚本执行的中间状态时，这些内部数据结构可能处于不一致状态（比如堆栈帧正在被修改），后台线程的读取操作会直接触发内存访问错误，导致崩溃。
• qmlEngine.evaluate本质是执行QML/JS代码，跨线程调用会直接破坏引擎的线程上下文，崩溃概率更高。

2. 隐式的线程不安全操作 #

你参考的stackTrace实现中，Scope scope(const_cast<ExecutionEngine *>(this))会创建V4的作用域对象，而作用域依赖于当前线程的执行上下文。后台线程没有初始化V4的线程本地存储（TLS），创建Scope时会访问无效的TLS数据，这也是崩溃的常见诱因。

二、避免崩溃的可行方案 #

既然无法在UI线程正常运行时执行追踪，需要换一种思路获取阻塞时的QML堆栈：

1. 预注入QML脚本监控点 #

在QML脚本的关键执行节点（比如循环、耗时函数前后）注入自定义的堆栈记录逻辑：

• 利用console.trace()或者自定义函数，定期将当前堆栈信息写入线程安全的日志队列（比如QMutex保护的QList）。
• 当后台线程检测到UI阻塞时，直接读取该队列中的最新堆栈记录，无需跨线程调用引擎API。
• 缺点：需要提前预判可能的阻塞点，无法覆盖所有未知的阻塞场景。

2. 利用Qt的调试API做离线分析 #

• 启用Qt的QML调试器，当UI阻塞时，通过调试器连接到进程获取实时堆栈。但调试器会对性能有一定影响，不适合生产环境。
• 使用QJSEngine的setStackCaptureEnabled（Qt 5.12+）或V4引擎的相关配置，让引擎在执行时自动记录堆栈快照，后台线程仅读取预先存储的快照数据（需确保快照存储是线程安全的）。

3. 主线程状态冻结后的安全读取 #

如果必须在后台线程读取引擎状态，唯一的前提是确保UI线程完全停止执行QML代码：

• 不建议使用QThread::terminate()强制终止UI线程，这会导致资源泄漏且风险极高。
• 更安全的方式是：在UI线程的QML执行逻辑中，每执行一段代码就检查一个线程安全的标志位，当后台线程设置该标志时，UI线程主动暂停并将当前堆栈写入共享内存，后台线程再读取。但这种方式需要修改QML执行的底层逻辑，复杂度较高。

三、主线程事件阻塞的优化方案 #

如果需要在主线程执行某些操作时避免处理新事件，同时不显著影响性能，可以采用以下方法：

1. 使用QEventLoop::processEvents的过滤参数 #

在主线程执行关键函数前，临时设置事件过滤器，只允许处理特定类型的事件：

// 仅处理用户输入事件，忽略其他事件
QEventLoop loop;
loop.processEvents(QEventLoop::ExcludeUserInputEvents);
// 或者指定只处理某类事件
loop.processEvents(QEventLoop::EventLoopFlag(QEventLoop::ExcludeUserInputEvents | QEventLoop::ExcludeSocketNotifiers));

这种方式不会完全阻塞事件循环，只是过滤掉非必要事件，性能影响极小。

2. 临时禁用事件队列 #

在执行耗时操作前，调用QCoreApplication::setEventProcessingEnabled(false)禁用事件处理，操作完成后再恢复：

bool wasEnabled = QCoreApplication::setEventProcessingEnabled(false);
// 执行需要独占主线程的操作
QCoreApplication::setEventProcessingEnabled(wasEnabled);

注意：该方法会完全阻止主线程处理任何事件，仅适合极短时间的操作，否则会导致UI假死。如果是在UI已经阻塞的场景下调用（比如你的堆栈追踪场景），该方法不会带来额外性能影响，因为此时UI线程已经无法处理事件。

3. 使用QMutex或QReadWriteLock保护临界区 #

如果主线程的操作需要与后台线程同步，可以用读写锁保护引擎状态的访问：

• UI线程执行QML代码时持有写锁，后台线程读取堆栈时持有读锁。但这种方式会导致后台线程必须等待UI线程释放锁，而你的场景中UI线程已经阻塞，等待会失去意义，因此仅适合UI线程未阻塞时的同步场景。

内容的提问来源于stack exchange，提问作者maxpovver