c++blackberry-10blackberry-qnx

My QNX/BB10 C++ application crashes, a simple C++ object seems to be corrupted

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.

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;
    . . .
};

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.

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:~$

What could be wrong with my ALPeerData class?

Solution

  • It turns out that QNX has a problem with its implementation of the C++ standard in its gcc / qcc compiler.

    The 'virtual' keyword in ALPeerData's destructor declaration is not necessary and is 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.

    In reality, specifying 'virtual' for ALPeerData's destructor causes incorrect binary code to be generated. Thus, accessing the member variables leads to garbage results.

    When I removed the redundant 'virtual' keyword, the crash vanished.

    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.

    The bottom line: one needs to be wary regarding QNX's implementation of virtual destructors.