Skip to content

BLE: Fix GattServer callbacks not being copied to GattServer instance of the service #14084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 5, 2021

Conversation

paul-szczepanek-arm
Copy link
Member

Summary of changes

When adding services to GattServer, they are allocated new memory and any changes made to original characteristics will not take effect after adding them - all operations must be performed on the GattServer version. This is correct behaviour.

At the same time we are requesting the user keeps hold of the old characteristics, wasting space for no reason. This is because gattserver makes references to the original characteristics. There is no need for this.

This PR copies the values being used through reference (authorisation callbacks) and updates the docs to remove the requirement to keep the characteristics after adding. The behaviour does not change and existing code will run the same way but it is now allowed to free the characteristics used to build the service and thus free up memory.

Impact of changes

Migration actions required

Documentation

none


Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

@ithinuel


@@ -941,7 +964,8 @@ ble_error_t GattServer::reset(ble::GattServer* server)
currentHandle = 0;
cccd_cnt = 0;

_auth_char_count = 0;
_auth_callbacks_count = 0;
_auth_callbacks = nullptr;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

memory is freed elsewhere (line 954)

@mergify mergify bot added the needs: work label Dec 23, 2020
Copy link
Member

@ithinuel ithinuel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite the nitpicking on class/pointer to bool auto conversion in if/while statements, it LGTM.

GattCharacteristic *auth_char = getInstance().get_auth_char(handle);
if (auth_char && auth_char->isReadAuthorizationEnabled()) {
char_auth_callback *auth_cb = getInstance().get_auth_callback(handle);
if (auth_cb && auth_cb->read_cb) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a bit fan of pointer to bool coersion.
I'd prefer a

Suggested change
if (auth_cb && auth_cb->read_cb) {
if ((auth_cb != NULL) && (auth_cb->read_cb != NULL)) {

GattAuthCallbackReply_t ret = auth_char->authorizeRead(&read_auth_params);
if (ret != AUTH_CALLBACK_REPLY_SUCCESS) {
return ret & 0xFF;
auth_cb->read_cb.call(&read_auth_params);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what FunctionPointerWithContext does, but the test above followed by this by-value access to the member is a bit confusing.

@ciarmcom ciarmcom added the release-type: patch Indentifies a PR as containing just a patch label Dec 23, 2020
@ciarmcom
Copy link
Member

@paul-szczepanek-arm, thank you for your changes.
@ithinuel @ARMmbed/mbed-os-connectivity @ARMmbed/mbed-os-maintainers please review.

@ciarmcom ciarmcom requested review from ithinuel and a team December 23, 2020 12:30
@adbridge
Copy link
Contributor

CI started

@mergify mergify bot removed the needs: review label Dec 23, 2020
@mbed-ci
Copy link

mbed-ci commented Dec 23, 2020

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️
jenkins-ci/mbed-os-ci_cmake-example-test ✔️

@paul-szczepanek-arm
Copy link
Member Author

There's something wrong with CI, the failed test is complaining about errors in mbed tools?

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 4, 2021

There's something wrong with CI, the failed test is complaining about errors in mbed tools?

This fixes the issue #14108. This PR needs to be rebased to the latest master.

@paul-szczepanek-arm
Copy link
Member Author

thanks, rebased

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 4, 2021

Ci restarted

@mbed-ci
Copy link

mbed-ci commented Jan 4, 2021

Jenkins CI Test : ❌ FAILED

Build Number: 2 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️

@paul-szczepanek-arm
Copy link
Member Author

Build failing because of unrelated issue causing link error on ARM:
#14112

@jamesbeyond
Copy link
Contributor

Build failing because of unrelated issue causing link error on ARM:
#14112

Hi, @paul-szczepanek-arm
The failure is caused by recent(31th Dec) changes happened to socket example :
https://github.com/ARMmbed/mbed-os-example-sockets/commits/development
The failure is consistent and reproduceable across both mbed-OS nighty and PR tests

@paul-szczepanek-arm
Copy link
Member Author

Build failing because of unrelated issue causing link error on ARM:
#14112

Hi, @paul-szczepanek-arm
The failure is caused by recent(31th Dec) changes happened to socket example :
https://github.com/ARMmbed/mbed-os-example-sockets/commits/development
The failure is consistent and reproduceable across both mbed-OS nighty and PR tests

That was the socket defaulting to tls and is already fixed.

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 5, 2021

CI restarted

@mbed-ci
Copy link

mbed-ci commented Jan 5, 2021

Jenkins CI Test : ✔️ SUCCESS

Build Number: 3 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM ✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️
jenkins-ci/mbed-os-ci_cmake-example-test ✔️

@0xc0170 0xc0170 merged commit ce825bc into ARMmbed:master Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants