QList<const QBluetoothDeviceInfo* declaration / definiton problem

Axel Spoerl

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

NO , YOU GOT COMPLETE WORKing CODE - after the wrong line is removed.

Untrue. The code posted is not complete. As an example, the class definition starts with Q_OBJECT => Large parts of the declarations are missing in the first fragment.

The second fragment misses the function name, let alone that I don't see where this unnamed function is called and where info is declared, as @JonB asked.

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

Can we get back to the problem

Good idea. Please let's start with what was asked in the beginning: Please post your entire code.

and quit bickering

You don't have to quit bickering all at once. It's totally fine if you fade it out gradually. Or have I misunderstood, and intention was to insult me? Forgiven with a smile! Just have a look at the code of conduct when it suits you.

it is getting tiresome.

Kind of agree.

Anonymous_Banned275

@Axel-Spoerl said in QList<const QBluetoothDeviceInfo* declaration / definiton problem:

The second fragment misses the function name, let alone that I don't see where this unnamed function is called and where info is declared, as @JonB asked.

What is " second fragment " ?
The code contains two functions /methods....

Please be more specific and make use of the requested (!) code and highlight where is " the missing function" problem.

Since the add of info works and is verified in the code - as I repeatedly stated - the source of info is material.
JonB is a nice guy , but this time on wrong track...

Please quit stalling with silly requests for more code - if the code is missing a function it would not compile , duh...

Axel Spoerl

@AnneRanch
To summarize:
@Christian Ehrlicher and @JonB, both truly nice guys, have already told you what the problem is: A pointer to a (probably) stack allocated object info is added to the list RemoteDeviceInfo. When it goes out of scope, the pointer points to a deleted object and things go banana from there. That's the most likely scenario based on the code fragments we see.

In the next post, your call out @JonB, apparently in disagreement with the current findings.

Very interestingly you twist things around, blaming us for not finding whatever you would accept as being the problem:

simple reading thru should have been sufficient to find the problem.

In essence that means:

you know you have a problem
you don't know what it is
you are certain that it's not, what @Christian-Ehrlicher and @JonB (very capable experts) say it is - even though they point at something obviously wrong
on the other hand you claim (and blame), that the code fragments posted must be sufficient for others to figure out your problem

Question: Have you read and understood what we believe could be (part of) the problem?

Three behaviors make it rather hard to dive deeper

consistently ignoring requests to post your entire code (for clarity: entire means all, everything, the whole)
such requests being called "silly", "bickering" (thanks by the way, it has made me laugh out loud)
no feedback on the findings pointed out earlier (like e.g. "Ok, thanks, I will test a different approach and let you know")

"Simple reading thru should have been sufficient to find the problem" => I have just done as you said.
My count is:

3 refusals to co-operate
2 insults
1 thank you
1 apology (none for the insults, though)
0 please

My finding: Communicating with you isn't fun. IMHO, communication is your problem.

Good bye, @AnneRanch

JonB

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

JonB is a nice guy , but this time on wrong track...

Thanks. Why don't you show where info is declared since this remains the candidate for the bad behaviour from what we have seen so far?

Anonymous_Banned275

@JonB I have added some more debugging code , basically bypassing the range loop after the "append".

RemoteDeviceInfo.append(&info);
text = "DIRECT ";
text += RemoteDeviceInfo.at(0)->name();
qDebug()<< text;
qDebug()<< text;
return;

here is the output and contents of RemoteDeviceInfo:

" TASK START setup connect void SettingsDialog::RunPairing()"
"\n TASK addDevice "
" device address ED:C3:50:CA:6D:29"
" device name OontZ Angle solo D29\n"
" TASK pair device name OontZ Angle solo D29\n"
" TASK pairingStatus OontZ Angle solo D292"
"DIRECT OontZ Angle solo D29"

or when Bluetooth "works better" - I have a real issue , outside of this problem

" TASK continue...void SettingsDialog::RunPairing()"
"\n TASK addDevice "
" device address 98:D3:31:F8:39:33"
" device name SPP-CA\n"
" TASK pair device name SPP-CA\n"
" TASK pairingStatus SPP-CA0"
"DIRECT SPP-CA"
"DIRECT SPP-CA"
"\n TASK addDevice "
" device address 98:D3:31:FC:10:73"
" device name HC-05\n"
" TASK pair device name HC-05\n"
" TASK pairingStatus HC-050"
"DIRECT HC-05"
"DIRECT HC-05"
"\n TASK addDevice "
" device address 98:D3:31:FB:12:EB"
" device name HC-05\n"
" TASK pair device name HC-05\n"
" TASK pairingStatus HC-050"
"DIRECT HC-05"
"DIRECT HC-05"

This is how the other "fragment " looks now:

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

however - this morning Bluetooth refuses to cooperate so I'll post the output of the
void SettingsDialog::on_applyButton_11_clicked()
later.

Thanks for not giving up and your continuing interest in resolving this issue, appreciate that very much.
Cheers

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

Screenshot from 2023-05-16 09-22-30.png

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