-
Notifications
You must be signed in to change notification settings - Fork 90
Fix ESP8266 crash in logging macros due to __FUNCTION__ in flash #371
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
Conversation
|
|
||
| /** | ||
| * ESP8266 specific configurations | ||
| * Note: __FUNCTION__ is stored in flash on ESP8266, so we use FPSTR() to handle it properly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment doesn't reflect the code below anymore as __FUNCTION__ was removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a commit in PR #373 to cleanup
| // error | ||
| #if ASYNCWEBSERVER_LOG_LEVEL >= ASYNC_WS_LOG_ERROR | ||
| #define async_ws_log_e(format, ...) ets_printf(String(F("E async_ws %s() %d: " format)).c_str(), __FUNCTION__, __LINE__, ##__VA_ARGS__); | ||
| #define async_ws_log_e(format, ...) Serial.printf_P(PSTR("E async_ws %d: " format "\n"), __LINE__, ##__VA_ARGS__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it useful to print the line number without the function name? We'll be searching on the error text either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw that but agree with if because it quickly helps determine if the prints are in sync or not with the code we are reading. That's usually the first thing I look when users are giving some logs or stack... I first make sure the code they run is really the code they thunk they run.
On ESP8266, the
__FUNCTION__macro returns a pointer to flash memory. The logging macros pass this directly toets_printfwith%s, which expects a RAM pointer. This causes a LoadStoreError (Exception 3) crash whenever anyasync_ws_log_*macro is invoked.Replace
ets_printfwithSerial.printf_PusingPSTR()for the format string, and remove__FUNCTION__since it cannot be safely used with printf on ESP8266.This bug has existed since the logging refactoring in commit e323ae1 (2025-09-10). Any ESP8266 code path that triggers a log message (e.g., queue overflow, allocation failure) would crash.