Bluetooth: A2DP: Fix NULL pointer references issue

[lylezhu2012]

The opposite logic is used to determine if a pointer is valid.

Correct the judgement logic.

Fixes #74728.

[jhedberg]

I think the more worrying thing here is that it seems this code was never tested. Otherwise you'd get NULL dereferences immediately.

[Thalley]

I think the more worrying thing here is that it seems this code was never tested. Otherwise you'd get NULL dereferences immediately.

Indeed. BSIM can't test BREDR right? So for classic we should probably start implementing/requesting unit tests at the very least.

[jhedberg]

BSIM can't test BREDR right? So for classic we should probably start implementing/requesting unit tests at the very least.

Yep. One alternative to explore for runtime testing, would be to use the BlueZ btvirt tool to create multiple virtual dual-mode controllers. btvirt makes the controllers "reachable" to each other, so you'd start one qemu instance per controller and then set one as connectable + discoverable and another to then try to connect to the first one and do some A2DP or other Bluetooth Classic protocol communication between them. That's a rather big effort of its own, but if @lylezhu2012 or anyone else with a stake in Bluetooth Classic is interested it might be the shortest path to get some runtime testing in our CI.

[Thalley]

BSIM can't test BREDR right? So for classic we should probably start implementing/requesting unit tests at the very least.

Yep. One alternative to explore for runtime testing, would be to use the BlueZ btvirt tool to create multiple virtual dual-mode controllers. btvirt makes the controllers "reachable" to each other, so you'd start one qemu instance per controller and then set one as connectable + discoverable and another to then try to connect to the first one and do some A2DP or other Bluetooth Classic protocol communication between them. That's a rather big effort of its own, but if @lylezhu2012 or anyone else with a stake in Bluetooth Classic is interested it might be the shortest path to get some runtime testing in our CI.

Cool

We should at least look for some useful approach for testing classic in CI, otherwise it'll just end up broken periodically.

Adding support for it in BSIM would probably be ideal - Then we could also start working towards some dual-mode tests, but I assume that's also a significant effort right @aescolar ?

[lylezhu2012]

BSIM can't test BREDR right? So for classic we should probably start implementing/requesting unit tests at the very least.

Yep. One alternative to explore for runtime testing, would be to use the BlueZ btvirt tool to create multiple virtual dual-mode controllers. btvirt makes the controllers "reachable" to each other, so you'd start one qemu instance per controller and then set one as connectable + discoverable and another to then try to connect to the first one and do some A2DP or other Bluetooth Classic protocol communication between them. That's a rather big effort of its own, but if @lylezhu2012 or anyone else with a stake in Bluetooth Classic is interested it might be the shortest path to get some runtime testing in our CI.

Yes. In the short term, I hope to enable pts test, which is what I am doing. In this way, we can ensure the most basic quality. Then, we plan implement BSIM-like testing based on twister.

[aescolar]

Then we could also start working towards some dual-mode tests, but I assume that's also a significant effort right @aescolar ?

Correct. Classic BT is not currently supported, and there is no plans for it, and I doubt Nordic will have a motivation to pay for that development :)