async server shows crash with heap4c about espasyncwebserver HOT 21 CLOSED

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

from espasyncwebserver.

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?

from espasyncwebserver.

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.

from espasyncwebserver.

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)

from espasyncwebserver.

the server should return 500 on request. How often does your curl command send requests?

from espasyncwebserver.

does it wait for them to finish before starting a new one?

from espasyncwebserver.

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.

from espasyncwebserver.

and what if not using heap4c?
and you were correct. I actually execute xtensa-lx106-elf-addr2line -aipfC -e [elf]

from espasyncwebserver.

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 :(

from espasyncwebserver.

I've gone back to an old version of my sketch with sync server + heap4c. No crashes.

from espasyncwebserver.

For what it's worth: naked AsyncServer with heap4c doesn't crash. AyncWebServer does.

from espasyncwebserver.

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

from espasyncwebserver.

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

from espasyncwebserver.

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.

from espasyncwebserver.

btw, this would need update for latest git

from espasyncwebserver.

ok. I could test get rid of printing and leave the lib.

Still crashes :(

from espasyncwebserver.

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

from espasyncwebserver.

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

from espasyncwebserver.

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?

from espasyncwebserver.

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

from espasyncwebserver.

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...

from espasyncwebserver.