[
https://issues.apache.org/jira/browse/MYNEWT-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-702:
---------------------------------------
Description:
If the application calls ble_gap_update_params() while an update connection
procedure for that connection is already in progress, the existing entry gets
re-inserted in the ble_gap_update_entries list. This yields a cycle in the
list, causing the host task to loop endlessly during iteration.
More details:
# Host initiates a connection update procedure; creates an entry and inserts it
into the list (ble_gap_update_entries).
# Host attempts to initiate a second connection update procedure for the same
connection. Since an existing update procedure is ongoing, this attempt fails
with a status code of BLE_HS_EALREADY.
# On detecting the error, the ble_gap_update_params() function tries to clean
up (goto done). Part of this cleanup involves freeing the update entry that
got allocated earlier in the function but never got inserted into the list. In
this case, no entry was allocated, but it looks like one was, because the entry
pointer was used to detect a duplicate entry. Consequently, the entry is freed
but never removed from the list!
# The host initiates a third connection update procedure for the same
connection. This time, no duplicate is detected because the entry in the list
got corrupted when it was freed, making its connection handle value
indeterminate. The host allocates the same entry from the pool, populates it,
and inserts it into the list. Now the same entry is in the list twice,
creating a cycle. When the host iterates this list, it loops forever.
was:If the application calls ble_gap_update_params() while an update
connection procedure for that connection is already in progress, the existing
entry gets re-inserted in the ble_gap_update_entries list. This yields a cycle
in the list, causing the host task to loop endlessly during iteration.
> BLE Host - duplicate connection update entries
> ----------------------------------------------
>
> Key: MYNEWT-702
> URL: https://issues.apache.org/jira/browse/MYNEWT-702
> Project: Mynewt
> Issue Type: Bug
> Reporter: Christopher Collins
> Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> If the application calls ble_gap_update_params() while an update connection
> procedure for that connection is already in progress, the existing entry gets
> re-inserted in the ble_gap_update_entries list. This yields a cycle in the
> list, causing the host task to loop endlessly during iteration.
> More details:
> # Host initiates a connection update procedure; creates an entry and inserts
> it into the list (ble_gap_update_entries).
> # Host attempts to initiate a second connection update procedure for the same
> connection. Since an existing update procedure is ongoing, this attempt
> fails with a status code of BLE_HS_EALREADY.
> # On detecting the error, the ble_gap_update_params() function tries to clean
> up (goto done). Part of this cleanup involves freeing the update entry that
> got allocated earlier in the function but never got inserted into the list.
> In this case, no entry was allocated, but it looks like one was, because the
> entry pointer was used to detect a duplicate entry. Consequently, the entry
> is freed but never removed from the list!
> # The host initiates a third connection update procedure for the same
> connection. This time, no duplicate is detected because the entry in the
> list got corrupted when it was freed, making its connection handle value
> indeterminate. The host allocates the same entry from the pool, populates
> it, and inserts it into the list. Now the same entry is in the list twice,
> creating a cycle. When the host iterates this list, it loops forever.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
