complications with connection to local Bluetooth

[Blitzor DDD]

It says:

The inferior stopped because it received a signal from OS.
Signal name: SIGSEGV.
Signal meaning: Segmentation fault.

it crashes on the line socket.connectToService(address, QBluetoothUuid(QBluetoothUuid::SerialPort));

[anda_skoa]

When a program crashes on a Unix system (assuming that is one due to SIGSEV), then it usually generates a core dump file, which can be analyized with a debugger.

Or the program can be run in the debugger and it will then know the last trace of function calls at the time of the crash.

That line itself doesn't look like it could crash (no pointer or uninitialized data present), so it could be inside the connectToService() method.

But make sure that "this" is a valid object.

Cheers,
_

[Blitzor DDD]

Why it does not crash, when I run it on Android device?

[anda_skoa]

There can be many reasons.

For example if "this" is no longer a valid object then the memory "socket" points to could still be accessible depending on the operating system's memory managment.

Which is why the stack trace is important.
If it crashes in some internal function inside connectToService() it could be a bug in the platform's implementation for that function that is not in the implementation of the other platform.
But if the crash is in application code, then it might just be hidden on one of the platforms.

Very often, when crashes seemingly happen in library code it is actually the application code that is wrong.
When access to non-heap members fails, like in this case, it is often that the "this" object has already been destroyed.

Cheers,
_

[Blitzor DDD]

Look, ich hab noch nicht verstanded..
Why "this" can not be a valid object? If I firslty just push the button, which calls slot try_to_connect_to_local_address after I run my program?
And "this" must be valid!
oder ist das falsch?

Grüße,

[anda_skoa]

It is likely that "this" is valid, but it can happen that a method is called on an object that has already been deleted.

Then the method will often execute nicely but can crash if access to certain members or in a certain way can no longer be done properly.

For example, the following works nicely for me, despite the object having been deleted

#include <iostream>
#include <string>
 
using namespace std;
 
class Test
{
public:
    Test() : m_int(0) {}
 
    void noMemberAccess()
    {
        cout << "noMemberAccess called" << endl;
    }
 
    void intReadAccess()
    {
        cout << "intReadAccess called: value=" << m_int << endl;
    }
 
    void stringWriteAccess()
    {
        m_string = "foo";
        cout << "stringWriteAccess called:" << m_string << endl;
    }
 
    int m_int;
    string m_string;
};
 
int main()
{
    Test *t = new Test;
 
    t->noMemberAccess();
    t->intReadAccess();
    t->stringWriteAccess();
 
    cout << "deleting object" << endl;
 
    delete t;
 
    t->noMemberAccess();
    t->intReadAccess();
    t->stringWriteAccess();
 
    return 0;
}

#include <iostream>
#include <string>

using namespace std;

class Test
{
public:
    Test() : m_int(0) {}

    void noMemberAccess()
    {
        cout << "noMemberAccess called" << endl;
    }

    void intReadAccess()
    {
        cout << "intReadAccess called: value=" << m_int << endl;
    }

    void stringWriteAccess()
    {
        m_string = "foo";
        cout << "stringWriteAccess called:" << m_string << endl;
    }

    int m_int;
    string m_string;
};

int main()
{
    Test *t = new Test;

    t->noMemberAccess();
    t->intReadAccess();
    t->stringWriteAccess();

    cout << "deleting object" << endl;

    delete t;

    t->noMemberAccess();
    t->intReadAccess();
    t->stringWriteAccess();

    return 0;
}

To copy to clipboard, switch view to plain text mode 

Obvioulsy the memory pointed to by "t" is still OK enough, but that is not in any way guaranteed.
So different systems or different loads on the same system, etc. can lead to different outcomes. It might work nicely but it could crash.

The result is often weird stack traces, like QString::length() appearing to crash, while actually QString::length() was called on a QString member variable of a destroyed object.

Hence it is important to see how deep the stack trace goes into the method you are experiencing a crash with, but also important to verify that the object the call is coming from is still valid,

Cheers,
_

[Blitzor DDD]

wow!
it is very unexpectedly for me!)
Thank you for full explanation.