Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Ben Gladstone]

Whoops forgot reply-all again:

I downloaded the source code and have been looking through it a bit and I
think I'm onto something. I noticed that it's not just F5 that causes the
problem but any keypress whose handler returns HTOP_SAVE_SETTINGS.

Then, it seems that eventually Header_writeBackToSettings() in Header.c is
called. This function has an if statement which decides whether to write a
"%s(%d)" or just a "%s" for each meter... This looks suspiciously like
something that would cause the problem we're seeing. I don't know enough
about the code to know what exactly is wrong, but I think I found where to
look!

On Thu, Jun 15, 2017 at 1:16 AM, Ben Gladstone 
wrote:

> Ah you're right! I hadn't tried it via the setup menu but it's behaving
> the same way for me that it is for you. Definitely has something to do with
> F5. Thanks, I'm curious to see what it turns out to be
>
> On Jun 15, 2017 1:11 AM, "Daniel Lange"  wrote:
>
>> Am 15.06.2017 um 02:00 schrieb Ben Gladstone:
>> > I agree it's really strange and it doesn't make sense to me either why
>> > it would be doing that. I thought maybe it had something to do with my
>> > F5 key, maybe if there was another keybinding I forgot about. But nope,
>> > it has the same behavior when I use the mouse to click on tree mode too.
>> > I'll play around with it and see if I can get a clearer picture on the
>> > conditions that cause it
>>
>> Pressing F5 is the critical hint. I changed tree view view the Setup
>> menu and then you don't see that behaviour. But changing with F5 I can
>> reproduce it as well. Very strange!
>> I'll forward upstream.
>>
>>

Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Ben Gladstone]

Ah you're right! I hadn't tried it via the setup menu but it's behaving the
same way for me that it is for you. Definitely has something to do with F5.
Thanks, I'm curious to see what it turns out to be

On Jun 15, 2017 1:11 AM, "Daniel Lange"  wrote:

> Am 15.06.2017 um 02:00 schrieb Ben Gladstone:
> > I agree it's really strange and it doesn't make sense to me either why
> > it would be doing that. I thought maybe it had something to do with my
> > F5 key, maybe if there was another keybinding I forgot about. But nope,
> > it has the same behavior when I use the mouse to click on tree mode too.
> > I'll play around with it and see if I can get a clearer picture on the
> > conditions that cause it
>
> Pressing F5 is the critical hint. I changed tree view view the Setup
> menu and then you don't see that behaviour. But changing with F5 I can
> reproduce it as well. Very strange!
> I'll forward upstream.
>
>

Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Daniel Lange]

Am 15.06.2017 um 02:00 schrieb Ben Gladstone:
> I agree it's really strange and it doesn't make sense to me either why
> it would be doing that. I thought maybe it had something to do with my
> F5 key, maybe if there was another keybinding I forgot about. But nope,
> it has the same behavior when I use the mouse to click on tree mode too.
> I'll play around with it and see if I can get a clearer picture on the
> conditions that cause it

Pressing F5 is the critical hint. I changed tree view view the Setup
menu and then you don't see that behaviour. But changing with F5 I can
reproduce it as well. Very strange!
I'll forward upstream.

Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Ben Gladstone]

Well I'm 99% sure it's not just my setup now: I was able to reproduce the
bug on a fresh virtual machine of Debian. Here's my procedure:

1. Install Debian Jessie in a virtual machine with 4 CPU cores
2. Install htop from Jessie repository
3. Add jessie-backports repo to /etc/apt/sources.list
4. apt update && apt -t jessie-backports install htop (upgrade htop
to 2.0.2-1~bpo8+1)
5. rm ~/.config/htop/htoprc
6. Open htop, don't change anything, quit (regenerate a fresh htoprc)
7. Open htop, add CPU 1, CPU 2, CPU 3, CPU 4 meters, quit htop, reopen and
verify meters are still there (yup they are fine)
8. Toggle tree view, quit htop
9. Reopen htop and CPU1-4 meters have changed into CPU AVG meters. Double
check in htoprc and notice that every instance of "CPU(n)" has changed to
just "CPU"

I have no idea why tree view would have anything to do with that, but it
seems like when it goes to rewrite htoprc for some reason it forgets about
the "(1)" part and just prints "CPU".

I busted out strace to see this happening in action. Here's htop writing to
htoprc when creating a fresh htoprc:

