ESP32 Forum

Got an CORRUPT HEAP abort and tried to drill down with lst file.
At the end this is the way where it happens:

• invoke_abort
  abort
  split_if_necessary
  multi_heap_malloc
  get_all_caps ret = multi_heap_malloc(heap->heap, size);
  heap_caps_malloc_default r=heap_caps_malloc( size, MALLOC_CAP_DEFAULT | MALLOC_CAP_INTERNAL );
  _malloc_r return heap_caps_malloc_default( size );
  0x 4000beaf ??
  lmsg.arg = (void *)osi_malloc(arg_len);
  esp_ble_gatts_app_register

1. In my application a BLE Server is created like this, and it works fine Get these events during creating server

• Event:ESP_GATTS_REG_EVT gatts_if:4
  Event:ESP_GATTS_CREATE_EVT gatts_if:4
  Event:ESP_GATTS_START_EVT gatts_if:4
  Event:ESP_GATTS_ADD_CHAR_EVT gatts_if:4
  Event:ESP_GATTS_ADD_CHAR_DESCR_EVT gatts_if:4
  Event:ESP_GATTS_REG_EVT gatts_if:5
  Event:ESP_GATTS_CREATE_EVT gatts_if:5
  Event:ESP_GATTS_START_EVT gatts_if:5
  Event:ESP_GATTS_ADD_CHAR_EVT gatts_if:5
  Event:ESP_GATTS_ADD_CHAR_EVT gatts_if:5
  Event:ESP_GAP_BLE_ADV_START_COMPLETE_EVT
  Event:ESP_GAP_BLE_ADV_DATA_RAW_SET_COMPLETE_EVT

2. Next this service should be removed with esp_ble_gatts_app_unregister and there I get these events:

• Event:ESP_GATTS_UNREG_EVT gatts_if:4
  Event:ESP_GATTS_UNREG_EVT gatts_if:5

3. and then created again (with other char for example). Thats where the bug comes up
For testing, steps are called manually, means there is a lot of time between. So there should be no overlapping of (internal)free and malloc

Is step2 is not sufficient or is there any other hint, what to do ?

I've changed step 2 to

• delete service
  on ESP_GATTS_DELETE_EVT unreg app
  on ESP_GATTS_UNREG_EVT
  - deinit and disable Bluedroid
  - deinit and disable Controller
  - init and enable Controller again
  - init and enable Bluedroid
  - register callbacks for gap, gatts and gattc
  - set local MTU

Still get the corrupt heap

A corrupt heap can be a horrible thing. There are some good diagnostic aids for tracking it down documented here:

http://esp-idf.readthedocs.io/en/latest ... debug.html

If it were me, I'd slowly step through the code and intersperse heap corruption detection checks. Ideally there will be a sequence of statements where the heap is good and then some statements later, the heap has been corrupted. We can then perform sub-division and keep drilling down to spot it. Heap corruption can occur for a number of reasons, the two biggest being:

1. We allocate X bytes of storage but write X+Y of data
2. We allocate X bytes of storage, release the storage and then continue to write to the old storage location

It is always possible that ESP-IDF code is corrupting the heap but it is also possible that user code is responsible. First task is to try and determine when it is being corrupted which may provide guidance as to which of the possibilities is the culprit.

@kolban,
thanks for your comment.
It directed me to right documents and at the end , the bug was on my side.