Skip to content
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

Service re-registration leads to increasingly large allocs #896

Open
jimmo opened this issue Dec 22, 2020 · 0 comments
Open

Service re-registration leads to increasingly large allocs #896

jimmo opened this issue Dec 22, 2020 · 0 comments
Assignees

Comments

@jimmo
Copy link

jimmo commented Dec 22, 2020

hi! I'm from the MicroPython project. We provide a Python API around NimBLE, but we've run into a problem due to the fact that the Python program can be restarted without the board restarting. We do what we can (via the public API) to shutdown and reset NimBLE across these "program resets" but I've just noticed an issue that during service registration we see increasingly large calls to malloc() from ble_gatts_count_cfg().

The cause is that although we call gatts_reset(), nothing resets ble_hs_max_services ble_hs_max_attrs and ble_hs_max_client_configs. I am currently working around this by resetting them from our code.

I think the feature we really want is a global "nimble_reset" function that clears/resets all global variables (i.e. zeros .bss variables and resets .data variables back to default values, as if the board has just restarted).

I understand this is a bit of a weird requirement -- not many implementors of NimBLE would need to register services more than once per hard reset, but would appreciate any suggestions. Thanks!

jimmo added a commit to jimmo/micropython that referenced this issue Dec 22, 2020
Without this fix, each time service registration happened it would do an increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
dpgeorge pushed a commit to micropython/micropython that referenced this issue Dec 22, 2020
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Jan 26, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Jan 26, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Jan 26, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Jan 26, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Jan 27, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Jan 27, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Jan 29, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Jan 31, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Feb 1, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Feb 1, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Feb 15, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Feb 15, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Mar 10, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Mar 10, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Mar 10, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Apr 9, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
pfalcon pushed a commit to pfalcon/pycopy that referenced this issue Apr 18, 2021
Without this fix, each time service registration happened it would do an
increasingly large malloc() for service state.

See apache/mynewt-nimble#896.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants