<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I think I've found & fixed this, maybe also the events
starvation issue.<br>
<br>
See <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/418#issuecomment-683286134">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/418#issuecomment-683286134</a><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/418"></a><br>
<br>
and <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/6b709a0cb399d1a7c3866f68d7f9dbf92f9246c8">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/6b709a0cb399d1a7c3866f68d7f9dbf92f9246c8</a><br>
<br>
Please test.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 29.08.20 um 10:34 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:055865ed-a1f9-f0a4-d9b0-229055366c01@expeedo.de">
<pre class="moz-quote-pre" wrap="">I've just found another clue to the events task starvations:
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/418">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/418</a>
TL;DR: the events task can be blocked by running lower priority tasks as
well, not just higher priority tasks.
So raising the events task priority cannot be the solution.
Regards,
Michael
Am 26.08.20 um 20:28 schrieb Michael Balzer:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Am 26.08.20 um 06:17 schrieb Mark Webb-Johnson:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">It seems to be a web socket (web ui?) connection went away, a logging
message was produced, and that overflowed the queue. Perhaps the user
is just logging too much? Can you log at debug level to web uI (or
does it cause the problem I mentioned earlier about debug logging the
debug logs)? Any ideas?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I haven't been able to get a correlation to any specific configuration
or system situation yet on these event queue overflows.
The event queue has room for 40 entries by default, so the system
normally has been in an overload situation (starved event task) for at
least 30-40 seconds when the abort is triggered.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Event: ticker.1@EventScript 0 secs
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">…tells the events task wasn't completely stuck before the abort, just
didn't get a lot of CPU share. That's why I thought raising the task
priority could have an effect.
I totally need user data on this, as the crash doesn't happen at all on
my module. So it's also possible the issue is caused by a vehicle module
bug, or by the poller receive bug we discovered a few days ago:
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/405#issuecomment-674499551">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/405#issuecomment-674499551</a>
This is solved now by the merge of the fast polling branch, which
includes the fixes for this. So we may see already an improvement with
the next build.
But there are at least three more bugs/shortcomings in the current
poller which can potentially also cause this issue (and others) by high
vehicle task load / wrong memory allocations / out of bounds accesses.
Which is why I'm currently working on a rewrite of the receiver.
Regards,
Michael
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>