Thanks Takashi,
All great for the last week on 1.4.7-3 - still running thru CPU hogging builds
using 100% of the system and quiet times ~2%!
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
On 2026-09-06 05:38, Takashi Yano via Cygwin wrote:
Hi Brian,
On Fri, 4 Sep 2026 10:44:51 -0600
Brian Inglis wrote:
On 2026-09-03 14:58, Takashi Yano via Cygwin wrote:
Hi Brian,
On Wed, 2 Sep 2026 12:52:53 -0600
Brian Inglis wrote:
On 2026-09-02 00:50, Takashi Yano via Cygwin wrote:
On Tue, 1 Sep 2026 23:24:27 -0600
Brian Inglis wrote:
Now with btop 1.4.7 it is less obvious when it freezes, as the info panes become
static, while the time display keeps updating, whereas in the previous release,
the time display also froze, making the need for a restart more obvious.
Thanks for the report. Two questions.
(1) When btop freezes, are all the info panes stopped,
while the time on the top middle is updating?
As far as I can tell, nothing else, other than the top middle timestamp (update
period 60000ms), is being obviously updated e.g. uptime freezes.
(2) How often the issue happens?
It happens every few days: Cygwin services run continuously between Cygwin Setup
upgrade runs or Windows patch restarts (the weekend before Patch Tuesdays).
I stay logged in running Xwin between those Cygwin startups.
Are there any error messages in ~/.local/state/btop.log?
Ah - didn't know about that: attached log entries since just before the upgrade
from 1.4.5 to 1.4.7, then -2 on Sep 3.
Now going to download and install -3 and keep an eye on that log.
2026/08/10 (02:33:15) | ERROR: Stall in Runner thread, restarting!
2026/08/11 (22:02:06) | ERROR: Stall in Runner thread, restarting!
2026/08/13 (12:14:06) | ERROR: Stall in Runner thread, restarting!
These are the problem that Claude expected. The mechanism of
the freeze is as follows.
(1) Due to high load of the system, the runner thread in btop
sometimes does not respond in predetermined period.
(2) If the main thread detects that runner thread hang, it
calls pthread_cancel() for runner thread to restart the
thread.
(3) However, if the runner thread holds a mutex, the thread
is cancelled without releasing mutex.
(4) The new runner thread freezes because it cannot acquire
the mutex.
On Linux, If the thread holding c++ mutex is cancelled, the
mutex is released in the unwinding process. However, cygwin
does not do that (POSIX does not require that).
1.4.7-3 do not call pthread_cancel() even when the response
from the runnder thread is delayed. Instead, simply skips
updating panes. Hopefully, 1.4.7-3 no longer suffers from
the issue.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
