QGC crashes after disconnecting USB [Release V5.0]

[diablo1281]

I can't add the tag - please mark this as Release V5.0.

Clearly mention the version you're testing and your operating system.
QGC 93ee76f
Windows 11 24H2

Describe your hardware setup (telemetry, flight controller, firmware).
Holybro Pixhawk 6X connected by USB cable.
Firmware: PX4 1.15.4

Include detailed steps to reproduce the issue.
After physically disconnecting the USB cable, while the connection in QGC is still open, I get an error message about access to the COM port.
Connection is still open (but with state disconnected), so I want to terminate it by clicking Disconnect. After clicking the button, the QGC window disappears, but the process continues working in the background. To launch QGC again, it needs to be manually closed via Task Manager as there can't be two instances running simultaneously.

On the sidenote, it takes quite some time to launch every time.

Add screenshots or screen recordings where possible — they really help!

Nagrywanie.2025-05-15.235106.mp4

[HTRamsey]

I'm gonna guess this is via autoconnect? Trying to open/close a composite USB gets stuck in a qt function for quite a while. If you manually set to the correct port I think this doesn't happen right?

Edit: Nevermind it happens regardless

[diablo1281]

Just checked, it happens regardless if it's AutoConnect or set Link

[hyeonseung89]

Even if you check with version v5.0rc, the same symptoms appear not only in USB serial connections but also in UDP and TCP connections.

Can you please refer to this part and check?

critical: FactValueGrid::_initForNewVehicle: vehicle is NULL (default:FactValueGrid::_initForNewVehicle:66)

[HTRamsey]

@DonLakeFlyer looks like we may still have some issues after #12795

I tried this commit right before that FactValueGrid change and it works fine

[HTRamsey]

@diablo1281 @hyeonseung89 we'll have to wait for Don to look at it, but as far as I can tell there's nothing wrong with the comms code itself. The main thread just dies after _initForNewVehicle

Edit: Also yeah windows takes forever to start the first time and I'm not sure why yet

[HTRamsey]

@DonLakeFlyer nevermind I tracked it down to #12536 I think, the artifact from ec7a337 works but the one from cd7128c does not. Although that PR doesn't look like it changes anything that would cause this... I will try to figure it out, @rubenp02 might need you to check it out too if you get a chance

[rubenp02]

I don't have the chance to look into it in detail right now but if it's that PR, it's probably either an issue with the QML (likely not the new code itself but rather an existing bug in the backend that it exposes) or this. Edit: It may also be the map item restoring logic getting triggered when it shoudn't. Since the PR has a few commits I think this will be very quick to narrow down with a bisect.

I'll try to check this out later today but absolutely feel free to revert if you want.