"Continue in AP mode" crashing after PR #135

[glynhudson]

I think I've found a bug which seems to have been introduced after PR #135.

When in AP and the "Continue in AP mode" is selected the unit crashes. "Continue in AP Mode" is a very useful feature since it enables the wifi-gateway to be used without connecting to a local WiFi network. See #120

$GU^36
Exception (9):
epc1=0x40216e9c epc2=0x00000000 epc3=0x00000000 excvaddr=0x097f0762 depc=0x00000000

ctx: sys 
sp: 3ffffcf0 end: 3fffffb0 offset: 01a0

>>>stack>>>
3ffffe90:  3fff7474 00000323 3fff5b2c 402110f4  
3ffffea0:  3fff59a4 00000007 3fff2868 40212500  
3ffffeb0:  3ffe8f3f 00000007 3fff2868 40216809  
3ffffec0:  3fff59a4 00000007 3fff2868 40219f27  
3ffffed0:  00000000 00000000 00000000 00000000  
3ffffee0:  00000000 00000000 3fff7474 0000032f  
3ffffef0:  00000323 3ffec064 3ffec06e 3fff63ac  
3fffff00:  00000008 00000000 3fff7164 401004d8  
3fffff10:  4020b130 3fff5354 0000001d 3fff63ac  
3fffff20:  4020b130 3fff669c 3fff2878 4020b1d4  
3fffff30:  40237551 00000000 3fff00d8 40237608  
3fffff40:  4023732d 3fff00f0 3ffef570 0e473c4b  
3fffff50:  60000600 00000003 3ffef570 0e473c4b  
3fffff60:  40237849 40240ea0 40241b6f 00000001  
3fffff70:  40247655 00000000 3ffeb271 00000008  
3fffff80:  4024769a 3fffdab0 00000000 3fffdcb0  
3fffff90:  3ffef580 3fffdab0 00000000 40202b37  
3fffffa0:  40000f49 40000f49 3fffdab0 40000f49  
<<<stack<<<

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v4ceabea9
~ld

[jeremypoulter]

Well that sucks....

If you still have the ELF file can you try using https://github.com/janLo/EspArduinoExceptionDecoder to decode the stack trace?

[glynhudson]

Here's the decoded result:

./decoder.py -e firmware.elf stack.txt 
Exception: 9 (LoadStoreAlignmentCause: Load or store to an unaligned address)

epc1:     0x40216e9c: AsyncClient::setRxTimeout(unsigned int) at ??:?
epc2:     0x00000000
epc3:     0x00000000
excvaddr: 0x097f0762
depc:     0x00000000

ctx: sys

sp:       0x3ffffcf0
end:      0x3fffffb0
offset:   0x000001a0

stack:
0x402110f4: AsyncResponseStream::write(unsigned char const*, unsigned int) at ??:?
0x40212500: non-virtual thunk to AsyncResponseStream::write(unsigned char const*, unsigned int) at ??:?
0x40216809: Print::print(String const&) at ??:?
0x40219f27: std::_Function_handler<void (int), handleScan(AsyncWebServerRequest*)::{lambda(int)#1}>::_M_invoke(std::_Any_data const&, int) at web_server.cpp:?
0x401004d8: malloc at ??:?
0x4020b130: ESP8266WiFiScanClass::_scanDone(void*, int) at ??:?
0x4020b130: ESP8266WiFiScanClass::_scanDone(void*, int) at ??:?
0x4020b1d4: ESP8266WiFiScanClass::_scanDone(void*, int) at ??:?
0x40237551: scan_cancel at ??:?
0x40237608: scan_cancel at ??:?
0x4023732d: scan_start at ??:?
0x40237849: scan_remove_probe_ssid at ??:?
0x40240ea0: ppCheckTxIdle at ??:?
0x40241b6f: pp_attach at ??:?
0x40247655: ets_timer_handler_isr at ??:?
0x4024769a: ets_timer_handler_isr at ??:?
0x40202b37: loop_task(ETSEventTag*) at core_esp8266_main.cpp:?

EspArduinoExceptionDecoder works pretty well, first time I've used it. I did have an issue using the default python 3, I forced it to use 2.7 and it worked. I've comented on an issue janLo/EspArduinoExceptionDecoder#1

[jeremypoulter]

I wonder if this is an issue with the navigation happening during a wifi network scan update. This probably causes the request to be cancelled.

[glynhudson]

Sounds plausible. Is there a way to make wifi scanning not happen all the time? ie. it happens once when the page is loaded. I've noticed when trying to select a wifi network the SSID's often move up and down as new wifi networks (often very weak ones) are detected or disappear. While very impressive I don't think the continuous scanning is required. It can actually make selecting the desired SSID a bit tricky if the list is continuously moving up and down! Maybe a button "refersh" or "update WiFi scan" if a re-scan is required.

Maybe this would fix the issue.

I just tested again on a different ESP using staging libs and was able to reproduce the crash, however this time the stack track was a bit different:

Exception: 9 (LoadStoreAlignmentCause: Load or store to an unaligned address)

epc1:     0x40218240: AsyncClient::space() at ??:?
epc2:     0x00000000
epc3:     0x00000000
excvaddr: 0x65636351
depc:     0x00000000

ctx: sys

sp:       0x3ffffc70
end:      0x3fffffb0
offset:   0x000001a0

stack:
0x40211bc0: AsyncWebServerResponse::addHeader(String const&, String const&) at ??:?
0x40212261: AsyncWebServerResponse::_assembleHead(unsigned char) at ??:?
0x4010020c: _umm_free at umm_malloc.c:?
0x40211bc0: AsyncWebServerResponse::addHeader(String const&, String const&) at ??:?
0x40100690: free at ??:?
0x402025c3: String::move(String&) at ??:?
0x40211bc0: AsyncWebServerResponse::addHeader(String const&, String const&) at ??:?
0x402117c4: AsyncAbstractResponse::_respond(AsyncWebServerRequest*) at ??:?
0x4021082d: AsyncWebServerRequest::send(AsyncWebServerResponse*) at ??:?
0x40212c3c: non-virtual thunk to AsyncResponseStream::write(unsigned char const*, unsigned int) at ??:?
0x40217b49: Print::print(String const&) at ??:?
0x4021b9f7: std::_Function_handler<void (int), handleScan(AsyncWebServerRequest*)::{lambda(int)#1}>::_M_invoke(std::_Any_data const&, int) at web_server.cpp:?
0x401004d8: malloc at ??:?
0x4020b68c: ESP8266WiFiScanClass::_scanDone(void*, int) at ??:?
0x4020b68c: ESP8266WiFiScanClass::_scanDone(void*, int) at ??:?
0x4020b730: ESP8266WiFiScanClass::_scanDone(void*, int) at ??:?
0x40239261: scan_cancel at ??:?
0x40239318: scan_cancel at ??:?
0x4023903d: scan_start at ??:?
0x40239559: scan_remove_probe_ssid at ??:?
0x40249355: ets_timer_handler_isr at ??:?
0x4024939a: ets_timer_handler_isr at ??:?
0x4020303f: loop_task(ETSEventTag*) at core_esp8266_main.cpp:?

[glynhudson]

Interestingly since #135 has had a negative effect on the amount of free heap available. Here's a graph showing the past month of free heap on my home openevse. Maybe it's just a coincidence but the drop in free heap does coincide with when I uploaded #135 and #132.

What sort of free heap values are you experiencing on your test setup?

I've been trying to thing of ways we can reduce memory usage, maybe #143 could help a bit?