Skip to content

Conversation

@bdraco
Copy link

@bdraco bdraco commented Jan 22, 2026

On ESP8266, the __FUNCTION__ macro returns a pointer to flash memory. The logging macros pass this directly to ets_printf with %s, which expects a RAM pointer. This causes a LoadStoreError (Exception 3) crash whenever any async_ws_log_* macro is invoked.

Replace ets_printf with Serial.printf_P using PSTR() 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.

@bdraco bdraco mentioned this pull request Jan 22, 2026
5 tasks
@mathieucarbou mathieucarbou merged commit c96f80d into ESP32Async:main Jan 22, 2026
34 checks passed

/**
* ESP8266 specific configurations
* Note: __FUNCTION__ is stored in flash on ESP8266, so we use FPSTR() to handle it properly

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.

Copy link
Member

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__)

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.

Copy link
Member

@mathieucarbou mathieucarbou Jan 22, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants