[Ovmsdev] Duktape handling of blank metrics?

[Mark Webb-Johnson]

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