0

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?

Moshe Rubin
  • 1,944
  • 1
  • 17
  • 37

1 Answers1

0

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.

Moshe Rubin
  • 1,944
  • 1
  • 17
  • 37
  • I don't understand. Why you declare destructor as virtual if your main class is not derived from other. – Oleg Gopkolov Feb 02 '16 at 04:15
  • I added the 'virtual' keyword to help another developer who derives from ALPeerData in the future. Making it virtual avoids the common bug of the base destructor not getting called. According to the official C++ specification, this is completely benign. See http://stackoverflow.com/questions/300986/when-should-you-not-use-virtual-destructors for a discussion on making all destructors virtual. Another theoretical scenario: Suppose a derived class _had_ been derived from ALPeerData, but was later removed from the code during refactoring, without removing the virtual keyword from ALPeerData. – Moshe Rubin Feb 03 '16 at 08:44