-
Notifications
You must be signed in to change notification settings - Fork 13.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User exception (panic/abort/assert) after random number of successful requests #6811
Comments
I've also just found that using host as script.google.com in https://github.com/esp8266/Arduino/blob/919c7535631d60e085f87d2b4c72d05a88651eed/libraries/ESP8266WiFi/examples/BearSSL_Validation/BearSSL_Validation.ino causes the exact same error. |
@NiallRees can you try something simple on your end? I'm traveling for a few days and may not be able to run anything on real HW for a while. Can you make: Arduino/cores/esp8266/StackThunk.cpp Line 39 in 919c753
into
and re-try the connections with your app or the Validation example? That would add an additional 1K to the available stack for BearSSL and narrow it down to a stack overflow issue vs. something else. |
@earlephilhower thank you so much! It's working absolutely fine now. I've seen you've increased the stack size in previous releases, is the problem that certificates are getting larger and larger? |
Could you add the following lines to your sketch to figure out exactly how much bigger the stack usage was? First, add
at the top of your sketch, then after connect:
It's not really a certificate size thing (they're processed byte-by-byte as they come in), but it could be a new encryption mode which is using more stack than others we've seen. Thx! |
BSSL stack: 5636 |
Thanks, @NiallRees . Unfortunately, that's actually saying that the required stack is smaller than the default value (5636 vs. 5748) which gives more questions than answers. Is that # stable through multiple connections? Do you see some fluctuations between runs/connections? My thinking is that there might be some ISR called which requires more than (5748-5636 = 112 bytes) of space, but it's not always called so you have the case where the unmodified code works most times, but when that ISR happens the SYS needs >112 bytes of stack... The alternative is that it's not the stack, but memory corruption somewhere (possible, but we do run valgrind on the host to check for stuff like that). By increasing the stack you don't avoid the corruption, but the corruption ends up in some part of the stack that's not used anyway so it's invisible to the app. |
What part is using so much stack? |
@TD-er it's the BSSL stack, different from the SYS or CONT. There's a stack thunk mechanism involved to dynamically allocate and destroy it. |
Ah, OK, didn't know that. |
@NiallRees thanks for the detailed info. I was able to reproduce it using the BSSL_Validation.ino like you said. Sometimes it worked fine w/o any changes, but other times it would crash. The issue is sometimes the max BSSL stack usage is 5636, which is fine, but other times I get that it's used 5828 which is past the stack end. I'll bump up the stack allocation and tweak the validation exmable to dump the BSSL stack as well. |
Fixes esp8266#6811 which found an issue where connecting to scripts.google.com would *occasionally* cause a crash. On inspection, it was found that up to 5828 bytes of stack were used once in a while, so expand the stack to 5900 bytes to cover this case plus a little extra.
Fixes #6811 which found an issue where connecting to scripts.google.com would *occasionally* cause a crash. On inspection, it was found that up to 5828 bytes of stack were used once in a while, so expand the stack to 5900 bytes to cover this case plus a little extra.
Hi @earlephilhower , I'm a total newbie and I just started learning Arduino using nodemcu esp8266. Do you have details on how to fix this?
|
FYI I have (had) the same problem. I am connected to my local MQTT-broker, but close this connection for a short connection to Pushover (to send messages to my phone). This led to crash after a number of connects (in the range 2 to 20-something). So far: And no crashes yet. //#define _stackSize (5900/4) |
@Teddyz, you're saying you saw I think |
I had this BSSL-check in my program running today: #include <StackThunk.h>
uint16_t max_stack_usage = 0;
...
// In loop
if (now() - prev1s >= 1UL) {
//checkDelay("", 1);
prev1s = now();
relay (4); // update relay
yield();
//checkDelay("do every 1 seconds", 2);
uint16_t stack_usage = stack_thunk_get_max_usage();
static uint16_t usage_increases = 0;
if ( stack_usage > max_stack_usage ) {
Serial.printf("%02d BSSL stack: %d -> %d \n", ++usage_increases, max_stack_usage, stack_usage);
max_stack_usage = stack_usage;
}
return;
}
01 BSSL stack: 0 -> 4484 Soft WDT Crash after > 100 connections to api.pushover.net/1/messages.json. Plus the same number of connections to my local MQTT-broker. 01 BSSL stack: 0 -> 4516 So far no crash. The Soft WDT reset had the explanation below. I do not understand where it went wrong, but I also do not think it is related to this problem.
|
i had problem with resets on boot after "Refreshing JWT" but since the mod everything works fine for 2 days now. |
Changing BSSL stack to 6648 was not enough for me, BSSL was timing out. |
I have similar issue on this thread causes The error was due to the conflict between I did not change the default stack size defined as No more crashes have occurred after I adjusted the buffer size. Before, sometimes it would go through, and sometimes it wouldn't when |
Basic Infos
Platform
Settings in IDE
Problem Description
I'm using the WiFiClientSecure client and sometimes during connection, other times after a request, User exception (panic/abort/assert) is raised and the board restarts. If it successfully makes a request, it crashes on the next attempt.
I've attached a decoded stack trace along with heap memory debug. Would really appreciate some help with this.
MCVE Sketch (WiFi creds left blank)
Debug Messages
Decoded
The text was updated successfully, but these errors were encountered: