Crash when Debug port is Disabled - HTTPClient destructor issue? · Issue #5734 · esp8266/Arduino (original) (raw)

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: [ESP-12]
• Core Version: [just released 2.5.0]
• Development Env: [Arduino IDE 1.8.8]
• Operating System: [Ubuntu]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [dout]
• Flash Size: [4MB]
• lwip Variant: [v2 Lower Memory]
• Reset Method: [ck]
• Flash Frequency: [40Mhz]
• CPU Frequency: [80Mhz]
• Upload Using: [SERIAL]
• Upload Speed: [115200]

Problem Description

In Arduino IDE when Debug port is set to Disabled the ESP8266 reboots (most probably due to a crash) a short while after fetching JSON data via https, parsing it and displaying it on a LED matrix. However, if I set the Debug port to Serial then everything works properly. My application does not use any debugging stuff. It does not even use the Serial stuff, does not call Serial.begin(), nothing of that.

The Debug level is set to None all the time so there's no reason why Debug port setting should be significant or should affect the application in any way, IMHO.

I cannot debug this because when I enable debugging and thus set the Debug port to Serial the issue disappears :-)

EDIT: here's the minimal code:

#include <ESP8266WiFi.h>
#include <ESP8266HTTPClient.h>
#include <WiFiClientSecureBearSSL.h>

const int led = 5;

void setup(void)
{
  pinMode(led, OUTPUT);
  for(byte i=0; i<5; i++) {
    digitalWrite(led, HIGH);
    delay(150);
    digitalWrite(led, LOW);
    delay(200);
  }
  
  WiFi.mode(WIFI_STA);
  // Wait for connection
  while (WiFi.status() != WL_CONNECTED) {
    delay(250);
  }
}

void displayData()
{
  digitalWrite(led, HIGH);
  HTTPClient http;
  std::unique_ptr<BearSSL::WiFiClientSecure>client(new BearSSL::WiFiClientSecure);
  client->setInsecure();
  if (http.begin(*client, "https://jigsaw.w3.org/HTTP/connection.html")) {
    if (http.GET() == 200) {
      String payload = http.getString();
    }
    http.end();
  }
  digitalWrite(led, LOW);
}

void loop(void)
{
  static unsigned long mil = 0;
  if (millis() - mil > 5000) {   
    displayData();
    mil = millis();
  }
}

It's easy to reproduce that mere Debug port setting turns application crashing to not crashing and vice-versa.

It's obvious from the source code above that the LED should blink 5 times at start, then wait for up to 5 seconds, and then blink (when the HTTPS request is invoked) once every five seconds.
What you observe is that immediately after the longer HTTPS blink there's the boot-up fast 5 blinks. That indicates the crash&reboot.

EDIT2: you might notice that my MCVE is an almost verbatim copy of the "BasicHttpsClient" example that is provided with Arduino core. Interesting is that the stock BasicHttpsClient does not crash. What is different? Well, the only interesting difference is the order of HTTPClient and BearSL client instantiation. And that's actually it! If you switch the order of those two lines in the BasicHttpsClient example (so that HTTPClient is first, the std::unique_ptr is second) it will start crashing as well, this time with a stack trace:

[SETUP] WAIT 4...
[SETUP] WAIT 3...
[SETUP] WAIT 2...
[SETUP] WAIT 1...
[HTTPS] begin...
[HTTPS] GET...

Exception (9):
epc1=0x40206cb9 epc2=0x00000000 epc3=0x00000000 excvaddr=0x000001cb depc=0x00000000

>>>stack>>>

ctx: cont
sp: 3ffffd60 end: 3fffffc0 offset: 01a0
3fffff00:  00000001 3ffeecd8 3ffefd14 40202842  
3fffff10:  00000000 00000000 3ffefd14 3ffefa94  
3fffff20:  0000000f 0000000d 000001bb 40001388  
3fffff30:  3ffefe1c 0000001f 00000015 3ffefac4  
3fffff40:  0000000f 00000005 3ffefadc 0000000f  
3fffff50:  00000000 3ffefb14 0000001f 00000011  
3fffff60:  3ffefb3c 0000000f 00000000 00000000  
3fffff70:  00000000 00000000 ffffffff 3fffef00  
3fffff80:  00000000 00000000 00000000 00000000  
3fffff90:  00000000 00000000 3ffeecd8 40202761  
3fffffa0:  3fffdad0 00000000 3ffeed20 402082b4  
3fffffb0:  feefeffe feefeffe 3ffe8508 401009e9  
<<<stack<<<

 ets Jan  8 2013,rst cause:2, boot mode:(1,7)


 ets Jan  8 2013,rst cause:4, boot mode:(1,7)

wdt reset