【问题标题】:Qt application crashes on exit, OS applies "fault tolerant heap shim"Qt 应用程序在退出时崩溃,操作系统应用“容错堆 shim”
【发布时间】:2014-09-19 11:24:18
【问题描述】:

我无法找出导致应用程序在退出时崩溃的原因。更令人困惑的是,它并不总是崩溃,有时会,有时不会,而且似乎完全是任意的。

该示例基本上创建了一个自定义图像提供程序,该提供程序将静态谷歌地图 API 请求加载为 PNG 图像以在 QML 中显示。图像提供程序本身可以工作,我首先怀疑问题可能在于在堆栈上实例化网络访问管理器,但事实并非如此,我动态实例化它时得到相同的行为。有趣的是,崩溃似乎与任何特别的事情无关。只是启动和关闭应用程序有时会在没有任何交互的情况下产生崩溃,但在没有任何交互的情况下它大多不会崩溃。有时与地图中心和缩放的多次交互不会导致退出时崩溃,但大多数情况下确实如此。

另一个嫌疑人是我实例化的事件循环,以便在网络请求完成时“阻止”图像提供程序方法。由于图像提供者的设计,图像必须由请求它的相同方法返回,换句话说,我不能使用“推荐”的方法,即仅从方法启动请求并通过连接其completed 捕获它信号给另一种方法。但这似乎也不是,因为提供者总是设法提供图像,我认为它没有问题。至少不是直接的,但可能是网络访问的一些副作用?

顺便说一句,Qt 仅在第一次使用网络访问管理器时会发出一些警告。在 Qt 5.2 中,我只得到了这四个:

QSslSocket: cannot resolve TLSv1_1_client_method
QSslSocket: cannot resolve TLSv1_2_client_method
QSslSocket: cannot resolve TLSv1_1_server_method
QSslSocket: cannot resolve TLSv1_2_server_method
QSslSocket: cannot resolve SSL_select_next_proto

...在升级到新的 5.3.1 以希望删除这些警告之后,实际上除了前四个之外还出现了两个:

QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb
QSslSocket: cannot resolve SSL_get0_next_proto_negotiated

也许这些警告与崩溃有关?

这里也是appcrash信息:

  Fault Module Name:    ntdll.dll
  Fault Module Version: 6.1.7601.17725
  Fault Module Timestamp:   4ec49b8f
  Exception Code:   c0000005
  Exception Offset: 000332a0
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:    1033
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

平台信息:Windows 7 x64,使用 GCC 构建的 32 位 Qt 库存

以下是相关代码:

C++

class MapReader : public QQuickImageProvider {
public:
    explicit MapReader() : QQuickImageProvider(QQuickImageProvider::Pixmap, QQmlImageProviderBase::ForceAsynchronousImageLoading) { }

    QPixmap requestPixmap(const QString &id, QSize *size, const QSize &requestedSize) {
        QNetworkAccessManager m;
        Q_UNUSED(requestedSize)
        Q_UNUSED(size)
        QEventLoop loop;
        QObject::connect(&m, SIGNAL(finished(QNetworkReply*)), &loop, SLOT(quit()));
        QNetworkReply * r = m.get(QNetworkRequest(QUrl(id)));
        loop.exec();

        if (r->error()) {
            qDebug() << "Error: " << r->errorString();
            r->deleteLater();
            return QPixmap();
        }

        QPixmap p;
        p.loadFromData(r->readAll());
        r->deleteLater();
        return p;
    }    
};

QML

Rectangle {
    id: root
    width: 360
    height: 360

    property string url : 'image://map/http://maps.googleapis.com/maps/api/staticmap?center=' + n + ',' + e + '&zoom=' + zoom.value + '&size=' + width  + "x" + height + '&maptype=satellite'
    property real n : 48.858222
    property real e : 2.2945

    Timer {
        id: t
        repeat: false
        interval: 100
        running: false
        onTriggered: {
            placeholder.source = root.url
        }
    }

    function refresh() { if (t.running) t.restart(); else t.start() }

    Image {
        id: placeholder
        anchors.fill: parent
    }

    MouseArea {
        anchors.fill: parent

        onClicked: {
            var xOffset = (mouseX / width - 0.5) * (360 / Math.pow(2, zoom.value))
            var yOffset = (mouseY / height - 0.5) * (360 / Math.pow(2, zoom.value))

            console.log(xOffset + " " + yOffset)

            root.n = root.n - yOffset
            root.e = root.e + xOffset
            root.refresh()
        }
    }

    Slider {
        id: zoom
        value: 17
        maximumValue: 21
        minimumValue: 1
        stepSize: 1
        x: 80
        y: parent.height - 25
        width: parent.width - 90

        onValueChanged: root.refresh()
    }
}

【问题讨论】:

  • 递归事件循环是无穷无尽的麻烦源。使用图像提供程序的设计基本上被破坏了。你需要用其他方式来做。
  • @KubaOber - 这提出了一个问题,如果网络访问管理器本质上是异步的并且图像提供者需要以相同的方法请求和返回图像,那么人们将如何使用它来实现图像提供者?
  • QQuickImageProvater API 从根本上被破坏了 :( 有一个丑陋的解决方法,QML 引擎在单独的线程中运行提供程序。
  • 你真的需要在调试器下运行它,看看它到底在哪里崩溃。你提供的“appcrash 信息”是没有用的。

标签: c++ qt crash qml qtquick2


【解决方案1】:

问题出在您的图像提供程序类中。我不确定确切的位置,但它就在那里,因为没有它我无法重现崩溃。我之所以能够这么说,是因为在您的情况下,图像提供程序完全没有必要——QtQuick Image 元素将接受并使用 Google API url 源。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-12-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多