[Ovmsdev] Duktape handling of blank metrics?

[Greg D.]

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