btop 1.4.7 info panes freeze

[Brian Inglis]

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.