You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@mynewt.apache.org by "Christopher Collins (JIRA)" <ji...@apache.org> on 2017/03/31 22:05:41 UTC

[jira] [Updated] (MYNEWT-702) BLE Host - duplicate connection update entries

     [ 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)