[BUG] ESP8266 crashes if different pages are loaded on high frequency #70
Comments
|
this is probably due to mem shortage and not a bug in server, advise to monitor your heap size and fragmentation. |
|
@lumapu : I know the project (using OpenDTU myself). Questions :
|
|
@lumapu correct me if I am wrong but I dont see any usage in your project Pio file of this fork, neither in your dev branch... Are you opening this issue in the right location? ;-) |
no, not directly at this end, but I have some function to read it during operation via API.
checked again the esphome fork. No crash was produceable. Then seconds after a new compiled version with your fork which crashes really fast.
Good point. I need to do some basic test before delivering new software to the folks. It was not published using your fork - I have only a feature branch localy. I really appreciate that you want to maintain the AsyncWebserver and completly read your discussion with @egnor. Some month ago I was searching for a better maintained fork coming from the younodebox one and found esphome. Since yesterday I know yours and hope that I can use it in near future. |
|
@lumapu thank you for these details! Can you please confirm: you are then using The Async lib behind stays the same, but just the Also, if I look at the traces, you are using SSE, not WebSocket, right ? I suspect that the difference in heap usage is due to the recent change from @vortigont: the project included a custom-made implementation of a forward linked list, which was replaced with std::list which is bi-directional and allows for constant time additions and removal. So the little heap usage increase is expected. We are both not using ESP8266 on a daily basis so it would help a lot if you had the opportunity to create a minimal reproductible test case in an .ino file we could add to the project. If the Async lib stays the same, but only the ESPAsyncWebServer fork is swapped, it would be interesting to find the issue indeed. The only big changes from ESPHome fork regarding SSE are in commits bb4eb89 and 48968b5 for SSE (@vortigont fyi) - not considering the more common api (request / response / handlers) |
|
9k of heap is definitely too low to work reliably even with a single connection. Running on the edge its is just a matter of time when you'll hit the out of mem issue. If your project if so memory stressed then I would not target for 8266 at all. Sorry, but this chip is too old to invest considerable time to optimize the code for such a limited conditions. |
|
@lumapu : you would need to measure the free heap just before the allocation requests that are failing (line see see in the stack traces ). @vortigont : what I do not get is why it works with the ESPhome fork. I agree with you that the free memory is too low and this is asking for problems, but the difference between the 2 forks in terms of memory usage is low. I was wondering if one of the 2 commits could have introduced a side effect not thought of. Sincerely I do not see any right now that is why I was asking for your second option. |
I agree, and I had to make the same hard choice on my projects. The ESP8266 is 10 years old now and you can easily swap it with an ESP32 for less then 2 euros which has a lot more memory, power, cores etc |
that's what I mean - there might be something very specific indeed that could be investigated and even probably fixed or optimized, but to do this on 8266 - nah... have more things to invest time and efforts into :) |
I agree: without more effort from @lumapu to pinpoint a bit more the issue and have a minimal reproductible use case proving any issue from the library, we cannot do anything but suspect a memory constrain as shown in the stack trace. @lumapu : you should monitor your free heap at key points where memory is allocated (before these malloc / new / vfprintf calls. |
|
@lumapu : could you please walk me through your project and tell me exactly which API ou are calling, with which kind of data when it fails ? I guess it all start here, but please be more specific. https://github.com/lumapu/ahoy/blob/main/src/web/web.h I am willing to help more, but the lack of information you give is not helping ;-) Specifically, what I am searching for, is if a change in method signature regarding PROGMEM usage could have made it so that the content is now not read from flash but loaded into ram. So I need to know what exactly you are using for the ESpAsync API. As I understand right now, your html pages are generated with a python script and their type is And you are using So the method which is called is: AsyncWebServerResponse *beginResponse_P(int code, const String& contentType, const uint8_t * content, size_t len, AwsTemplateProcessor callback=nullptr);`which is implemented in ESPHome fork and original repo as: AsyncWebServerResponse * AsyncWebServerRequest::beginResponse_P(int code, const String& contentType, const uint8_t * content, size_t len, AwsTemplateProcessor callback){
return new AsyncProgmemResponse(code, contentType, content, len, callback);
}In our repo, this method is deprecated and redirected: [[deprecated("Replaced by beginResponse(...)")]]
AsyncWebServerResponse* beginResponse_P(int code, const String& contentType, const uint8_t* content, size_t len, AwsTemplateProcessor callback = nullptr) {
return beginResponse(code, contentType, content, len, callback);
}and goes to: AsyncWebServerResponse* AsyncWebServerRequest::beginResponse(int code, const String& contentType, const uint8_t* content, size_t len, AwsTemplateProcessor callback) {
return new AsyncProgmemResponse(code, contentType, content, len, callback);
}Can you please have a deeper look at the method signatures used like this example ? Thanks! |
From my understanding this comes with the Webserver, in my ´platformio.ini
I only change line 29 in my
Not completly shure what you mean, let my discribe how it's done in Ahoy:
I can try to do so - give me some time - I don't want to waste too much time in ESP8266 (as you also mentioned 😉) |
full ack - the ESP8266 was the chip where I started at and somehow it is possible to run the most recent software of Ahoy on it, but sadly not with this fork. It's not high prio for me but anyway it would be cool if it is supported. |
correct, it's measured and stored until it's transfered to WebUI by JSON-API |
That's not that easy. I random click on different menu items in the WebUI and from time to time it crashes. I can try to do a screen video to describe better.
I'm sorry for that - I will help as much as I can. You guys are that fast - I really apreciate it. I was talking about the development branch, which is more than 200 commits apart from main: https://github.com/lumapu/ahoy/tree/development03
Maybe this line: https://github.com/lumapu/ahoy/blob/83b386deda9a25ed5279b1efb720b52d33859aef/src/web/web.h#L378
yes that's correct. The python script is used to do some preprocessor and translation things. Also some generic content like menu and footer are included.
yes, I think so: https://github.com/lumapu/ahoy/blob/83b386deda9a25ed5279b1efb720b52d33859aef/src/web/web.h#L248
yes, I was notified by the deprecation and renamed the Thank you for all your efforts, it feels really professional here |
No... Just changing the name is enough. This is the same signature and implementation behind like explained. |
|
I started another (private) project using this AsyncWebserver again. This project does not include websockets for now. Even if I request pages on a high frequency no crash was seen so far. The behavior feels the same as described in newer issue: |
|
@lumapu : ws implementation in this fork is relying on the |
|
@mathieucarbou I did not use the youbox-node-fork for a long time. Thanks for the hint - I think I can easily switch for a test the Webserver library to youbox-node and see if the issue is still there. As a subscriber of esphome fork I heard about the following, maybe it could be related to my problem or at least an improvment: |
|
You are using SSE ? |
@lumapu I have included this patch in this version => |
|
Hi @lumapu , |
|
Hello, I've just fixed a bug regarding string usages for ESP8266 (long time bug): https://github.com/mathieucarbou/ESPAsyncWebServer/releases/tag/v3.3.17 If possible, please let me know if it solves the issue.... |
Please make sure to go through the recommendations before opening a bug report:
https://github.com/mathieucarbou/ESPAsyncWebServer?tab=readme-ov-file#important-recommendations
done, set
-D CONFIG_ASYNC_TCP_STACK_SIZE=4096without any changeDescription
I'm the maintainer and developer of AhoyDTU https://github.com/lumapu/ahoy. This project has some configuration pages, which are mostly communicating using AJAX.
As some of the users mention that the ESP8266 is really unstable with other forks of the AsyncWebserver, I wanted to try this fork.
To produce the issue you simply have to click in the menu 2-3 times on a high frequency to get the ESP crashed.
Board
ESP8266 Wroom
Ethernet adapter used ?
no
Stack trace
I see two different behaviors:
Trace 1
Trace 2
Additional notes
I'd like to switch to this AsyncWebserver in future. As my project is multiplatform I already tested with success on ESP32. For now I use the esphome fork, but there the ESP8266 also feels unstable (that is reported by many users).
The text was updated successfully, but these errors were encountered: