<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
It seems we've got another mutex issue in duktape:<br>
<br>
<tt>OVMS# mo ta</tt><tt><br>
</tt><tt>Number of Tasks = 22 Stack: Now Max Total Heap
32-bit SPIRAM C# PRI CPU% BPR/MH</tt><tt><br>
</tt><tt>3FFAFB88 1 Blk esp_timer 436 708 4096
40288 644 31232 0 22 0% 22/ 0</tt><tt><br>
</tt><tt>3FFC0E90 2 Blk eventTask 476 1884 4608
104 0 0 0 20 0% 20/ 0</tt><tt><br>
</tt><tt>3FFC3314 3 Blk OVMS Events 704 3360 8192
92364 0 35464 1 8 1% 8/ 0</tt><tt><br>
</tt><tt>3FFC6764 4 Rdy OVMS DukTape 496 10864 12288
580 0 189492 1 3 10% 3/<u><b>42</b></u></tt><br>
<br>
…increasing once per minute. I'll have a look.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 24.07.20 um 15:27 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:a626d302-802c-0e3b-71b0-d1b5cbc02a91@expeedo.de">
<pre class="moz-quote-pre" wrap="">TL;DR: you need to pull my latest esp-idf changes.
I've finally found & solved the strange priority changes for our
netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the
bug was in the esp-idf posix threads mutex implementation.
I had suspected the mutex priority inheritance for a while, so added a
way to retrieve the internal mutex hold count for our task list. Using
this I noticed the hold count would always & only raise by 2 whenever
any kind of mongoose connection was closed.
That lead me to checking the thread concurrency protection for mongoose
mbufs, because every mongoose connection has two mbufs associated (rx &
tx), each having a posix mutex.
The bug was: posix mutexes were deleted after locking (taking) them.
FreeRTOS mutexes must not be deleted while being taken, that breaks the
priority inheritance (more precisely the disinheritance), with the
visible effect being the mutex hold count not returning to zero.
As a side effect, this may also solve the strange event task starvations
(hope so…). I was investigating this as I suspected some busy loop in
the netmanager context. With the netman running at prio 22, that would
effectively block almost all other processing including the timer
service. I've found & fixed one potential busy loop trigger in the
netman that would have been caused by the netman task still running
while all interfaces had been lost -- not sure if that could happen, but
it would explain the effects.
So please watch your crash debug info & report if the issue still turns up.
Regards,
Michael
</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>