write(3, "# Beware! This file is rewritten
> by htop when settings are changed in the interface.\n# The parser is also
> very primitive, and not human-friendly.\nfields=0 48 17 18 38 39 40 2 46 47
> 49 1
> \nsort_key=46\nsort_direction=1\nhide_threads=0\nhide_kernel_threads=1\nhide_userland_threads=0\nshadow_other_users=0\nshow_thread_names=0\nshow_program_path=1\nhighlight_base_name=0\nhighlight_megabytes=1\nhighlight_threads=1\ntree_view=0\nheader_margin=1\ndetailed_cpu_time=0\ncpu_count_from_zero=0\nupdate_process_names=0\naccount_guest_in_cpu_meter=0\ncolor_scheme=0\ndelay=15\nleft_meters=AllCPUs
> Memory Swap \nleft_meter_modes=1 1 1 \nright_meters=Tasks LoadAverage
> Uptime \nright_meter_modes=2 2 2 \n", 669) = 669


Here's the trace upon adding the CPU1-4 meters:

> write(3, "# Beware! This file is rewritten
> by htop when settings are changed in the interface.\n# The parser is also
> very primitive, and not human-friendly.\nfields=0 48 17 18 38 39 40 2 46 47
> 49 1
> \nsort_key=46\nsort_direction=1\nhide_threads=0\nhide_kernel_threads=1\nhide_userland_threads=0\nshadow_other_users=0\nshow_thread_names=0\nshow_program_path=1\nhighlight_base_name=0\nhighlight_megabytes=1\nhighlight_threads=1\ntree_view=0\nheader_margin=1\ndetailed_cpu_time=0\ncpu_count_from_zero=0\nupdate_process_names=0\naccount_guest_in_cpu_meter=0\ncolor_scheme=0\ndelay=15\nleft_meters=AllCPUs
> Memory Swap \nleft_meter_modes=1 1 1 \nright_meters=Tasks LoadAverage
> Uptime CPU(1) CPU(2) CPU(3) CPU(4) \nright_meter_modes=2 2 2 1 1 1 1 \n",
> 705) = 705


Finally here's the trace after toggling tree view:

> write(3, "# Beware! This file is rewritten
> by htop when settings are changed in the interface.\n# The parser is also
> very primitive, and not human-friendly.\nfields=0 48 17 18 38 39 40 2 46 47
> 49 1
> \nsort_key=46\nsort_direction=1\nhide_threads=0\nhide_kernel_threads=1\nhide_userland_threads=0\nshadow_other_users=0\nshow_thread_names=0\nshow_program_path=1\nhighlight_base_name=0\nhighlight_megabytes=1\nhighlight_threads=1\ntree_view=1\nheader_margin=1\ndetailed_cpu_time=0\ncpu_count_from_zero=0\nupdate_process_names=0\naccount_guest_in_cpu_meter=0\ncolor_scheme=0\ndelay=15\nleft_meters=AllCPUs
> Memory Swap \nleft_meter_modes=1 1 1 \nright_meters=Tasks LoadAverage
> Uptime CPU CPU CPU CPU \nright_meter_modes=2 2 2 1 1 1 1 \n", 693) = 693


This doesn't tell us much we didn't already know, except that it proves
that it actually is htop modifying the file like that and not some other
program. The big question is still: why?

This is a super goofy issue and isn't really making sense but I have been
able to replicate it on a different system so I'm pretty sure it's not just
me. Any ideas what else we could check for leads?

On Wed, Jun 14, 2017 at 5:00 PM, Ben Gladstone 
wrote:

> I agree it's really strange and it doesn't make sense to me either why it
> would be doing that. I thought maybe it had something to do with my F5 key,
> maybe if there was another keybinding I forgot about. But nope, it has the
> same behavior when I use the mouse to click on tree mode too. I'll play
> around with it and see if I can get a clearer picture on the conditions
> that cause it
>
>
> On Jun 14, 2017 9:01 AM, "Daniel Lange"  wrote:
>
> O.k., so the htoprc files show exactly what you described in prose.
>
> Unfortunately(?) it works for me in Jessie, I installed the same
> backports-kernel that you have etc. Can't reproduce.
>
> The config file reading logic doesn't look like it could drop "(1)"
> either. And it doesn't care about tree mode or not for the meters.
>
> I hope somebody sees the same odd behaviour and can shed some light on
> this.
>
>
>

Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Ben Gladstone]

I agree it's really strange and it doesn't make sense to me either why it
would be doing that. I thought maybe it had something to do with my F5 key,
maybe if there was another keybinding I forgot about. But nope, it has the
same behavior when I use the mouse to click on tree mode too. I'll play
around with it and see if I can get a clearer picture on the conditions
that cause it

On Jun 14, 2017 9:01 AM, "Daniel Lange"  wrote:

O.k., so the htoprc files show exactly what you described in prose.

Unfortunately(?) it works for me in Jessie, I installed the same
backports-kernel that you have etc. Can't reproduce.

The config file reading logic doesn't look like it could drop "(1)"
either. And it doesn't care about tree mode or not for the meters.

I hope somebody sees the same odd behaviour and can shed some light on this.

Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Daniel Lange]

O.k., so the htoprc files show exactly what you described in prose.

Unfortunately(?) it works for me in Jessie, I installed the same
backports-kernel that you have etc. Can't reproduce.

The config file reading logic doesn't look like it could drop "(1)"
either. And it doesn't care about tree mode or not for the meters.

I hope somebody sees the same odd behaviour and can shed some light on this.

Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Ben Gladstone]

Whoops forgot to hit reply-all, resending:

Alright I just tried that and I'm still seeing the strange behavior. I
deleted htoprc and opened htop, then quit. I've attached the htoprc file it
created as "htoprc.start"

Then, I reopened htop and added a "CPU 1" meter, then quit htop. I've
attached the htoprc at this stage as "htoprc.cpu1". I reopened htop to make
sure it was still there, and it was fine.

Then, I toggled tree view on and quit htop. Upon reopening htop, the "CPU
1" meter had changed to a "CPU AVG" meter. I've attached the htoprc from
this stage as "htoprc.aftertreeview".

For some reason it changed the meter entry "CPU(1)" into just "CPU" upon
entering tree view. I'm not sure if tree view is the only thing that causes
this to happen, but it's the only time I've noticed it so far.

Let me know if there's any other information about my system configuration
that would be useful.

On Tue, Jun 13, 2017 at 12:46 PM, Daniel Lange  wrote:

> Control: severity -1 minor
>
> Hi Ben,
>
> thanks a lot for submitting the bug report.
> I can't verify the issue here. I can create and persist a "CPU 2" meter
> all I want and it shows up independent of tree view or not.
>
> Could you look at .config/htop/htoprc and possibly move that out of the
> way so htop creates a fresh one. Does that "fix" the issue?
>
> Kind regards,
> Daniel
>
>
>


htoprc.aftertreeview
Description: Binary data


htoprc.cpu1
Description: Binary data


htoprc.start
Description: Binary data

Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Daniel Lange]

Control: severity -1 minor

Hi Ben,

thanks a lot for submitting the bug report.
I can't verify the issue here. I can create and persist a "CPU 2" meter
all I want and it shows up independent of tree view or not.

Could you look at .config/htop/htoprc and possibly move that out of the
way so htop creates a fresh one. Does that "fix" the issue?

Kind regards,
Daniel

Bug#864336: htop replaces CPU1/2/3/4/5/6/7/8 meter with CPU AVG meter after switching to tree view, quitting, and reopening

[Ben Gladstone]

Package: htop
Version: 2.0.2-1~bpo8+1
Severity: normal

Dear Maintainer,

I noticed this bug upon upgrading from htop in Debian stable to htop in Debian 
jessie-backports.

In the version in stable, there wasn't a meter for "All CPUs", so I built my 
own by adding meters
for CPU1,2,3,4,5,6,7,8 all in one column. This worked great. Then, I upgraded 
to the version in jessie-backports.

After a few days, I noticed that my CPU meters had been replaced by 8 CPU AVG 
meters that all moved in sync, rather than
individual meters for each CPU. I replaced them with individual CPU meters and 
quit htop, and when I came back they were still there.

Then, I switched htop to tree view and quit. Now upon reopening: all my meters 
have been replaced with CPU AVG meters again.
I "fixed" the problem by just using the new "All CPUs" meter instead, but I 
experimented by adding one "CPU 2" meter. If I don't 
toggle tree view, the meter remains as-is between different runs of htop. 
However, when I toggle tree view, quit, and reopen htop, 
the meter has once again been replaced with a CPU AVG meter. This happens 
consistently.

This is my first ever bug report to any debian package so sorry if there's any 
standard protocol I left out.
Let me know if you need any more information!

Thanks,
Ben

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages htop depends on:
ii  libc6 2.19-18+deb8u9
ii  libncursesw5  5.9+20140913-1+b1
ii  libtinfo5 5.9+20140913-1+b1

htop recommends no packages.

Versions of packages htop suggests:
ii  lsof4.86+dfsg-1
ii  strace  4.9-2

-- no debconf information