Sometimes crashes occur after calling deinit(false)

[pikkaru]

I found this phenomenon when I was testing with version 1.4.2 at first, but the same phenomenon seems to occur when I test with 2.1.0 with modified code to be able to compile in that
environment. I use ESP32 Dev Module and Arduino Core for ESP32 v2.0.15.

Here is the part of my code(The ~ part omits code that is irrelevant to the BLE process):

          ~~~~~~~~~~~
          NimBLEDevice::init(ble_name);
          ~~~~~~~~~~~
          pStartupConfigServer = NimBLEDevice::createServer();
          pStartupConfigServer->setCallbacks(new ConfigServerCallbacks());
          NimBLEService *pService = pStartupConfigServer->createService(CONFIGSERVICE_UUID);
          pTxconfigCharacteristic = pService->createCharacteristic(
                        CONFIGCHARACTERISTIC_UUID_TX,
                        NIMBLE_PROPERTY::NOTIFY
                      );
          NimBLECharacteristic * pRxconfigCharacteristic = pService->createCharacteristic(
                        CONFIGCHARACTERISTIC_UUID_RX,
                        NIMBLE_PROPERTY::WRITE
                      );
          pRxconfigCharacteristic->setCallbacks(new ConfigChrCallbacks());
          pService->start();
          pConfigServer->getAdvertising()->start();
          bool ble_conf_test_flag = true;
          while (ble_conf_test_flag == true){
            if (Serial.available()>0){
              uart_command = Serial.readStringUntil('\n');
              if (uart_command == "exit"){
                ble_conf_test_flag = false;
              }
            }
            if (deviceConnected && !oldDeviceConnected) {
                oldDeviceConnected = deviceConnected;
            }
            delay(10);
          }
          pConfigServer->getAdvertising()->stop();
          NimBLEDevice::deinit(false);
          ~~~~~~~~~~~
        }

and this is the error message:

18:15:41.475 -> Guru Meditation Error: Core  0 panic'ed (InstrFetchProhibited). Exception was unhandled.
18:15:41.475 -> 
18:15:41.475 -> Core  0 register dump:
18:15:41.475 -> PC      : 0x00000000  PS      : 0x00060230  A0      : 0x8009996b  A1      : 0x3ffd3c80  
18:15:41.475 -> A2      : 0x3ffdff64  A3      : 0x00000001  A4      : 0x00000001  A5      : 0x0000abb5  
18:15:41.521 -> A6      : 0x00000000  A7      : 0x00000001  A8      : 0x800f80bc  A9      : 0x3ffd3c60  
18:15:41.521 -> A10     : 0x3ffc87f0  A11     : 0x3ffc87f0  A12     : 0x3ffca5b8  A13     : 0x00060223  
18:15:41.521 -> A14     : 0x00060220  A15     : 0x00000001  SAR     : 0x00000013  EXCCAUSE: 0x00000014  
18:15:41.521 -> EXCVADDR: 0x00000000  LBEG    : 0x400924f8  LEND    : 0x4009250e  LCOUNT  : 0x00000000  
18:15:41.521 -> 
18:15:41.521 -> 
18:15:41.521 -> Backtrace: 0xfffffffd:0x3ffd3c80 0x40099968:0x3ffd3ca0
18:15:41.521 -> 
18:15:41.521 -> 
18:15:41.521 -> 
18:15:41.521 -> 
18:15:41.521 -> ELF file SHA256: 66693fbd39183016
18:15:41.521 -> 
18:15:41.848 -> Rebooting...
18:15:41.848 -> ets Jul 29 2019 12:21:46
18:15:41.848 -> 
18:15:41.848 -> rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
18:15:41.848 -> configsip: 0, SPIWP:0xee
18:15:41.848 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
18:15:41.848 -> mode:DIO, clock div:1
18:15:41.848 -> load:0x3fff0030,len:1344
18:15:41.848 -> load:0x40078000,len:13964
18:15:41.848 -> load:0x40080400,len:3600
18:15:41.848 -> entry 0x400805f0

I would like to add that I remember this happening very rarely in 1.4.1.
Calling the delay function between deinit and stop seems to alleviate the problem, but I cannot determine if this is the correct solution.

[h2zero]

From the look of that backtrace something is accessing a nullptr. I suggest to remove the call to stop and just let the deinit take care of it.

[pikkaru]

Thank you for your response. Currently the problem appears to be resolved. I would appreciate it if you could point me to a sample code that includes deinit, if you have one, as I have not been able to find it.

[h2zero]

The code you have there is a good example already. There is nothing special about deinit to show an example of really, the only thing to know is that is will stop all BLE activity and release the resources until init is called again.

[thekurtovic]

@pikkaru You could add checks on the return values from init and deinit.