Stack Smashing protect Failure - getCharacteristics()

[arsab]

Trying to connect:
https://forum.mysensors.org/topic/6951/nrf5-multi-sensor-board-12-14

Configured appropriate service and characteristics:
static BLEUUID serviceMPUUID("6e400001-b5a3-f393-e0a9-e50e24dcca9e");
static BLEUUID charMP_BMUUID("6e400004-b5a3-f393-e0a9-e50e24dcca9e");

then when getting characteristic pointer:
pMP_BMRemoteCharacteristic = pMPRemoteService->getCharacteristic(charMP_BMUUID);

faced "Stack Smashing protect Failure"

Looks to be solved by:
nkolban/esp32-snippets#863

"Hi,
probably its because you are using arduino library with bug (maybe more than 1), in this library its already fixed:
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/BLERemoteService.cpp#L129"

effectively changing "uint16_t count = 1;" looks to be resolved, my program then works.

[chegewara]

Stack Smashing protect Failure
Task's stack is too small. You have 2 options:

1. increase task's stack
2. try to make some local variables (most likely some arrays) a global variables to initialize in heap instead of on stack

[mwild1]

No, this is not related to stack size. This is a bug in the BLE library that took me some time to track down (frustratingly it seems it is already fixed in another repo).

The problem is that the function at https://github.com/espressif/arduino-esp32/blob/master/libraries/BLE/src/BLERemoteService.cpp#L159 allocates space for a single result on the stack:

	esp_gattc_char_elem_t result;

But then passes a count of 10 to esp_ble_gattc_get_all_char(). The documentation is not great for this function, but it appears this may cause it to copy up to 10 results into the array provided by the result pointer. However there is only space allocated for a single result, so multiple characteristics will overflow and trigger the stack smashing protection.

	uint16_t count = 10;  // this value is used as in parameter that allows to search max 10 chars with the same uuid
		esp_gatt_status_t status = ::esp_ble_gattc_get_all_char(
			getClient()->getGattcIf(),
			getClient()->getConnId(),
			m_startHandle,
			m_endHandle,
			&result,
			&count,
			offset
);

Since it is called in a loop already, I assume simply setting count = 1 is an acceptable fix.

[atanisoft]

@mwild1 definitely looks like a possible solution, feel free to submit a PR for this after testing.

[chegewara]

Yes, this seems it is that bug. I still forgot it is not fixed in arduino.

[arsab]

I assume we can now close this one since the fix is now repository:
#3082
a12d609