Hi folks, I just updated to the latest (7 commits), and am having trouble with a stack overflow in a task named "tiT". Not sure if that's real, or if the task name has been corrupted. My startup script enables both simcom and wifi. Turning off wifi doesn't prevent the crash. Turning off simcom does (I get all the way to the server connecting), so it's apparently somehow related to the modem and ppp stack. Thoughts? Greg W (10404) wifi: incorrect scan type: 1073533448 I (11404) simcom: State timeout, transition to 2 I (11404) simcom: State: Enter PoweringOn state I (11404) simcom: Power Cycle I (11894) housekeeping: System considered stable, auto init re-enabled I (17034) simcom: State: Enter PoweredOn state I (36404) simcom: State: Enter MuxStart state I (36404) gsm-mux: Start MUX I (36414) gsm-mux: Channel #0 is open I (36424) gsm-mux: Channel #1 is open I (36424) gsm-mux: Channel #2 is open I (36434) gsm-mux: Channel #3 is open I (36434) gsm-mux: Channel #4 is open I (37404) simcom: State: Enter NetWait state I (47484) simcom: CREG Network Registration: RegisteredRoaming I (48404) simcom: State: Enter NetStart state I (49494) simcom: PPP Connection is ready to start I (50404) simcom: State: Enter NetMode state I (50404) gsm-ppp: Initialising... W (50404) wifi: incorrect scan type: 1073533448 OVMS > ***ERROR*** A stack overflow in task tiT has been detected. abort() was called at PC 0x4008f024 on core 1 0x4008f024: vApplicationStackOverflowHook at /home/greg/esp/esp-idf/components/esp32/./panic.c:648 Backtrace: 0x4008ee34:0x3ffca170 0x4008f00b:0x3ffca190 0x4008f024:0x3ffca1b0 0x4008b52c:0x3ffca1d0 0x4008d534:0x3ffca1f0 0x4008d4ea:0x3ffb15dc 0x4008ee34: invoke_abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648 0x4008f00b: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648 0x4008f024: vApplicationStackOverflowHook at /home/greg/esp/esp-idf/components/esp32/./panic.c:648 0x4008b52c: vTaskSwitchContext at /home/greg/esp/esp-idf/components/freertos/./tasks.c:4837 0x4008d534: _frxt_dispatch at /home/greg/esp/esp-idf/components/freertos/./portasm.S:406 0x4008d4ea: _frxt_int_exit at /home/greg/esp/esp-idf/components/freertos/./portasm.S:206 Rebooting...
I think that is the TCP/IP task. Maybe CONFIG_TCPIP_TASK_STACK_SIZE? Have a look in menuconfig and see what you have those stack sizes set to (/STACK to show them all). A ‘module tasks’ can show you the current running values. My tiT is 3072bytes in size (but max level is 696 bytes). CONFIG_TCPIP_TASK_STACK_SIZE=2560 Regards, Mark
On 2 Mar 2018, at 12:55 PM, Greg D. <gregd2350@gmail.com> wrote:
Hi folks,
I just updated to the latest (7 commits), and am having trouble with a stack overflow in a task named "tiT". Not sure if that's real, or if the task name has been corrupted.
My startup script enables both simcom and wifi. Turning off wifi doesn't prevent the crash. Turning off simcom does (I get all the way to the server connecting), so it's apparently somehow related to the modem and ppp stack.
Thoughts?
Greg
W (10404) wifi: incorrect scan type: 1073533448 I (11404) simcom: State timeout, transition to 2 I (11404) simcom: State: Enter PoweringOn state I (11404) simcom: Power Cycle I (11894) housekeeping: System considered stable, auto init re-enabled I (17034) simcom: State: Enter PoweredOn state I (36404) simcom: State: Enter MuxStart state I (36404) gsm-mux: Start MUX I (36414) gsm-mux: Channel #0 is open I (36424) gsm-mux: Channel #1 is open I (36424) gsm-mux: Channel #2 is open I (36434) gsm-mux: Channel #3 is open I (36434) gsm-mux: Channel #4 is open I (37404) simcom: State: Enter NetWait state I (47484) simcom: CREG Network Registration: RegisteredRoaming I (48404) simcom: State: Enter NetStart state I (49494) simcom: PPP Connection is ready to start I (50404) simcom: State: Enter NetMode state I (50404) gsm-ppp: Initialising... W (50404) wifi: incorrect scan type: 1073533448 OVMS > ***ERROR*** A stack overflow in task tiT has been detected. abort() was called at PC 0x4008f024 on core 1 0x4008f024: vApplicationStackOverflowHook at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
Backtrace: 0x4008ee34:0x3ffca170 0x4008f00b:0x3ffca190 0x4008f024:0x3ffca1b0 0x4008b52c:0x3ffca1d0 0x4008d534:0x3ffca1f0 0x4008d4ea:0x3ffb15dc 0x4008ee34: invoke_abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008f00b: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008f024: vApplicationStackOverflowHook at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008b52c: vTaskSwitchContext at /home/greg/esp/esp-idf/components/freertos/./tasks.c:4837
0x4008d534: _frxt_dispatch at /home/greg/esp/esp-idf/components/freertos/./portasm.S:406
0x4008d4ea: _frxt_int_exit at /home/greg/esp/esp-idf/components/freertos/./portasm.S:206
Rebooting...
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Perhaps set to 4096, then stress the system. SSH, webserver, etc. Then, have a look at ‘module tasks’ and see the maximum it got to. Regards, Mark.
On 2 Mar 2018, at 2:00 PM, Greg D. <gregd2350@gmail.com> wrote:
Yeah, stack size is 2560. Tried bumping it to 4k, and that fixed it. Backing down, it seems like just bumping it from 2560 to 2816 is sufficient to prevent the crash.
What value should I set it to?
Greg
Mark Webb-Johnson wrote:
I think that is the TCP/IP task. Maybe CONFIG_TCPIP_TASK_STACK_SIZE?
Have a look in menuconfig and see what you have those stack sizes set to (/STACK to show them all). A ‘module tasks’ can show you the current running values. My tiT is 3072bytes in size (but max level is 696 bytes).
CONFIG_TCPIP_TASK_STACK_SIZE=2560
Regards, Mark
On 2 Mar 2018, at 12:55 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi folks,
I just updated to the latest (7 commits), and am having trouble with a stack overflow in a task named "tiT". Not sure if that's real, or if the task name has been corrupted.
My startup script enables both simcom and wifi. Turning off wifi doesn't prevent the crash. Turning off simcom does (I get all the way to the server connecting), so it's apparently somehow related to the modem and ppp stack.
Thoughts?
Greg
W (10404) wifi: incorrect scan type: 1073533448 I (11404) simcom: State timeout, transition to 2 I (11404) simcom: State: Enter PoweringOn state I (11404) simcom: Power Cycle I (11894) housekeeping: System considered stable, auto init re-enabled I (17034) simcom: State: Enter PoweredOn state I (36404) simcom: State: Enter MuxStart state I (36404) gsm-mux: Start MUX I (36414) gsm-mux: Channel #0 is open I (36424) gsm-mux: Channel #1 is open I (36424) gsm-mux: Channel #2 is open I (36434) gsm-mux: Channel #3 is open I (36434) gsm-mux: Channel #4 is open I (37404) simcom: State: Enter NetWait state I (47484) simcom: CREG Network Registration: RegisteredRoaming I (48404) simcom: State: Enter NetStart state I (49494) simcom: PPP Connection is ready to start I (50404) simcom: State: Enter NetMode state I (50404) gsm-ppp: Initialising... W (50404) wifi: incorrect scan type: 1073533448 OVMS > ***ERROR*** A stack overflow in task tiT has been detected. abort() was called at PC 0x4008f024 on core 1 0x4008f024: vApplicationStackOverflowHook at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
Backtrace: 0x4008ee34:0x3ffca170 0x4008f00b:0x3ffca190 0x4008f024:0x3ffca1b0 0x4008b52c:0x3ffca1d0 0x4008d534:0x3ffca1f0 0x4008d4ea:0x3ffb15dc 0x4008ee34: invoke_abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008f00b: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008f024: vApplicationStackOverflowHook at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008b52c: vTaskSwitchContext at /home/greg/esp/esp-idf/components/freertos/./tasks.c:4837
0x4008d534: _frxt_dispatch at /home/greg/esp/esp-idf/components/freertos/./portasm.S:406
0x4008d4ea: _frxt_int_exit at /home/greg/esp/esp-idf/components/freertos/./portasm.S:206
Rebooting...
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 02/03/18 19:00, Greg D. wrote:
Yeah, stack size is 2560. Tried bumping it to 4k, and that fixed it. Backing down, it seems like just bumping it from 2560 to 2816 is sufficient to prevent the crash.
I built with the correct version of the esp_idf and my crash on startup reported yesterday persisted. It was not obviously a stack overflow but did occur very shortly after the simcom connected to the network. Setting CONFIG_TCPIP_TASK_STACK_SIZE to 4096 resolves my crash too. Thanks for finding this.
Yea! I'm fussing with getting my module to allow task tracking. In the mean time, do you have any info on how large the stack grows? Seems like we don't need to go all the way to 4k, but I don't want to shave it too close either. Greg Tom Parker wrote:
On 02/03/18 19:00, Greg D. wrote:
Yeah, stack size is 2560. Tried bumping it to 4k, and that fixed it. Backing down, it seems like just bumping it from 2560 to 2816 is sufficient to prevent the crash.
I built with the correct version of the esp_idf and my crash on startup reported yesterday persisted. It was not obviously a stack overflow but did occur very shortly after the simcom connected to the network.
Setting CONFIG_TCPIP_TASK_STACK_SIZE to 4096 resolves my crash too.
Thanks for finding this.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (3)
-
Greg D. -
Mark Webb-Johnson -
Tom Parker