typo in the code, might explain why it locks up after a while

[dannutu]

Hi Andreas and thanks for sharing this example. I appreciate it's a few years old and as you already explained in a few of the other closed issues you don't have the time to check it anymore but this issue is really trivial to fix and requires next to no time from your side - change just one character in the code :)

I played with your example on an esp32 and it works for a few hours and then it just freezes without any obvious reason. mosquitto would log "Socket error on client <client_id>, disconnecting" multiple times and nothing would work from that point on until the esp32 would be reset, when it would suddenly work again, and the cycle would repeat. (and no, it's not related to bad wifi signal, I checked it on the router)

Looking at your code I believe this is a typo and you probably meant to write "i < 10", not "i > 10":
for (int i = 0; i > 10; i++) {
MQTTclient.loop();
delay(100);
}

Because of this typo the loop()'s are never actually executed. Not sure how much of a problem this would create if you're not actually expecting any mqtt messages in the client (like in this one) but I still think it wouldn't hurt to change "i > 10" to "i < 10", just in case it helps. I just reflashed the esp32 with the updated version and I'll leave it overnight to see if it makes any difference to the stability.

[dannutu]

Nope, it didn't help with stability, it ran for about 5 hours and then it got stuck again.
I'll try leaving it connected to the USB serial console, hopefully the Serial.print debug instructions will point to where exactly in the program it gets stuck.

[digamesystems]

I know this is an old post, but I think I found the problem.

The current code in the repo has a memory leak in:

BLEAdvertisedDeviceCallbacks().

class MyAdvertisedDeviceCallbacks: public BLEAdvertisedDeviceCallbacks {
    /**
        Called for each advertising BLE server.
    */
    void onResult(BLEAdvertisedDevice advertisedDevice) {
      Serial.print("BLE Advertised Device found: ");
      Serial.println(advertisedDevice.toString().c_str());
      pServerAddress = new BLEAddress(advertisedDevice.getAddress());

      bool known = false;
      for (int i = 0; i < (sizeof(knownAddresses) / sizeof(knownAddresses[0])); i++) {
        if (strcmp(pServerAddress->toString().c_str(), knownAddresses[i].c_str()) == 0) known = true;
      }
...

The pointer pServerAddress is allocated, but the memory is never freed up. To fix, delete the BLEAddress you create after you are done using it.

      delete pServerAddress; 

This fixed it for me and it's been running solid for over a day now.

Thanks again, Andreas!

[SensorsIot]

Thank you for the info. Could you create a pull request or indicate where you placed the statement? Then I would not need to test again ;-)

[digamesystems]

Hi Andreas.

No problem!

I never forked the whole repo, 'just grabbed some bits out I needed. Here's my version of the class in question:

class MyAdvertisedDeviceCallbacks: public BLEAdvertisedDeviceCallbacks {
  
  void onResult(BLEAdvertisedDevice advertisedDevice) {
    
   /******** This grabs some memory ********/
    pServerAddress = new BLEAddress(advertisedDevice.getAddress());
    
    bool known = false;
    
    for (int i = 0; i < numKnownAddresses; i++) {
      if (strcmp(pServerAddress->toString().c_str(), knownAddresses[i][1].c_str()) == 0) {
        known = true;

        deviceFound = true;     
        digitalWrite(RED_LED, HIGH);
         
        if (advertisedDevice.getRSSI() > rssiThreshold) deviceClose = true;
        else deviceClose = false;
  
        if (deviceClose){
          if (knownAddresses[i][2] == "false") { // We haven't seen him yet this scan...
            knownAddresses[i][2] = "true";
            digitalWrite(GREEN_LED, HIGH);
            Serial.println("=============== Known device found! =============== ");
            Serial.print("NAME: ");
            Serial.println(advertisedDevice.getName().c_str());
            Serial.print("RSSI: ");
            Serial.println(advertisedDevice.getRSSI());
            Serial.print("ADDRESS: ");
            Serial.println(pServerAddress->toString().c_str());
          }
          //pBLEScan->stop();
        }   
      }
    }
    /******** This releases the memory when we're done. ********/
    delete pServerAddress;     
  }  
       
};

In debugging this, I learned a useful function for tracking down this kind of thing:

int freeHeapBefore = ESP.getFreeHeap();

/* Do some stuff that allocates and deallocates memory.... */

int freeHeapAfter  = ESP.getFreeHeap();

Serial.println("Free Heap Delta: ");
Serial.println( freeHeapBefore - freeHeapAfter);

If code like this lives in your main loop you can check if the free heap is shrinking over time.

[MertGurdogann]

Hi @digamesystems.
I've looked at your explanation, most people in Mr. Andreas' Polar Receiver example pClient->connect(pAddress); stuck in section. Does your suggestion solve this problem?

nkolban/esp32-snippets#874
In the link I left, the issue is still not resolved, some say that they are successfully connected. I am also getting the same error.

Best Regards.

[SensorsIot]

I added the line to the proximity sketch. Thank you.

[digamesystems]

Hi @MertGurdogann

I'm sorry, but my fix probably wont help much with your "connect" issue. I just fixed a memory leak in the routine that scans advertising messages. (My application never connects to a BLE device; I'm using the advertising messages as part of a location tracking application where I have known tags scattered about an area.)

I took a look at the thread you referenced above, though.

Wow! There are a lot of eyes on this issue! That suggests smarter minds than my own should squish this bug soon.

Just two hours ago someone suggested they might have a library that could help: nkolban/esp32-snippets#874 (comment)

Regards,
John.

[digamesystems]

@SensorsIot No problem! Happy to be of some use after all the great stuff you've given us. :)

…

On 9/6/2021 1:08 AM, SensorsIOT wrote: I added the line to the proximity sketch. Thank you. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUY6QD33JM3YOOSV5VUGLUARZGFANCNFSM4ZDHPYMQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.