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</home/ben/.config/htop/htoprc>, "# 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</home/ben/.config/htop/htoprc>, "# 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</home/ben/.config/htop/htoprc>, "# 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 <[email protected]> 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" <[email protected]> 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. > > >
