This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352R: Memory leak in simple_broadcaster, bad notes in gap.h

Part Number: CC1352R

Hi there, this isn't actually a question but I wasn't sure where to file a bug report so I'm hoping this helps someone.

I'm using CC13x2_26x2 SDK 4.30.00.54 on a LPSTK-1352R.  The example I'm referencing is in ti/simplelink_cc13x2_26x2_sdk_4_30_00_54/examples/rtos/CC1352R1_LAUNCHXL/ble5stack/simple_broadcaster, although it applies to the other variants of the simple_broadcaster project as well.

simple_broadcaster.c::SimpleBroadcaster_processAdvEvent , receives sbGapAdvEventData_t* pEventData, which contains a void* pBuf.  pBuf is information about an advertising event, with notes available in the source/ti/ble5stack/inc/gap.h header file saying what pBuf should be cast to, and when the receiver is responsible for freeing it.  The notes in gap.h are incorrect.  Specifically the notes for:

  • GAP_EVT_ADV_START_AFTER_ENABLE
  • GAP_EVT_ADV_START_AFTER_ENABLE
  • GAP_EVT_ADV_START
  • GAP_EVT_ADV_END

for which it says "pBuf should be cast to a uint8_t which will contain the advertising handle".  But in reality pBuf points to a uint8_t containing the handle, and the receiver is responsible for freeing it, which SimpleBroadcaster_processAdvEvent doesn't do.  In the simple_broadcaster example this results only in the leak of a single byte, which is why I expect it wasn't noticed.  If you modify the example to start receiving more regular events, you will accumulate leaked memory you start getting allocation failures, and sadness ensues.

It's easy to fix.  Since pBuf always contains a pointer, I patched the leak by conditionally freeing the memory before the return at the end of SimpleBroadcaster_processAdvEvent (line 558 of simple_broadcaster.c).

if(pEventData->pBuf != NULL) {
    ICall_free(pEventData->pBuf);
}

Hope someone finds this useful! And that TI can patch this and update the notes in gap.h before the next SDK release :)