[Ovmsdev] Crash debug

[Tamás Kovács]

I don't updated the sdkconfig file, now use the latest working, no crash.
In old missing stack size row.

Mark Webb-Johnson <mark at 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 at 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 at 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 at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
Üdvözlettel:
Kovács Tamás
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190120/87ab63f6/attachment-0001.html>