本文介绍了我的QNX / BB10 C ++应用程序崩溃,一个简单的C ++对象似乎已损坏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个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 ++对象似乎已损坏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

05-29 13:53
查看更多