[Ovmsdev] Duktape handling of blank metrics?
Mark Webb-Johnson
mark at webb-johnson.net
Thu Mar 29 11:36:12 HKT 2018
Greg,
> ... looks like it needs an additional 512 bytes. Dropping to an increment of 256 bytes, 21*256 didn't do it, 22*256 did.
I suggest 6144. That is what the others use.
> And, why is the script running from obd2ecu causing the async console to fall over?
To show the value it executes the script. That needs stack.
Regards, Mark.
> On 29 Mar 2018, at 10:29 AM, Greg D. <gregd2350 at gmail.com> wrote:
>
> ... looks like it needs an additional 512 bytes. Dropping to an increment of 256 bytes, 21*256 didn't do it, 22*256 did.
>
> How much above that is needed for safety? And, why is the script running from obd2ecu causing the async console to fall over? The output from the script is no different than a regular line generated from a regular metric.
>
> Greg
>
>
> Greg D. wrote:
>> Thanks for the analysis. module tasks isn't working, but I'll do some tests to get an approximate limit.
>>
>> Please get some "day job" stuff done - this isn't time critical.
>>
>> Greg
>>
>>
>> Mark Webb-Johnson wrote:
>>> 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 <mailto: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 <mailto:greg at linux-0rpb:%7E/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 <mailto:greg at linux-0rpb:%7E/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 <mailto: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 <mailto: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 <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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/36bcc751/attachment.htm>
More information about the OvmsDev
mailing list