Unknown Exception is not beeing caught in trycatch-Block (Bluetooth Low Energy, ServiceDetailsDiscovery)

SpaceToon

@J-Hilk Yes, It is initialized with a nullptr, and when I click on reset on the GUI (or when the function startServiceDetailsDiscovery is called, I actually make the following check, which I did not copy in the code in my above post due to clarity):

    if(selectedService)
    {
        delete selectedService;
        selectedService = nullptr;
    }

JonB

@SpaceToon
OK, not a lot more helpful in the further trace, other than knowing it happens during QMdiArea::viewMode().

But I think the Level #4 line is telling you that you have source code and the error emanated when Line #160 of BluetoothModel.cpp was executing. May not help, but you might look at that line of code for clues?

SpaceToon

@JonB said in Unknown Exception is not beeing caught in trycatch-Block (Bluetooth Low Energy, ServiceDetailsDiscovery):

But I think the Level #4 line is telling you that you have source code and the error emanated when Line #160 of BluetoothModel.cpp was executing. May not help, but you might look at that line of code for clues?

Thank you. Well, that's exactly this line: try { selectedService->discoverDetails(); }

What I don't understand: Okay, that only 4 services are found and displayed instead of 5 is an error. I still don't know why this error occurs sometimes (and I cannot specifically reproduce the error. I keep connecting to the device until the error occurs at some point). Since I don't need the missing service, it doesn't matter at first that it is missing. But the other service I use, the Nordic UART Service, does exist and is being found. Then when I try to get the details from this service, my application crashes. If I could catch the error, then I would simply start the search for the services again automatically, because then it will find all 5 services again and the application runs correctly. But because of the crash, this possibility is missing. But I thank you guys for the help anyway.

JonB

@SpaceToon
I notice that everything you are using --- including the actual Qt libraries --- is compiled (MSVC) with debug.

Have you tried recompiling/linking for Release mode? There is a "reasonable" chance the crash will not happen there... !

P.S.
Have you tried commenting out your:

connect(selectedService, &QLowEnergyService::stateChanged, this, &TestApp::serviceDetailsDiscoveredSlot);

Does the crash still happen during selectedService->discoverDetails()? If not, did you ever show us your TestApp::serviceDetailsDiscoveredSlot()?

KH-219Design

@SpaceToon thank you for posting the screenshot of the crash stack.

If this were my project and I were debugging, my normal behavior is to focus on the last (top-most) part of the stack where I recognize function names that I myself authored. In the present case, that would be BluetoothModel.cpp line 160. (This echoes what @JonB said earlier, so I know you have done this already.)

However, it is possible that the bug is in Qt code and not in BluetoothModel.cpp.

It is always advantageous, however, to do everything possible to rule out a bug in one's own code, because it is generally a quite larger effort to both: (1) diagnose a bug in Qt itself, and (2) patch a bug in Qt itself (or wait for a patch).

If I focus on the Qt part of the stack, however, then the crash appears to happen in QLowEnergyController::connected (very top, "Level 1" or frame 1 of the stack).

What seems weird to me is that QLowEnergyController::connected is a signal. And I cannot (given my lack of deeper access to your debugger scenario) superficially see how execution could logically proceed from BluetoothModel::startServiceDetailsDiscovery ("Level 4" of stack) into QLowEnergyController::connected ("Level 3" of stack).

You might want to look at any code of yours that references that signal (QLowEnergyController::connected).

If this is a Qt bug (specific to Qt BLE on the WinRT system), then you might try to reproduce it by building and running the "Bluetooth Low Energy Scanner Example":

If you try connecting to your peripheral from the official Qt sample app and you encounter a crash when doing so, then I think https://bugreports.qt.io would accept that.

kshegunov

You're probably overwriting a pointer or double-deleting an object.

selectedService = lowEnergyController->createServiceObject(serviceUuid, this);

