How can i debug what's the problem? I get the following crash (source code on my github: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3): I used the latest openvehicle updates + my mitsubishi code. I create the firwmare with make app, then upload to my NAS and update via OTA update.
Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console
Firmware: 3.1.011-244-g1a15127d-dirty/ota_0/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 OVMS> ***ERROR*** A stack overflow in task OVMS DukTape has been detected. abort() was called at PC 0x40096278 on core 1 Backtrace: 0x40096064:0x3ffc11b0 0x4009625f:0x3ffc11d0 0x40096278:0x3ffc11f0 0x40091704:0x3ffc1210 0x40093768:0x3ffc1230 0x4009371e:0x3ffc1250 0x7aad5675:0x3f81d8f4 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x3b (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:0x3fff0018,len:4 load:0x3fff001c,len:4960 ho 0 tail 12 room 4 load:0x40078000,len:7416 ho 0 tail 12 room 4 load:0x40080000,len:8344 entry 0x4008037c I (882) spiram: SPI RAM mode: flash 40m sram 40m I (882) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (883) cpu_start: Pro cpu up. I (887) cpu_start: Starting app cpu, entry point is 0x40081668 I (877) cpu_start: App cpu up. I (1785) spiram: SPI SRAM memory test OK I (1786) heap_init: Initializing. RAM available for dynamic allocation: I (1786) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1793) heap_init: At 3FFBCDA8 len 00023258 (140 KiB): DRAM I (1798) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1805) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1811) heap_init: At 4009D560 len 00002AA0 (10 KiB): IRAM --
Hello Tamás, Same bug here, with the last release, my guest is because we load in memory to many thing. To be able to start the device I choose Vehicle Empty and then chose the right one or you can disable duktape on sdkconfig (or by make menuconfig) # # Library Support # CONFIG_OVMS_SC_JAVASCRIPT_NONE=y CONFIG_OVMS_SC_JAVASCRIPT_DUKTAPE= regards, Olivier Le dim. 20 janv. 2019 à 12:38, Tamás Kovács <kommykt@gmail.com> a écrit :
How can i debug what's the problem? I get the following crash (source code on my github: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3): I used the latest openvehicle updates + my mitsubishi code. I create the firwmare with make app, then upload to my NAS and update via OTA update.
Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console
Firmware: 3.1.011-244-g1a15127d-dirty/ota_0/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 OVMS> ***ERROR*** A stack overflow in task OVMS DukTape has been detected. abort() was called at PC 0x40096278 on core 1 Backtrace: 0x40096064:0x3ffc11b0 0x4009625f:0x3ffc11d0 0x40096278:0x3ffc11f0 0x40091704:0x3ffc1210 0x40093768:0x3ffc1230 0x4009371e:0x3ffc1250 0x7aad5675:0x3f81d8f4 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x3b (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:0x3fff0018,len:4 load:0x3fff001c,len:4960 ho 0 tail 12 room 4 load:0x40078000,len:7416 ho 0 tail 12 room 4 load:0x40080000,len:8344 entry 0x4008037c I (882) spiram: SPI RAM mode: flash 40m sram 40m I (882) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (883) cpu_start: Pro cpu up. I (887) cpu_start: Starting app cpu, entry point is 0x40081668 I (877) cpu_start: App cpu up. I (1785) spiram: SPI SRAM memory test OK I (1786) heap_init: Initializing. RAM available for dynamic allocation: I (1786) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1793) heap_init: At 3FFBCDA8 len 00023258 (140 KiB): DRAM I (1798) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1805) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1811) heap_init: At 4009D560 len 00002AA0 (10 KiB): IRAM --
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
What size stack have you defined for Duktape? Should be the default 12288. Regards, Mark
On 20 Jan 2019, at 8:04 PM, Olivier <ogrums@gmail.com> wrote:
Hello Tamás,
Same bug here, with the last release, my guest is because we load in memory to many thing. To be able to start the device I choose Vehicle Empty and then chose the right one or you can disable duktape on sdkconfig (or by make menuconfig)
# # Library Support # CONFIG_OVMS_SC_JAVASCRIPT_NONE=y CONFIG_OVMS_SC_JAVASCRIPT_DUKTAPE=
regards, Olivier
Le dim. 20 janv. 2019 à 12:38, Tamás Kovács <kommykt@gmail.com> a écrit : How can i debug what's the problem? I get the following crash (source code on my github: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3): I used the latest openvehicle updates + my mitsubishi code. I create the firwmare with make app, then upload to my NAS and update via OTA update.
Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console Firmware: 3.1.011-244-g1a15127d-dirty/ota_0/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 OVMS> ***ERROR*** A stack overflow in task OVMS DukTape has been detected. abort() was called at PC 0x40096278 on core 1 Backtrace: 0x40096064:0x3ffc11b0 0x4009625f:0x3ffc11d0 0x40096278:0x3ffc11f0 0x40091704:0x3ffc1210 0x40093768:0x3ffc1230 0x4009371e:0x3ffc1250 0x7aad5675:0x3f81d8f4 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x3b (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:0x3fff0018,len:4 load:0x3fff001c,len:4960 ho 0 tail 12 room 4 load:0x40078000,len:7416 ho 0 tail 12 room 4 load:0x40080000,len:8344 entry 0x4008037c I (882) spiram: SPI RAM mode: flash 40m sram 40m I (882) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (883) cpu_start: Pro cpu up. I (887) cpu_start: Starting app cpu, entry point is 0x40081668 I (877) cpu_start: App cpu up. I (1785) spiram: SPI SRAM memory test OK I (1786) heap_init: Initializing. RAM available for dynamic allocation: I (1786) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1793) heap_init: At 3FFBCDA8 len 00023258 (140 KiB): DRAM I (1798) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1805) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1811) heap_init: At 4009D560 len 00002AA0 (10 KiB): IRAM --
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I don't updated the sdkconfig file, now use the latest working, no crash. In old missing stack size row. Mark Webb-Johnson <mark@webb-johnson.net> ezt írta (időpont: 2019. jan. 20., V, 13:31):
What size stack have you defined for Duktape? Should be the default 12288.
Regards, Mark
On 20 Jan 2019, at 8:04 PM, Olivier <ogrums@gmail.com> wrote:
Hello Tamás,
Same bug here, with the last release, my guest is because we load in memory to many thing. To be able to start the device I choose Vehicle Empty and then chose the right one or you can disable duktape on sdkconfig (or by make menuconfig)
# # Library Support # CONFIG_OVMS_SC_JAVASCRIPT_NONE=y CONFIG_OVMS_SC_JAVASCRIPT_DUKTAPE=
regards, Olivier
Le dim. 20 janv. 2019 à 12:38, Tamás Kovács <kommykt@gmail.com> a écrit :
How can i debug what's the problem? I get the following crash (source code on my github: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3): I used the latest openvehicle updates + my mitsubishi code. I create the firwmare with make app, then upload to my NAS and update via OTA update.
Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console
Firmware: 3.1.011-244-g1a15127d-dirty/ota_0/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 OVMS> ***ERROR*** A stack overflow in task OVMS DukTape has been detected. abort() was called at PC 0x40096278 on core 1 Backtrace: 0x40096064:0x3ffc11b0 0x4009625f:0x3ffc11d0 0x40096278:0x3ffc11f0 0x40091704:0x3ffc1210 0x40093768:0x3ffc1230 0x4009371e:0x3ffc1250 0x7aad5675:0x3f81d8f4 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x3b (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:0x3fff0018,len:4 load:0x3fff001c,len:4960 ho 0 tail 12 room 4 load:0x40078000,len:7416 ho 0 tail 12 room 4 load:0x40080000,len:8344 entry 0x4008037c I (882) spiram: SPI RAM mode: flash 40m sram 40m I (882) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (883) cpu_start: Pro cpu up. I (887) cpu_start: Starting app cpu, entry point is 0x40081668 I (877) cpu_start: App cpu up. I (1785) spiram: SPI SRAM memory test OK I (1786) heap_init: Initializing. RAM available for dynamic allocation: I (1786) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1793) heap_init: At 3FFBCDA8 len 00023258 (140 KiB): DRAM I (1798) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1805) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1811) heap_init: At 4009D560 len 00002AA0 (10 KiB): IRAM --
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Üdvözlettel: Kovács Tamás
When you ‘make’, it should set defaults for kconfig. Anyway, stack of 12288 definitely solves this problem. Mark
On 20 Jan 2019, at 8:47 PM, Tamás Kovács <kommykt@gmail.com> wrote:
I don't updated the sdkconfig file, now use the latest working, no crash. In old missing stack size row.
Mark Webb-Johnson <mark@webb-johnson.net> ezt írta (időpont: 2019. jan. 20., V, 13:31):
What size stack have you defined for Duktape? Should be the default 12288.
Regards, Mark
On 20 Jan 2019, at 8:04 PM, Olivier <ogrums@gmail.com> wrote:
Hello Tamás,
Same bug here, with the last release, my guest is because we load in memory to many thing. To be able to start the device I choose Vehicle Empty and then chose the right one or you can disable duktape on sdkconfig (or by make menuconfig)
# # Library Support # CONFIG_OVMS_SC_JAVASCRIPT_NONE=y CONFIG_OVMS_SC_JAVASCRIPT_DUKTAPE=
regards, Olivier
Le dim. 20 janv. 2019 à 12:38, Tamás Kovács <kommykt@gmail.com> a écrit : How can i debug what's the problem? I get the following crash (source code on my github: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3): I used the latest openvehicle updates + my mitsubishi code. I create the firwmare with make app, then upload to my NAS and update via OTA update.
Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console Firmware: 3.1.011-244-g1a15127d-dirty/ota_0/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 OVMS> ***ERROR*** A stack overflow in task OVMS DukTape has been detected. abort() was called at PC 0x40096278 on core 1 Backtrace: 0x40096064:0x3ffc11b0 0x4009625f:0x3ffc11d0 0x40096278:0x3ffc11f0 0x40091704:0x3ffc1210 0x40093768:0x3ffc1230 0x4009371e:0x3ffc1250 0x7aad5675:0x3f81d8f4 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x3b (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:0x3fff0018,len:4 load:0x3fff001c,len:4960 ho 0 tail 12 room 4 load:0x40078000,len:7416 ho 0 tail 12 room 4 load:0x40080000,len:8344 entry 0x4008037c I (882) spiram: SPI RAM mode: flash 40m sram 40m I (882) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (883) cpu_start: Pro cpu up. I (887) cpu_start: Starting app cpu, entry point is 0x40081668 I (877) cpu_start: App cpu up. I (1785) spiram: SPI SRAM memory test OK I (1786) heap_init: Initializing. RAM available for dynamic allocation: I (1786) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1793) heap_init: At 3FFBCDA8 len 00023258 (140 KiB): DRAM I (1798) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1805) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1811) heap_init: At 4009D560 len 00002AA0 (10 KiB): IRAM --
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Üdvözlettel: Kovács Tamás _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I also updated yesterday and got a stack overflow in duktape on boot. When I updated I remember git complaining because I had modified main/Kconfig (minimal Cadillac support) so I reverted it, updated it and then manually merged my changes back in. But today I updated sdkconfig: mv sdkconfig{,-} cp support/support/sdkconfig.default.hw31 sdkconfig and see change I was missing: diff sdkconfig{-,} 494c494 < CONFIG_OVMS_SC_JAVASCRIPT_DUKTAPE_STACK=8192 --- > CONFIG_OVMS_SC_JAVASCRIPT_DUKTAPE_STACK=12288 I now have 3.2.001-8-gf09b83a5-dirty running on my dev box. Craig
participants (4)
-
Craig Leres -
Mark Webb-Johnson -
Olivier -
Tamás Kovács