[Ovmsdev] Branch for-v3.3 network issues

Michael Balzer dexter at expeedo.de
Sat Sep 18 23:28:12 HKT 2021


Craig,

Am 18.09.21 um 00:14 schrieb Craig Leres:
> On 9/17/21 12:24 AM, Michael Balzer wrote:
>> Duktape still occasionally runs into the null/undefined issue with 
>> for…in:
>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/474#issuecomment-744005044 
>>
>> We need to test the revision 3 ESP32 on this.
>
> What can I do to test this on my frankenstein v3 module?

Here's a simple test that reliably reproduces the effect on my modules:

 1. Setup handler loop: script eval 'PubSub.subscribe("usr.testev",
    function(ev) { var ms=Number(ev.substr(11))||10;
    OvmsEvents.Raise("usr.testev."+ms, ms); })'
 2. Start event loop with 10 ms interval: event raise usr.testev.10

The handler will keep raising the same event with the given interval. 
You can monitor the events by settingt log level debug on events or 
using the event tracing (event trace on/off), be aware 10 ms will flood 
your terminal/shell. Check the Duktape CPU usage to see if the loop is 
still running without enabling the event log.

The loop _should_ normally run indefinitely. To stop it manually, you 
would do: script eval 'PubSub.unsubscribe("usr.testev")'

In reality, it will abort after some random run time with a log entry 
like this:

E (1803740) ovms-duktape: [int/PubSub.js:1] TypeError: not object 
coercible|    at [anon] (duk_api_stack.c:3661) internal|    at hasKeys 
(int/PubSub.js:1) strict|    at messageHasSubscribers (int/PubSub.js:1) 
strict| at publish (int/PubSub.js:1) strict|    at [anon] 
(int/PubSub.js:1) strict preventsyield

…or (newly discovered today) with a heap corruption crash, which may 
have another cause though (investigating).

If it stops with the "TypeError", the loop should be restartable simply 
by repeating step 2. That proves the PubSub handler setup is still intact.

The time it needs to run into the TypeError varies widely and has some 
dependance on how many other handlers are registered. With no other 
javascript handlers registered, it normally takes 15-30 minutes on my 
modules to run into the error. With AuxBatMon, PwrMon & Edimax plugins 
enabled, it will normally happen within 5 minutes, sometimes within a 
few seconds.

The interval is basically irrelevant, the effect just comes faster with 
a short interval.

Regards,
Michael

PS: btw, the effect occurs with Duktape running in the upper 2 MB as 
well. That doesn't prove it's not the SPIRAM bug though, it just may 
have other trigger conditions.

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210918/7270304a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210918/7270304a/attachment.sig>


More information about the OvmsDev mailing list