[Ovmsdev] Duktape handling of blank metrics?

[Mark Webb-Johnson]

Probably insufficient stack in AsyncConsole.

At the moment it should be 5KB. Maybe more needed?

console_async.cpp line 50

ConsoleAsync::ConsoleAsync() : TaskBase("AsyncConsole", 5*1024)

Can you try increasing, then running a ‘module tasks’ to see what it actually used?

Regards, Mark.

> On 29 Mar 2018, at 10:08 AM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> Here you go...  (newlines added for clarity)
> 
> Greg
> 
> greg at linux-0rpb:~/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3>
> ~/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-addr2line -pfiaC -e
> build/ovms3.elf 0x4008ead4:0x3fff2f50 0x4008ecab:0x3fff2f70
> 0x4008ecc4:0x3fff2f90 0x4008ab6b:0x3fff2fb0 0x4008cd94:0x3fff2fd0
> 0x4008cd4a:0x3fff600c
> 
> 0x4008ead4: invoke_abort at
> /home/greg/esp/esp-idf/components/esp32/./panic.c:648
> 0x4008ecab: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
> 0x4008ecc4: vApplicationStackOverflowHook at
> /home/greg/esp/esp-idf/components/esp32/./panic.c:648
> 0x4008ab6b: vTaskSwitchContext at
> /home/greg/esp/esp-idf/components/freertos/./tasks.c:4837
> 0x4008cd94: _frxt_dispatch at
> /home/greg/esp/esp-idf/components/freertos/./portasm.S:406
> 0x4008cd4a: _frxt_int_exit at
> /home/greg/esp/esp-idf/components/freertos/./portasm.S:206
> 
> greg at linux-0rpb:~/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3>
> 
> 
> 
> 
> 
> Mark Webb-Johnson wrote:
>> Greg,
>> 
>> The backtrace we need is one either via gdbstub, or one you produce with:
>> 
>> ~/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-addr2line -pfiaC -e build/ovms3.elf 0x4008ead4:0x3fff2f50 0x4008ecab:0x3fff2f70 0x4008ecc4:0x3fff2f90 0x4008ab6b:0x3fff2fb0 0x4008cd94:0x3fff2fd0 0x4008cd4a:0x3fff600c
>> 
>> Regards, Mark
>> 
>>> On 29 Mar 2018, at 9:44 AM, Greg D. <gregd2350 at gmail.com> wrote:
>>> 
>>> So, now it's failing at my desk, too.  Good - a lot easier to grab a
>>> backtrace...   But, it's also happening whether the metrics are set or
>>> not.  I've updated the code to the current (including your housekeeping
>>> changes); not sure if that made a difference.
>>> 
>>> OVMS> vfs cat /store/obd2ecu/10
>>> ret1=OvmsMetricFloat("v.p.speed");
>>> ret2=OvmsMetricFloat("v.b.power");
>>> out = 0.0;
>>> if(ret1 > 0) { out=ret2/ret1; }
>>> out;
>>> OVMS> obdii ecu list
>>> PID             Type        Value    Metric
>>> 0   (0x00)       internal     0.000000
>>> 4   (0x04)       internal     0.000000 v.b.soc
>>> 5   (0x05)         metric     0.000000 v.e.temp
>>> ***ERROR*** A stack overflow in task AsyncConsole has been detected.
>>> abort() was called at PC 0x4008ecc4 on core 1
>>> 
>>> Backtrace: 0x4008ead4:0x3fff2f50 0x4008ecab:0x3fff2f70
>>> 0x4008ecc4:0x3fff2f90 0x4008ab6b:0x3fff2fb0 0x4008cd94:0x3fff2fd0
>>> 0x4008cd4a:0x3fff600c
>>> 
>>> Rebooting...
>>> 
>>> 
>>> 
>>> 
>>> Mark Webb-Johnson wrote:
>>>> Need to see a backtrace. Perhaps you are just on the borderline of stack usage, or something going crazy?
>>>> 
>>>> Looking at DukOvmsMetricFloat(), it just return the metric AsFloat(), and for float type metrics that should just be zero if not defined.
>>>> 
>>>> Regards, Mark.
>>>> 
>>>>> On 29 Mar 2018, at 8:58 AM, Greg D. <gregd2350 at gmail.com> wrote:
>>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> Does anyone know how DukTape scripting handles math with a metric that
>>>>> hasn't been updated yet? 
>>>>> 
>>>>> I have a short example script in the OBDII ECU documentation which
>>>>> (should) calculate a power-per-speed metric for display on a HUD.  Seems
>>>>> like it would be a useful example, and wanted to verify that it actually
>>>>> works. 
>>>>> 
>>>>> OVMS> vfs cat /store/obd2ecu/10
>>>>> ret1=OvmsMetricFloat("v.p.speed");
>>>>> ret2=OvmsMetricFloat("v.b.power");
>>>>> out = 0.0;
>>>>> if(ret1 > 0) { out=ret2/ret1; }
>>>>> out;
>>>>> 
>>>>> I have the module in the my Roadster, and the v.p.speed metric comes up
>>>>> as 0 kph (that's good - it's parked), but the power metric isn't
>>>>> provided by the car, so is blank when listing the metrics.  I expected
>>>>> the code to return zero.
>>>>> 
>>>>> Instead, executing the script by asking for 'obdii ecu list' causes an
>>>>> immediate crash with a stack overflow in task AsyncConsole.  If I
>>>>> initialize the power metric by hand (metric set v.b.power 0), the script
>>>>> runs just fine, returning 0 for the metric.
>>>>> 
>>>>> Oddly, when I first set it up on the desk (sans vehicle), so both of the
>>>>> metrics were blank, executing the script didn't cause crash.
>>>>> 
>>>>> Is there a way to make the code "Roadster safe", without dummying up the
>>>>> metric in, say, a startup script?  Better, is there a fix for DukTape to
>>>>> handle this, or should I just increase the stack size in AsyncConsole?
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Greg
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180329/7853ada4/attachment.htm>