checked out v4.1; now crashing

[mzimmers]

Hi all -

I've seen this error on occasion, but now it's doing it 100% of the time, rendering my app useless.

I checked out v4.1 for any updates, and now I get this on startup:

Code: Select all

 (4652) wifi: new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (4652) wifi: state: init -> auth (b0)
***ERROR*** A stack overflow in task wifi has been detected.
abort() was called at PC 0x4008bf8c on core 0

ELF file SHA256: 77ff10b58af3757efb8764af64f26975f51245bc9d4c7940db1a388dc670497b

Backtrace: 0x4008bb9d:0x3ffe8a50 0x4008bf75:0x3ffe8a70 0x4008bf8c:0x3ffe8a90 0x40099894:0x3ffe8ab0 0x40098858:0x3ffe8ad0 0x4009880e:0x3ffe8b10 0x4016b483:0x00000003 |<-CORRUPTED

The PC is at C:/esp-idf/components/esp32/panic.c:125.

Code: Select all

C:\esp-idf>git describe --tags
v4.1-dev-1986-gca735340f

C:\esp-idf>

Can someone help me get the paddles back in the water?

[ESP_Angus]

Hi mzimmers,

Thanks for the report. Can you please decode the backtrace from the stack trace?

The easiest way to do this is to use the idf_monitor tool, otherwise you can manually run xtensa-esp32-elf-addr2line as described here (it's just much more painstaking):
https://docs.espressif.com/projects/esp ... s-decoding

[mzimmers]

Monitor doesn't give me anything useful; I did it manually:

Code: Select all

$ addr2line -e build/wifibutton.elf
0x4008bb9d
C:/esp-idf/components/esp32/panic.c:157
0x4008bf75
C:/esp-idf/components/esp32/panic.c:174
0x4008bf8c
C:/esp-idf/components/esp32/panic.c:125
0x40099894
C:/esp-idf/components/freertos/tasks.c:2770
0x40098858
C:/esp-idf/components/freertos/portasm.S:406
0x4009880e
C:/esp-idf/components/freertos/portasm.S:206

Thanks...

[ESP_Angus]

Do you mind please using the full command line given in the docs link? The line numbers are often off-by-one or two, but the function names (and inlines) save a lot of time to understand the trace. The full command line is "xtensa-esp32-elf-addrline -pfia -e ELFFILE".

Monitor doesn't give me anything useful

That's very odd. Happy to help you debug it separately if that's useful.

[mzimmers]

Code: Select all

C:\esp32_projects\wifibutton>xtensa-esp32-elf-addr2line -pfiaC -e build/wifibutton.elf
0x4008bb9d
0x4008bb9d: invoke_abort at C:/esp-idf/components/esp32/panic.c:157
0x4008bf75
0x4008bf75: abort at C:/esp-idf/components/esp32/panic.c:174
0x4008bf8c
0x4008bf8c: vApplicationStackOverflowHook at C:/esp-idf/components/esp32/panic.c:125
0x40099894
0x40099894: vTaskSwitchContext at C:/esp-idf/components/freertos/tasks.c:2770
0x40098858
0x40098858: _frxt_dispatch at C:/esp-idf/components/freertos/portasm.S:406
0x4009880e
0x4009880e: _frxt_int_exit at C:/esp-idf/components/freertos/portasm.S:206

Here's what I get with monitor:

Code: Select all

C:\esp32_projects\wifibutton>idf.py monitor
Executing action: monitor
Choosing default port b'COM7' (use '-p PORT' option to set a specific serial port)
Running idf_monitor in directory c:\esp32_projects\wifibutton
Executing "C:\esp32_toolchain\python_env\idf4.1_py3.7_env\Scripts\python.exe C:\esp-idf\tools/idf_monitor.py -p COM7 -b 115200 --toolchain-prefix xtensa-esp32-elf- c:\esp32_projects\wifibutton\build\wifibutton.elf -m 'C:\esp32_toolchain\python_env\idf4.1_py3.7_env\Scripts\python.exe' 'C:\esp-idf\tools\idf.py'"...
--- idf_monitor on COM7 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:4
load:0x3fff0034,len:7256
load:0x40078000,len:15728
ho 0 tail 12 room 4
load:0x40080400,len:4980
0x40080400: _init at ??:?

entry 0x40080714

Thanks...

[liuzhifu]

HI @mzimmers， just can't reproduce this issue myself, is it possible for you to provide the demo (including sdkconfig) code for me to replicate the issue?

[mzimmers]

Hi liuzhifu - I can't do that. Besides being about 12,000 lines of code, my project requires proprietary hardware to run correctly.

I've moved back to release/v4.0, where I don't get this problem.

Thanks for looking.

[ESP_Angus]

Here's what I get with monitor:

So you don't get any monitor output after the ROM bootloader hands over to the IDF bootloader?

Are you setting a different baud rate for the console in the project (other than 115200)? If so, you can configure this or override it using an environment variable.

[mzimmers]

Hi Angus - no, I'm using the standard baud rate of 115,200. I don't think it would be a baud rate issue anyway, as I'm not seeing garbage; I'm just not seeing anything (other than what I posted).

[ESP_Angus]

That's very unusual! All I can think is that we have an exception handler in idf_monitor because sometimes Windows Console refuses to accept some sequences of bytes that are written to it. Our experience has been that it keeps working after this, but maybe under some circumstances it breaks the console completely?

If you have time, can you please try making this one line change in idf_monitor.py (replace "pass" with "raise" on line 1022), and see if it crashes when you boot up in the monitor?

Code: Select all

diff --git a/tools/idf_monitor.py b/tools/idf_monitor.py
index 0c1e2bfa01..fd56c5566f 100755
--- a/tools/idf_monitor.py
+++ b/tools/idf_monitor.py
@@ -1019,7 +1019,7 @@ if os.name == 'nt':
                 #
                 # Also possible for Windows to throw an OSError error if the data is invalid for the console
                 # (garbage bytes, etc)
-                pass
+                raise
 
         def write(self, data):
             if isinstance(data, bytes):