Steam timeout callback error code 0

[itsosmx]

Hello, Yesterday I was working on my system and everything was working properly. Today, for some reason everything is broken. After doing a lot of searching everywhere and removing a lot of the features I added Yesterday that were working without any problem, I found that the problem is in the stream callback, If I modify anything in the database, the esp32... Reboot, and if I don't do anything, this message is printed in the console

the error when updating anything

13:07:18.043 -> Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
13:07:18.043 -> 
13:07:18.043 -> Core  1 register dump:
13:07:18.043 -> PC      : 0x400ed967  PS      : 0x00060d30  A0      : 0x800eda90  A1      : 0x3ffdc7f0  
13:07:18.043 -> A2      : 0x3ffdc854  A3      : 0x00000000  A4      : 0x3ffdc8c4  A5      : 0x3ffdc8cc  
13:07:18.075 -> A6      : 0x3ffdc8dc  A7      : 0x00000000  A8      : 0x00000000  A9      : 0xcccccccd  
13:07:18.075 -> A10     : 0x00000000  A11     : 0x00000000  A12     : 0x00000000  A13     : 0x0000ff00  
13:07:18.075 -> A14     : 0x00ff0000  A15     : 0xff000000  SAR     : 0x00000020  EXCCAUSE: 0x0000001c  
13:07:18.075 -> EXCVADDR: 0x00000002  LBEG    : 0x4008b215  LEND    : 0x4008b225  LCOUNT  : 0xffffffff  
13:07:18.075 -> 
13:07:18.075 -> 
13:07:18.075 -> Backtrace: 0x400ed964:0x3ffdc7f0 0x400eda8d:0x3ffdc830 0x400d3286:0x3ffdc850 0x400f1681:0x3ffdc910 0x400f2775:0x3ffdca10 0x400f438d:0x3ffdca60 0x400f44b4:0x3ffdcbe0 0x400f46b2:0x3ffdcc00 0x400f47cd:0x3ffdccb0 0x400f483d:0x3ffdccd0 0x400f4874:0x3ffdccf0
13:07:18.107 -> 
13:07:18.107 -> 
13:07:18.107 -> 
13:07:18.107 -> 
13:07:18.107 -> ELF file SHA256: 7fd4a60068b15842
13:07:18.107 -> 
13:07:18.236 -> Rebooting...
13:07:18.236 -> ets Jul 29 2019 12:21:46
13:07:18.236 -> 
13:07:18.236 -> rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
13:07:18.268 -> configsip: 0, SPIWP:0xee
13:07:18.268 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

code setup func

  if (!Firebase.RTDB.beginStream(&stream, "/switch")) log("Stream error", stream.errorReason().c_str());
  Firebase.RTDB.setStreamCallback(&stream, SwitchesStreamCallback, StreamTimeoutCallback);

  if (!Firebase.RTDB.beginStream(&stream2, "/conditions")) log("Stream error", stream.errorReason().c_str());
  Firebase.RTDB.setStreamCallback(&stream2, ConditionsStreamCallback, CTimeoutCallback);

  if (!Firebase.RTDB.beginStream(&stream3, "/move")) log("Stream error", stream.errorReason().c_str());
  Firebase.RTDB.setStreamCallback(&stream3, MoveStreamCallback, MTimeoutCallback);

callback for switch

void SwitchesStreamCallback(FirebaseStream data) {
  FirebaseJson callbackJson; = data.jsonObject();
  json.iteratorBegin();
  FirebaseJson::IteratorValue callbackJsonRecord = json.valueAt(0);

  uint8_t pin = record.key.toInt();
  uint8_t value = record.value.toInt();
  if (pin != 0) {
    pinMode(pin, OUTPUT);
    digitalWrite(pin, value);
    log(pin, " Switch Updated ", record.value);
  }
  json.iteratorEnd();
}

void StreamTimeoutCallback(bool timeout) {
  if (timeout)
    log("stream timed out, resuming...\n");

  if (!stream.httpConnected())
    Serial.printf("error code: %d, reason: %s\n\n", stream.httpCode(), stream.errorReason().c_str());
}

[mobizt]

I cannot help you to debug or find the cause of your problem.

The Exception was unhandled error is because of dangling pointer issue as you are trying to use the object that point by the pointer that was destroyed or not existed.

The memory allocation failure due to out of memory can cause the dangling pointer as the pointer is still point to unallocated memory.

And it should be note that when you define class object, variable and calling the function inside the callback function, they use stack memory.

Then you should avoid the stack overflow problem by moving all codes in the callback to run in the main loop function instead.

Serial printing in the callback function also use stack and you should remove from production.

Anyway, you should take care of memory usage (heap) and memory leaks too which all can cause wdt reset crash.

[mobizt]

The data under the stream path should also keep small as possible.