问题描述
我正在开发一个QNX / Blackberry 10应用程序。我的应用程序最近开始崩溃。插入跟踪语句导致我相信崩溃发生在以下情况。
I'm working on a QNX / Blackberry 10 application. My application has recently begun to crash. Inserting trace statements has led me to believe the crash is occurring in the following situation.
我的客户端应用程序调用内部函数,传递它对C ++类对象的引用。传递的C ++类如下所示:
My client app calls an internal function, passing it a reference to a C++ class object. The passed C++ class looks like the following:
class ALPeerData
{
public:
ALPeerData ();
virtual ~ALPeerData ();
int _peerId;
ALModelType _modelType;
std::wstring _computerName;
std::wstring _uuidDevice;
. . .
};
当我访问 _computerName
或 _uuidDevice
成员变量后,被调用的函数返回它。被调用函数中的跟踪显示 ALPeerData
对象成员变量是预期的。因此,函数中的 _computerName.size()
返回类似于10的合理值,但在客户端应用程序中调用时返回约23 MB的大小。 ALPeerData
对象似乎已损坏。
The crash occurs when I access the _computerName
or _uuidDevice
member variables after the called function returns it. Traces within the called function show the ALPeerData
object member variables are as expected. Thus, _computerName.size()
within the function returns something reasonable like 10, but returns a size of about 23 MB when called in the client app. The ALPeerData
object seems to be corrupted.
我在这里列出qcc -V输出文档的原因: p>
I list here the qcc -V output for documentation reasons:
user:~$ qcc -V
cc: targets available in /home/bbndk/host_10_3_1_12/linux/x86/etc/qcc:
4.6.3,gcc_ntoarmv7le_gpp
4.6.3,gcc_ntox86_gpp
4.6.3,gcc_ntoarmv7le_cpp-ne
4.6.3,gcc_ntoarmv7le_cpp
4.6.3,gcc_ntox86 (default)
4.6.3,gcc_ntoarmv7le
4.6.3,gcc_ntox86_cpp-ne
4.6.3,gcc_ntox86_cpp
4.8.3,gcc_ntoarmv7le_gpp
4.8.3,gcc_ntox86_gpp
4.8.3,gcc_ntoarmv7le_cpp-ne
4.8.3,gcc_ntoarmv7le_cpp
4.8.3,gcc_ntox86
4.8.3,gcc_ntoarmv7le
4.8.3,gcc_ntox86_cpp-ne
4.8.3,gcc_ntox86_cpp
user:~$
我的 ALPeerData
类?
推荐答案
结果是QNX有问题在其gcc / qcc编译器中实现C ++标准。
It turns out that QNX has a problem with its implementation of the C++ standard in its gcc / qcc compiler.
在ALPeerData的析构函数声明中的'virtual'关键字不是必要和多余的,源自它。
The 'virtual' keyword in ALPeerData's destructor declaration is not necessary and redundant, as no class in my application derives from it. This should not make any difference -- I should be allowed to specify 'virtual' for any destructor I please.
在现实中,为<$ c $指定'virtual'是非常有用的。 c> ALPeerData 的析构函数会导致生成不正确的二进制代码。因此,访问成员变量会导致垃圾结果。
In reality, specifying 'virtual' for ALPeerData
's destructor causes incorrect binary code to be generated. Thus, accessing the member variables leads to garbage results.
当我删除冗余的'virtual'关键字时,崩溃消失了。
When I removed the redundant 'virtual' keyword, the crash vanished.
这不是我第一次遇到QNX的C ++虚拟析构函数的实现的问题。第一次可以在中看到。
This is not the first time I encountered a problem with QNX's implementation of C++ virtual destructors. The first time can be seen in a previous StackOverflow post of mine.
底线:需要谨慎对待QNX的虚拟析构函数的实现。
这篇关于我的QNX / BB10 C ++应用程序崩溃,一个简单的C ++对象似乎已损坏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!