Closed andig closed 8 years ago
so you are testing how the server performs when there are no handlers attached? Do you wait for the WiFi to start? Also can you please use addr2line when such exception occurs and get where it happened? Interesting addresses above are: 0x4021dec7 4021bee2 4021baf1
No success (new dump, new addresses due to added wifi connect wait):
C:\andi\arduino\hardware\eps8266com\esp8266\tools\xtensa-lx106-elf\bin>xtensa-lx106-elf-addr2line -e C:\Users\xx\AppData\Local\Temp\build662bf6597004a59e628e0f8ceba459f9.tmp\async.ino.elf 0x4021befa 0x4021bb09 0x4021dedf 0x4021baf8
??:?
??:?
??:?
??:?
addr2line needs be run on the .elf, right?
so you are testing how the server performs when there are no handlers attached?
I'm trying to build a minimal test case for the crashes I've seen. First step was adding heap4c which made crashes almost immediate. I assumed heap4c itself is not the reason so I started to dig in further.
After removing all my code and then all handlers it still crashed if there's http requests coming in. I'm suspecting the async server itself (no better idea with the minimal sketch above..)
Crash only happens if server is busy. No requests, no crash.
just do
xtensa-lx106-elf-addr2line C:\Users\xx\AppData\Local\Temp\build662bf6597004a59e628e0f8ceba459f9.tmp\async.ino.elf
then enter the addresses (they change with the code that's fine) just look for the addresses starting with 402 in the dump (some 401 might show as well)
the server should return 500 on request. How often does your curl command send requests?
does it wait for them to finish before starting a new one?
just do
error: xtensa-lx106-elf-addr2line: 'a.out': No such file
. I need the -e
then enter the addresses (they change with the code that's fine) just look for the addresses starting with 402 in the dump (some 401 might show as well)
Same result. Just ??.
the server should return 500 on request. How often does your curl command send requests? Does it wait for them to finish before starting a new one?
Even a single request is enough to crash if heap4c is compiled in.
and what if not using heap4c? and you were correct. I actually execute xtensa-lx106-elf-addr2line -aipfC -e [elf]
and what if not using heap4c?
no crash, runs for ages. But heap4c does heap poisoning as I've understood.
Unfortunely I've not yet managed to get gdb running on windows- no bundled version in the SDK :(
I've gone back to an old version of my sketch with sync server + heap4c. No crashes.
For what it's worth: naked AsyncServer with heap4c doesn't crash. AyncWebServer does.
maybe stop printing from heap4 ? and you need to understand that I can not support heap4 nor alter it's code as we are not supposed to use it at all
you are printing from interrupt using HardwareSerial that uses interrupts. Many shit can go wrong the other one you print from the loop And why test naked server? Who will ever use a Web server without a handler? There is TCP server for that
And why test naked server? Who will ever use a Web server without a handler? There is TCP server for that
Nobody. Trying to limit the number of variables. Don't have better ideas without gdb :(
you are printing from interrupt using HardwareSerial that uses interrupts. Many shit can go wrong the other one you print from the loop
ok. I could test get rid of printing and leave the lib in.
btw, this would need update for latest git https://github.com/me-no-dev/ESPAsyncWebServer/blob/8fed4c42f34a4693b6529f051fbb6840d886a1b4/src/WebResponses.cpp#L362
ok. I could test get rid of printing and leave the lib.
Still crashes :(
I'm trying to write a tool to decode the dumps for you (through the IDE tools). Maybe we'll get a better idea of what and why it happens. But since it does not crash with the regular memory management, I doubt it's the server's fault really... I checked the code and it all goes as planned even if no handlers are attached. As I said, will return 500 :) I updated the git for the changes in the core ;)
so I tested your sketch with umm_malloc and have no issues either :) if you want to give it a shot, my git fork of the ESP repo is running it
so I tested your sketch with umm_malloc and have no issues either :)
so its working with heap4 and working with umm_alloc, both with traffic, right?
if you want to give it a shot, my git fork of the ESP repo is running it
the 31b or the arduino? main branch?
I'm wondering what other differences there could be. Maybe the toolchain on Windows has problems?
my ESP8266 Arduino branch is running on umm_malloc. I did not try heap4 to be honest. Had already deleted the contents of the file :)
Ok. Crash with heap4 is this:
0x4021dfe7: tcp_output at ??:?
0x4021dfe7: tcp_output at ??:?
0x4021c002: tcp_input at ??:?
0x4021bc11: tcp_input at ??:?
0x4021bc00: tcp_input at ??:?
0x4021aa16: ip_input at ??:?
0x402197ab: etharp_find_addr at ??:?
0x40219d56: ethernet_input at ??:?
0x4022570f: ets_snprintf at ??:?
0x40205cf3: loop_task at C:\andi\arduino\hardware\eps8266com\esp8266\cores\esp8266/core_esp8266_main.cpp:43
0x40000f49: ?? ??:0
0x40000f49: ?? ??:0
As it does not crash with your umm* branch I'm closing as invalid. Thanks to the tool I can go back to the original sketch now and see how that behaves...
Trying to track down some crashes I've implemented heap4c and a simple sketch:
When putting a little load, this will crash pretty immediately if heap4c present and run fine for ages (as does a more complex sketch) as long as
ESPAsyncWebServer
is not started. As you can see there are no handlers attached, start ofESPAsyncWebServer
alone is enough to cause the crash.Use this for load:
Crash (update- deleted everything before wifi is up):