QList<const QBluetoothDeviceInfo* declaration / definiton problem

[JonB]

@AnneRanch

• Do you still have line reading RemoteDeviceInfo.append(&info); in your code? "Yes" or "No"?
• If "Yes" can you please, please, please, please show where info is declared?

That's it, 2 questions, 10 seconds to answer.

[Anonymous_Banned275]

@JonB YES
but sorry my class FULL CODE cannot be posted here it exceeds the allowed size.
You just have to take my word that "info" DOES contains data- as the debug output shows.

I suspect I MAY be running the class constructor multiple times....

Here is what I get when I attempt to debug here

void SettingsDialog::on_applyButton_11_clicked()
{
text = " DEBUG TEST Direct access ";
text += RemoteDeviceInfo.at(0)->name();
qDebug()<< text;
return; debug here

[J.Hilk]

@AnneRanch said in QList<const QBluetoothDeviceInfo* declaration / definiton problem:

I suspect I MAY be running the class constructor multiple times....

thats literally impossible.
The constructor is the only "function " that can not be called manually.

You may have multiple instances of a class that may or may not shadow each other, hard to tell without the full class but this error message/ debug output shows that your BluetoothDeviceInfo object is invalid/uninitialized or already destroyed.

Like previously suspected.

[JonB]

@AnneRanch said in QList<const QBluetoothDeviceInfo* declaration / definiton problem:

@JonB YES
but sorry my class FULL CODE cannot be posted here it exceeds the allowed size.

So we know the code still has RemoteDeviceInfo.append(&info);, but we still can't know/be told where info is declared. As you please. I leave it to others to figure better.

[Anonymous_Banned275]

@JonB Would this be OK ?

           if(info.isValid())
            {

            RemoteDeviceInfo.append(&info);
            text = "TEST DIRECT RemoteDeviceInfo.append(&info)";
            text += RemoteDeviceInfo.at(0)->name();
             text += RemoteDeviceInfo.at(0)->name();
             m_ui->plainTextEdit->appendPlainText(text);
            qDebug()<< text;
             qDebug()<< text;
            }
            else
            {
                text = "Failed info - info.isValid()";
                //text += RemoteDeviceInfo.at(0)->name();
                // text += RemoteDeviceInfo.at(0)->name();
                qDebug()<< text;
                 qDebug()<< text;
                 m_ui->plainTextEdit->appendPlainText(text);

            }

[JonB]

@AnneRanch
I can't tell from that from the above fragment. It depends where info is declared. If you would answer that we would know.

[Axel Spoerl]

@AnneRanch
No, because isValid() is irrelevant for the error. It The crash happens in the attempt to access a deleted object. Probably it just goes out of scope after the adding function has returned. This is what everybody tries to explain, and it seems to be hard to believe for you. No matter what you try, it is wrong to store stack-allocated objects in a list member and access them outside their scope. It might even occasionally work, as long as their freed memory remains untouched. But every address sanitizer will scream out a use-after-free exception.

You probably assume that once it’s in the container, the object’s lifetime is bound to that container. Kind of an understandable guess: You stick candy in a box and close it. You expect it stays there. And it does, but it turns foul because it expires in the box. Boom, that’s your crash. If you ask the candy if it’s valid, it may even say yes, although it stinks already.

The right solution I your case is probably to allocate info on the heap with new. Change the list of objects into a list of pointers. Don’t forget to delete the heap allocated objects in the destructor, best with qDeleteAll.

[J.Hilk]

I think the case is pretty clear,

QList<const QBluetoothDeviceInfo* > RemoteDeviceInfo; expects a heap allocated QBluetoothDeviceInfo instance

RemoteDeviceInfo.append(&info); info is a local function scoped stack allocated instance of QBluetoothDeviceInfo instance.

this is a different scoped function

void SettingsDialog::on_applyButton_11_clicked()
{
text = " DEBUG TEST Direct access ";
text += RemoteDeviceInfo.at(0)->name();
qDebug()<< text;
return;

trying to access the now destructed info instance.

Very likely, but we will never know for sure.

[Anonymous_Banned275]

@JonB info is a result of SIGNAL - remote Bluetooth device found.

[Anonymous_Banned275]

@J-Hilk Thanks for confirming the problem.

[Anonymous_Banned275]

@AnneRanch The crash happens in the attempt to access a deleted object. Probably it just goes out of scope after the adding function has returned. This very helpful to know.

[Anonymous_Banned275]

@J-Hilk Many thanks.
Finally something which makes sense.

My mistake - I was just trying to make a copy of "info" for more processing AFTER the device scan is finished , not during the actual scan , which can take almost a full minute to finish.

This is all I know about "info" :

public slots:
void addDevice(const QBluetoothDeviceInfo&);

the slot processes SIGNAL deviceDiscovered

connect(discoveryAgent, SIGNAL(deviceDiscovered(QBluetoothDeviceInfo)),
this, SLOT(addDevice(QBluetoothDeviceInfo)));

If the solution is to put "info" on heap - I do not know how...

however if I can manage to do the desired work on received "info" , while the scan is still not finished,
I may have to put it all into the slot "addDevice". Prefer not to do that.

Cheers

[Anonymous_Banned275]

@AnneRanch An idea - would this work in my application ?
Little advanced for me , but if it would work I would try it.

https://embeddeduse.com/2013/06/29/copied-or-not-copied-arguments-signals-slots/#:~:text=When QMetaObject%3A%3Aactivate creates the command object%2C it stores,order to make the routing of QMetaObject%3A%3Aactivate work.

PS Do I understand it correctly - QT does not have "copy constructor " ?

[Axel Spoerl]

PS Do I understand it correctly - QT does not have "copy constructor " ?

Goodness, no. Of course we have.

[Pl45m4]

@AnneRanch said in QList<const QBluetoothDeviceInfo* declaration / definiton problem:

PS Do I understand it correctly - QT does not have "copy constructor " ?

QObjects don't have. By design, because they have to stay unique.

Think about QObject properties, parent/child, unique identifier (like objectName). If you clone a QObject "one to one", it would cause a big mess and would violate the Qt objecttree / parent-child paradigm, since nothing is unique anymore.
Where should parent of some widget point to, when the parent widget up the object tree was cloned and there are two identical objects now?!

• https://doc.qt.io/qt-6/qobject.html#no-copy-constructor-or-assignment-operator

As mentioned here, a copy c'tor might be declared / implemented in the private section of a class, but is disabled through Q_DISABLE_COPY macro.

• https://doc.qt.io/qt-6/qtclasshelpermacros-proxy.html#Q_DISABLE_COPY

[Anonymous_Banned275]

@J-Hilk Would it be too offensive to ask you to discuss this ?
PS I do not get notified about new posts so it may take a few days before I ;ll read your reply.

[Pl45m4]

@AnneRanch said in QList<const QBluetoothDeviceInfo* declaration / definiton problem:

Would it be too offensive to ask you to discuss this ?

What do you want to discuss? Whether the documentation is lying?
You should not copy QObject.

Everything else, you can copy/use copy c'tors, as it's just standard C++ language and not "Qt".

[Anonymous_Banned275]

@Pl45m4 I was looking for alternative way to make a copy of "info" and I got it solved. CLOSED

[J.Hilk]

@AnneRanch said in QList<const QBluetoothDeviceInfo* declaration / definiton problem:

@J-Hilk Would it be too offensive to ask you to discuss this ?

No, of course not, open discourse is one of the fundamentals of society.

@AnneRanch said in QList<const QBluetoothDeviceInfo* declaration / definiton problem:

@Pl45m4 I was looking for alternative way to make a copy of "info" and I got it solved. CLOSED

I'm curious on what you now ended up using! But for your information I wanted to point out, that you can click on the cog symbol on your opening post and actually select "Mark topic as solved". Alternatively, if you think that one answer in particular solved your issue, you can mark that answer as the correct one.

[Anonymous_Banned275]

@J-Hilk

Currently I just add "info" to struct - class variable and pass "info" to another function for( partial) processing.
I am still not sure if I can process multiple SIGNAL.

Here is a code snippet. PLEASE keep in mind it is a code under construction and I like to keep old code so I do not duplicate and of course I use QDebug extensively.
I am posting the cope "as is " PLEASE do not tell me it does not compile.

       void SettingsDialog::addDevice(const QBluetoothDeviceInfo &info)
       {
           // //*BT_Database_Array[16];
           //HERE
           BT_Database_Array[Array_Index].BT_INFO_Address = info.address();
           BT_Database_Array[Array_Index].INFO_Name = info.name();

           //Array_Index++;
           //#endif
           //temporary copy to QString
           INFO_Name = info.name();
           BT_Database.INFO_Name = info.name();
           BT_Database.INFO_Address = info.address().toString();
           // verify name
           text = " TASK  verify name";
           text += BT_Database_Array[Array_Index].INFO_Name;
#ifdef DEBUG_TASK_SCAN
           qDebug()<< text;
#endif
           text= "Read info ";
           text += " name ";
           text += info.name();
           text += " address ";
           text += info.address().toString();

#ifdef DEBUG_TASK_SCAN
           qDebug()<< text;
#endif

           // verify address
           text = " TASK  verify address";
           text += BT_Database_Array[Array_Index].BT_INFO_Address.toString();
#ifdef DEBUG_TASK_PAIRING
           qDebug()<< text;
#endif

           //Pairing_verify(0);
           Pairing_verify(0, info);