-
Notifications
You must be signed in to change notification settings - Fork 390
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
Comments
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
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()
fromble_gatts_count_cfg()
.The cause is that although we call
gatts_reset()
, nothing resetsble_hs_max_services
ble_hs_max_attrs
andble_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!
The text was updated successfully, but these errors were encountered: