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.

CC2541: stack 1.5.2 potential memory leak

Part Number: CC2541

If the connection has dropped after a GATT message was received and sent through processing, how is the memory deallocation handled?

code reaches `return;` before the GATT_bm_free at the last line of this function. 

Is this a potential leak? 

Code below is from simpleBLECentral.c from 1.5.2 stack projects folder. 

static void simpleBLECentralProcessGATTMsg( gattMsgEvent_t *pMsg )
{
  if ( simpleBLEState != BLE_STATE_CONNECTED )
  {
    // In case a GATT message came after a connection has dropped,
    // ignore the message
    return;
  }
  
  if ( ( pMsg->method == ATT_READ_RSP ) ||
       ( ( pMsg->method == ATT_ERROR_RSP ) &&
         ( pMsg->msg.errorRsp.reqOpcode == ATT_READ_REQ ) ) )
  {
    if ( pMsg->method == ATT_ERROR_RSP )
    {
      uint8 status = pMsg->msg.errorRsp.errCode;
      
      LCD_WRITE_STRING_VALUE( "Read Error", status, 10, HAL_LCD_LINE_1 );
    }
    else
    {
      // After a successful read, display the read value
      uint8 valueRead = pMsg->msg.readRsp.pValue[0];

      LCD_WRITE_STRING_VALUE( "Read rsp:", valueRead, 10, HAL_LCD_LINE_1 );
    }
    
    simpleBLEProcedureInProgress = FALSE;
  }
  else if ( ( pMsg->method == ATT_WRITE_RSP ) ||
       ( ( pMsg->method == ATT_ERROR_RSP ) &&
         ( pMsg->msg.errorRsp.reqOpcode == ATT_WRITE_REQ ) ) )
  {
    
    if ( pMsg->method == ATT_ERROR_RSP == ATT_ERROR_RSP )
    {
      uint8 status = pMsg->msg.errorRsp.errCode;
      
      LCD_WRITE_STRING_VALUE( "Write Error", status, 10, HAL_LCD_LINE_1 );
    }
    else
    {
      // After a succesful write, display the value that was written and increment value
      LCD_WRITE_STRING_VALUE( "Write sent:", simpleBLECharVal++, 10, HAL_LCD_LINE_1 );      
    }
    
    simpleBLEProcedureInProgress = FALSE;    

  }
  else if ( simpleBLEDiscState != BLE_DISC_STATE_IDLE )
  {
    simpleBLEGATTDiscoveryEvent( pMsg );
  }
  
  GATT_bm_free( &pMsg->msg, pMsg->method );
}
  • Hello,

    Thanks for reaching out. It does indeed seems like it might cause a problem. However, to verify this is the case and the system is not freeing the memory somewhere else. I would suggest to monitor the heap. To monitor the heap, you can navigate to the Software Developer's Guide located in the SDK_INSTALL_DIR - Documents -TI_BLE_Software_Developer's_Guide.pdf. In particular, navigate to Section 3.4 Heap Manager and set a preprocessor symbol and reflash the project to enable this.

    BR,

    David.

  • Hi David,

    Thanks for looking into this. 

    Since this is code from the sample project as part of the 1.5.2 SDK, would this be something that TI can verify and suggest whether this is an issue? 

    Thanks,

    Lin

  • Hello Lin,

    I will take a look and come back. Could you please clarify if your current program executing has an issue and what it might be? Have you identified a mem leak?

    BR,

    David.

  • Hi David,

    In my implementation, I do not have a conditional return based on connection state. I was wondering if i should follow this sample code and add it to my code. 

    Therefore, I want to confirm that this is not an issue first before adding it to my code. 

    Did you get any further insight on this? 

    Thanks,

    Lin

  • Hi David,

    I'm seeing the need to check for  whether BLE is connected in my code like shown in the sample code. 

    `if ( simpleBLEState != BLE_STATE_CONNECTED ) { // In case a GATT message came after a connection has dropped, // ignore the message return; }`

    Can you confirm whether the way it's written in the sample code will cause a memory leak or not? 

    Thanks,

    Lin

  • Hello Lin,

    Apologies for the delay here, I was out of office and the msg I had sent apparently was not posted here. I was looking more into the code. The answer relys more on the fact of who owns the pMsg and is responsible for memory de/allocation. In the stack, GATT messages are allocated and owned by the stack, not by the application and therefore will be freed by the stack task. The memory must be freed by the application only when it actually consumes the message contents (using GATT_bm_free()). Once the connection drops, the stack knows the msg was not consumed (parsed my the application) and should free the payload itself when the event is cleaned up.

    Hope this helps.

    David.

  • Hi David, 
    The explanation makes sense, and doesn't make sense at the same time. It makes sense that same process that creates the memory should free the memory that was allocated for it. 
    Just wondering how does the stack knows whether the message was consumed? 

  • Hi Lin,

    In many cases there is a variable attached to the object (e.g. SafeToFree).

    Cheers,

    Marie H