This looks quite fishy. What happens in your model if I run through that twice and then run through the removal code (assuming there's one) twice ... I'd've expected you keep the objects in a list or something ...

SpaceToon

@KH-219Design Thank you, I will try that approach.

@kshegunov : Well, everytime, this function is called, I check if the selectedService Object already exists, nd if so, I delete it. So the follwoing function is called, when the user selects a Service in the GUI and clicks on Dsicover service details:

  if(selectedService)
    {
        delete selectedService;
        selectedService = nullptr;
    }

    selectedService = lowEnergyController->createServiceObject(serviceUuid, this);
    if(!selectedService){
       qDebug() << "Service not found"
        return;
    }

 connect(selectedService, &QLowEnergyService::stateChanged, this, &BluetoothModel::serviceDetailsDiscoveredSlot);
    try {
        selectedService->discoverDetails();
    }  catch (std::exception &e) {
        qDebug() << "error, try it again!" << e.what();
    }

So as you can see here, When the user clicks on the button more than one time (for no reason), there is always a check that makes sure, that the pointer to the selecteService obejct is not overwritten. Is that what you meant by your question?

JonB

@SpaceToon
Looks OK to me.

In a previous post I asked you:

Have you tried commenting out your:
connect(selectedService, &QLowEnergyService::stateChanged, this, &TestApp::serviceDetailsDiscoveredSlot);

If not, did you ever show us your TestApp::serviceDetailsDiscoveredSlot()?

I may be barking up the wrong tree, but is there any reason you don't want to try this or show your slot which is called during the crashy code? Perhaps you know that this is 100% irrelevant?

SpaceToon

@JonB Sorry, I saw your post, but I forgot to answer here. Well, if I comment this line, then nothing happens after the service discovery. I think this is not relevant, but here is the serviceDetailsDiscoveredSlot:

void BluetoothModel::serviceDetailsDiscoveredSlot(QLowEnergyService::ServiceState newState)
{
    if (newState == QLowEnergyService::ServiceDiscovered)
    {
        characteristicsList = selectedService->characteristics();
        for (const QLowEnergyCharacteristic &characteristic : characteristicsList)
        {
            emit characteristicDiscoveredSignal(characteristic);
        }
}

And the characteristicDiscoveredSignal only tells the UI to show the discovered characteristics on the GUI.

JonB

@SpaceToon said in Unknown Exception is not beeing caught in trycatch-Block (Bluetooth Low Energy, ServiceDetailsDiscovery):

Well, if I comment this line, then nothing happens after the service discovery

I don't understand what that means. Your crash then goes away if this code not executed?? characteristicsList = selectedService->characteristics(); --- could selectedService == nullptr/inavlid? "And the characteristicDiscoveredSignal only tells the UI to show the discovered characteristics on the GUI` --- and could that cause a crash?

As I said, maybe I'm barking up the wrong tree from the traceback, your call, just trying to see where a "crash" could be....

SpaceToon

@JonB
Ohh sorry, I was using a older version of my code and was commenting out the wrong line ;d
I will try it now with the correct version. I think this will take time ro reproduce this, but I will report here when I'm done.

EDIT: That was fast. The applications till crashes, although I commented out this line. And I do not think that my characteristicDiscoveredSignal caused a crash because I set up a breakpoint there and it is never reached.

SpaceToon

When I set a breakpoint at selectedService->discoverDetails(); and when I want to jump in the qt function discoverDetails() while debugging, it does not work. I want to now at which point exactly the error appears. Is there another way to debug this qt-own-function?

JonB

@SpaceToon
From your earlier stack trace, it looks like you are linking against debug versions of the Qt libraries, but there is a lack of line numbers. Did you compile Qt for debug, and can the debugger see/know the location of the corresponding Qt source files?

SpaceToon

@JonB Yes, I did.

@KH-219Design : Thank you very much for your suggestion, for using the lowenergy example from Qt. I did this and the same error occurs there! For this reason, I copied the following code from there and paste it in my .cpp file:

        connect(controller, QOverload<QLowEnergyController::Error>::of(&QLowEnergyController::error),
                this, &Device::errorReceived);

And in the Slot, I had:

void BluetoothModel::errorReceived(QLowEnergyController::Error /*error*/)
{
    qWarning() << "Error: " << controller->errorString();
}

And after a couple of times of connecting and disconneting, finally the error occurs. My errorReceived said:

Error:  "Remote device closed the connection"

And in the debugger, I had:

But my "Problem" was, that the LED on my device, that indactes that it is connected (it is a blue LED), was still on, so I did not knew before, that the connection was closed.
So, it has to do with my device and not with my code. Now, knowing where the error occurs, I can reestablish the connection to the device, before the user can do anything on he GUI, that leads to the crash.

@All: Thank you very much for your help here, love this community :)

KH-219Design

@SpaceToon said in Unknown Exception is not beeing caught in trycatch-Block (Bluetooth Low Energy, ServiceDetailsDiscovery):

@KH-219Design : Thank you very much for your suggestion, for using the lowenergy example from Qt. I did this and the same error occurs there! For this reason, I copied the following code from there and paste it in my .cpp file

@SpaceToon I'm truly happy to hear you are able to make forward progress on this!

This year marks the first year that I have ventured into BLE using Qt, and I have hit some minor hiccups myself. That is why your post caught my attention in the first place. However, I am working on Android and you are on Windows, which have very different backend/underlying BLE system stacks. So based on the difference in operating systems, I was doubtful if anything I learned would really translate directly here.

Your watershed moment about QLowEnergyController::Error prompted me to go look at my code again to see what I am doing in case of QLowEnergyController::Error. I noticed that in my slot I have this comment:

        // The Qt API for QLowEnergyController has some confusing
        // overlap/ambiguity.  When we get "ConnectionError" I would EXPECT that
        // the signal QLowEnergyController::disconnected would also be
        // forthcoming. But it seems (by observation) that this is not how it
        // works.  So we have to treat BOTH the disconnected signal and the
        // error signal as signs of a disconnection.

... so maybe you and I did actually run into a very similar pitfall after all!

It would be great to know if there is some null-reference bug in Qt BLE itself, but neither you nor I may have time to investigate that further. Since we both seem to have worked around our respective pain points, may we carry on and each deliver a successful project!

You also asked:

Did you compile Qt for debug, and can the debugger see/know the location of the corresponding Qt source files?

Which is a very useful tactic, which I have done many times on Linux Qt.

I just read some of this: https://stackoverflow.com/questions/5571098/how-can-i-make-msvc-debugger-step-into-qt-library-source-code-again/5576414

Which refers to compiling the QtCored5.dll DLL(s) for oneself. (This is essentially analogous to how I do it on Linux, but building Qt from source is usually several hours of effort on the first time... and I'm not talking about the additional potential hours of just letting the compiler run!)

Maybe someone else in this thread has had personal experience with debugging into Qt source files on Microsoft Windows. Or maybe that could be a new thread!