8

昨天我遇到了痛苦,这让我沮丧了 24 小时。问题归结为随机发生的意外崩溃。更复杂的是,调试报告也有绝对随机的模式。更复杂的是,所有调试跟踪都导致随机Qt 源或本地 DLL,即每次都证明问题不在我这边。

这里有一些这样可爱的报告的例子:

Program received signal SIGSEGV, Segmentation fault.
0x0000000077864324 in ntdll!RtlAppendStringToString () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0 0x0000000077864324 in ntdll!RtlAppendStringToString () from C:\Windows\system32\ntdll.dll
#1 0x000000002efc0230 in ?? ()
#2 0x0000000002070005 in ?? ()
#3 0x000000002efc0000 in ?? ()
#4 0x000000007787969f in ntdll!RtlIsValidHandle () from C:\Windows\system32\ntdll.dll
#5 0x0000000000000000 in ?? ()

warning: HEAP: Free Heap block 307e5950 modified at 307e59c0 after it was freed
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000778bf0b2 in ntdll!ExpInterlockedPopEntrySListFault16 () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0 0x00000000778bf0b2 in ntdll!ExpInterlockedPopEntrySListFault16 () from C:\Windows\system32\ntdll.dll
#1 0x000000007786fd34 in ntdll!RtlIsValidHandle () from C:\Windows\system32\ntdll.dll
#2 0x0000000077910d20 in ntdll!RtlGetLastNtStatus () from C:\Windows\system32\ntdll.dll
#3 0x00000000307e5950 in ?? ()
#4 0x00000000307e59c0 in ?? ()
#5 0x00000000ffffffff in ?? ()
#6 0x0000000000220f10 in ?? ()
#7 0x0000000077712d60 in WaitForMultipleObjectsEx () from C:\Windows\system32\kernel32.dll
#8 0x0000000000000000 in ?? ()

Program received signal SIGSEGV, Segmentation fault.
0x0000000000a9678a in QBasicAtomicInt::ref (this=0x8) at ../../include/QtCore/../../../qt-src/src/corelib/arch/qatomic_x86_64.h:121
121 : "memory");
(gdb) bt
#0 0x0000000000a9678a in QBasicAtomicInt::ref (this=0x8) at ../../include/QtCore/../../../qt-src/src/corelib/arch/qatomic_x86_64.h:121
#1 0x00000000009df08e in QVariant::QVariant (this=0x21e4d0, p=...) at d:/Distributions/qt-src/src/corelib/kernel/qvariant.cpp:1426
#2 0x0000000000b4dde9 in QList<QVariant>::value (this=0x323bd480, i=1) at ../../include/QtCore/../../../qt-src/src/corelib/tools/qlist.h:666
#3 0x00000000009ccff7 in QObject::property (this=0x3067e900,
name=0xa9d042a <QCDEStyle::drawPrimitive(QStyle::PrimitiveElement, QStyleOption const*, QPainter*, QWidget const*) const::pts5+650> "_q_stylerect")
at d:/Distributions/qt-src/src/corelib/kernel/qobject.cpp:3742
#4 0x0000000000000000 in ?? ()

正如您所看到的,这些东西非常讨厌,它没有提供任何有用的信息。但是,有一件事我没有注意。这是编译期间的一个奇怪的警告,也很难用眼睛捕捉到:

In file included from d:/Libraries/x64/MinGW-w64/4.7.2/Qt/4.8.4/include/QtCore/qsharedpointer.h:50:0,
                 from d:/Libraries/x64/MinGW-w64/4.7.2/Qt/4.8.4/include/QtCore/QSharedPointer:1,
                 from ../../../../source/libraries/Project/sources/Method.hpp:4,
                 from ../../../../source/libraries/Project/sources/Slot.hpp:4,
                 from ../../../../source/libraries/Project/sources/Slot.cpp:1:
d:/Libraries/x64/MinGW-w64/4.7.2/Qt/4.8.4/include/QtCore/qsharedpointer_impl.h: In instantiation of 'static void QtSharedPointer::ExternalRefCount<T>::deref(QtSharedPointer::ExternalRefCount<T>::Data*, T*) [with T = Project::Method::Private; QtSharedPointer::ExternalRefCount<T>::Data = QtSharedPointer::ExternalRefCountData]':
d:/Libraries/x64/MinGW-w64/4.7.2/Qt/4.8.4/include/QtCore/qsharedpointer_impl.h:336:11:   required from 'void QtSharedPointer::ExternalRefCount<T>::deref() [with T = Project::Method::Private]'
d:/Libraries/x64/MinGW-w64/4.7.2/Qt/4.8.4/include/QtCore/qsharedpointer_impl.h:401:38:   required from 'QtSharedPointer::ExternalRefCount<T>::~ExternalRefCount() [with T = Project::Method::Private]'
d:/Libraries/x64/MinGW-w64/4.7.2/Qt/4.8.4/include/QtCore/qsharedpointer_impl.h:466:7:   required from here
d:/Libraries/x64/MinGW-w64/4.7.2/Qt/4.8.4/include/QtCore/qsharedpointer_impl.h:342:21: warning: possible problem detected in invocation of delete operator: [enabled by default]
d:/Libraries/x64/MinGW-w64/4.7.2/Qt/4.8.4/include/QtCore/qsharedpointer_impl.h:337:28: warning: 'value' has incomplete type [enabled by default]

实际上,我只是将这个警告作为最后的手段,因为在如此绝望地寻找错误的过程中,代码已经感染了字面上的日志死亡。

仔细阅读后,我想起了,例如,如果使用std::unique_ptrstd::scoped_ptr用于Pimpl - 肯定应该提供析构函数,否则代码甚至无法编译。但是,我还记得它std::shared_ptr不关心析构函数并且没有它也可以正常工作。这也是我没有注意这个奇怪警告的另一个原因。长话短说,当我添加析构函数时,这种随机崩溃停止了。看起来 QtQSharedPointerstd::shared_ptr. 我想如果 Qt 开发人员将此警告转化为错误会更好,因为这样的调试马拉松根本不值得花时间、精力和精力

我的问题是:

  1. 有什么问题QSharedPointer?为什么析构函数如此重要?
  2. 为什么在没有析构函数的情况下会发生崩溃?这些对象(使用Pimpl + QSharedPointer)是在堆栈上创建的,并且在它们死后没有其他对象可以访问它们。然而,坠机发生在他们死​​后的某个随机时间段内。
  3. 有没有人遇到过这样的问题?请分享你的经验。
  4. Qt 中是否还有其他类似的陷阱——我必须知道这些陷阱以确保将来保持安全?

希望这些问题和我的一般帖子能帮助其他人避免我过去 24 小时去过的地狱。

4

2 回答 2

3

该问题已在 Qt 5 中解决,请参阅https://codereview.qt-project.org/#change,26974

编译器调用错误的析构函数或假设不同的内存布局可能会导致某种内存损坏。我想说编译器应该针对这个问题给出错误而不是警告。

于 2013-03-18T07:31:27.227 回答
1

您会遇到类似的问题std::unique_ptr,如果与不完整的类型一起使用,也会导致破坏的析构函数。当然,修复非常简单 - 我为该类声明了一个构造函数,然后在实现文件中将其定义为

MyClass::~MyClass() = default;

这是一个问题std::unique_ptr但不是问题的原因std::shared_ptr是析构函数是前者类型的一部分,但它是后者的成员。

于 2015-11-03T13:54:04.503 回答