htop 3.1.2 crashes on FreeBSD 14 (current, c 20220316, 2022402) while things are being compiled

htop 3.1.2 crashes after some time (every time) at least whenever something is being compiled on Framework laptop with Intel i5-1135G7 CPU & 32 GB RAM.

Crash happened while ...

• building world;
• compiling ports/net/wifibox;
• compiling ports/devel/binutils.

uname -a
FreeBSD luna 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n254246-6833ac673d9: Sat Apr 2 15:37:22 HST 2022 root@luna:/build/world/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG amd64

Edited captured output via script(1) ...

...
FATAL PROGRAM ERROR DETECTED

Please check at https://htop.dev/issues whether this issue has already been reported.
If no similar issue has been reported before, please create a new issue with the following information:

• Your htop version: '3.1.2'
• Your OS and kernel version (uname -a)
• Your distribution and release (lsb_release -a)
• Likely steps to reproduce (How did it happen?)
• Backtrace of the issue (see below)

Error information:

A signal 6 (Abort trap) was received.

Setting information:

htop_version=3.1.2;config_reader_min_version=2;fields=48 3 0 46 47 39 49 20 53 6 18 2 99 1;sort_key=20;sort_direction=1;tree_sort_key=0;tree_sort_direction=1;hide_kernel_threads=1;hide_userland_threads=0;shadow_other_users=0;show_thread_names=0;show_program_path=1;highlight_base_name=1;highlight_deleted_exe=1;highlight_megabytes=1;highlight_threads=1;highlight_changes=0;highlight_changes_delay_secs=5;find_comm_in_cmdline=1;strip_exe_from_cmdline=1;show_merged_command=0;tree_view=0;tree_view_always_by_pid=0;all_branches_collapsed=0;header_margin=0;detailed_cpu_time=0;cpu_count_from_one=0;show_cpu_usage=1;show_cpu_frequency=1;show_cpu_temperature=0;degree_fahrenheit=0;update_process_names=0;account_guest_in_cpu_meter=0;color_scheme=6;enable_mouse=1;delay=15;hide_function_bar=0;header_layout=two_50_50;column_meters_0=LoadAverage AllCPUs2 MemorySwap ZFSCARC ZFSARC;column_meter_modes_0=2 1 1 2 2;column_meters_1=System Hostname Uptime DateTime Battery DiskIO NetworkIO;column_meter_modes_1=2 2 2 2 2 2 2;

Backtrace information:

0: 0x21c842 /usr/local/bin/htop (CRT_handleSIGSEGV+0x102) [0x21c842]
1: 0x8270aa5a0 /lib/libthr.so.3 (_fini+0) [0x8270aa4d0]
2: 0x8270a9b5f /lib/libthr.so.3 (_fini+0) [0x8270a9a20]
3: 0x7ffffffff2d3 ? (+0) [0x7ffffffff2d0] {signal frame}
4: 0x82448edfa /lib/libc.so.7 (_fini+0) [0x82448edf0] {signal frame}
5: 0x8270a9a20 /lib/libthr.so.3 (_fini+0) [0x8270a9890]

To make the above information more practical to work with, please also provide a disassembly of your htop binary. This can usually be done by running the following command:

objdump -d -S -w which htop > ~/htop.objdump
...

I will attach "objdump" output & backtrace. For future, is backtrace needed when "objdump" output is also provided?

htop.objdump.txt
htop.gdb.bt-full.txt

[grahamperrin]

Cross-reference: FreeBSD bug 263024 – sysutils/htop: 3.1.2 crashes on 14.0-CURRENT while compiling things

No crashing here.

% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n253861-92e6b4712b5-dirty: Sat Mar 19 02:40:21 GMT 2022     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400053 1400053
% pkg query %v htop poudriere-devel
3.1.2
3.3.99.20211130
% pkg -vv | grep -e url -e enabled
    url             : "pkg+http://pkg0.pkt.freebsd.org/FreeBSD:14:amd64/latest",
    enabled         : yes,
    url             : "https://alpha.pkgbase.live/current/FreeBSD:14:amd64/latest",
    enabled         : no,
    url             : "file:///usr/local/poudriere/data/packages/main-default",
    enabled         : yes,
% 

• main-n253861-92e6b4712b5-dirty is https://cgit.freebsd.org/src/log/?qt=range&q=92e6b4712b5 from 2022-03-19.

From a run of poudriere yesterday, where (at a glance) a run of htop began 45 minutes earlier:

load: 15.76  cmd: awk 62561 [runnable] 0.05r 0.00u 0.00s 0% 460k
mi_switch+0xc2 kern_yield+0x59 uiomove_faultflag+0x10c dmu_read_uio_dnode+0xa3 dmu_read_uio_dbuf+0x3b zfs_read+0x1da zfs_freebsd_read+0x44 VOP_READ_APV+0x1f vn_read+0x1e8 vn_io_fault_doio+0x43 vn_io_fault1+0x15c vn_io_fault+0x1b0 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 
[main-default] [2022-04-02_16h47m20s] [parallel_build:] Queued: 155 Built: 73  Failed: 0   Skipped: 0   Ignored: 0   Fetched: 15  Tobuild: 67   Time: 08:18:58
 ID  TOTAL                ORIGIN   PKGNAME                    PHASE PHASE    TMPFS      CPU% MEM%
[01] 08:17:54       devel/llvm13 | llvm13-13.0.1_1            build 08:11:59 3.87 GiB 100.4%   5%
[02] 05:01:41       devel/llvm90 | llvm90-9.0.1_5             build 04:56:47 2.63 GiB  84.5% 5.1%
[03] 06:27:40       devel/llvm12 | llvm12-12.0.1_8            build 06:19:37 3.42 GiB 102.2%   3%
[04] 00:07:52 textproc/libe-book | libe-book-0.1.3_22 build-depends 00:07:36 3.65 GiB  19.1% 2.6%

2022-04-02 16-47 poudriere, libreoffice.txt

[grahamperrin]

@Parv FYI https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#quoting-code

[BenBE]

htop 3.1.2 crashes after some time (every time) at least whenever something is being compiled on Framework laptop with Intel i5-1135G7 CPU & 32 GB RAM.

Let's see …

Crash happened while ...

• building world;
• compiling ports/net/wifibox;
• compiling ports/devel/binutils.

Thus likely while many short-lived processes where active …

uname -a FreeBSD luna 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n254246-6833ac673d9: Sat Apr 2 15:37:22 HST 2022 root@luna:/build/world/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG amd64

Edited captured output via script(1) ...

...

FATAL PROGRAM ERROR DETECTED
Please check at https://htop.dev/issues whether this issue has already been reported. If no similar issue has been reported before, please create a new issue with the following information:

• Your htop version: '3.1.2'
• Your OS and kernel version (uname -a)
• Your distribution and release (lsb_release -a)
• Likely steps to reproduce (How did it happen?)
• Backtrace of the issue (see below)

Error information:

A signal 6 (Abort trap) was received.

Setting information:

Settings look okay …

Backtrace information:

0: 0x21c842 /usr/local/bin/htop (CRT_handleSIGSEGV+0x102) [0x21c842]
1: 0x8270aa5a0 /lib/libthr.so.3 (_fini+0) [0x8270aa4d0]
2: 0x8270a9b5f /lib/libthr.so.3 (_fini+0) [0x8270a9a20]
3: 0x7ffffffff2d3 ? (+0) [0x7ffffffff2d0] {signal frame}
4: 0x82448edfa /lib/libc.so.7 (_fini+0) [0x82448edf0] {signal frame}
5: 0x8270a9a20 /lib/libthr.so.3 (_fini+0) [0x8270a9890]

This looks absolutely strange, as there is no actual frame referencing the htop binary except for the actual signal handler. But given all the available symbols reference _fini, i.e. the program finalizers, the missing frame seems to also relate to program/thread shutdown somehow.

To make the above information more practical to work with, please also provide a disassembly of your htop binary. This can usually be done by running the following command:

objdump -d -S -w which htop > ~/htop.objdump ...

I will attach "objdump" output & backtrace. For future, is backtrace needed when "objdump" output is also provided?

The objdump is usually used to cross-reference the addresses of the backtrace to the actual source location. If the backtrace you provide references the actual code files+lines in the htop source you can skip the objdump. The reason the default output of our crash reporter asks for it is that on most systems people don't have the source available and debug symbols aren't usually installed either. Thus given the disassembly from the objdump and the backtrace is usually sufficient to cross-reference the actual source code for a given crash location (Due to inlining you can't usually trust the function name given in the backtrace for some functions).

[BenBE]

The backtrace from the GDB log looks interesting: In contrasts the backtrace from htop itself and gives some valuable additional information:

#0  thr_kill () at thr_kill.S:4
No locals.
#1  0x00000008244071f4 in __raise (s=6) at /freebsd/src/lib/libc/gen/raise.c:52
        id = 102132
#2  0x000000000021c8fb in CRT_handleSIGSEGV (signal=6) at CRT.c:1157
        signal_str = 0x824760960 "Abort trap"
#3  0x00000008270aa5a0 in handle_signal (actp=actp@entry=0x8205bb8c0, sig=sig@entry=6, info=info@entry=0x8205bbcb0, 
    ucp=ucp@entry=0x8205bb940) at /freebsd/src/lib/libthr/thread/thr_sig.c:303
        uc2 = {uc_sigmask = {__bits = {542881151, 8, 542881063, 8}}, uc_mcontext = {mc_onstack = 493921239077, mc_rdi = 64, 
            mc_rsi = 72057731476881447, mc_rdx = 34969159160, mc_rcx = 7189417373815731229, mc_r8 = 32768, mc_r9 = 35037120896, 
            mc_rax = 64, mc_rbx = 34903019664, mc_rbp = 0, mc_r10 = 34902619568, mc_r11 = 34968975693, mc_r12 = 180388626478, 
            mc_r13 = 201863462948, mc_r14 = 7189417373815731229, mc_r15 = 2369584, mc_trapno = 542917488, mc_fs = 8, mc_gs = 0, 
            mc_addr = 34903019664, mc_flags = 34783, mc_es = 0, mc_ds = 0, mc_err = 32768, mc_rip = 34902619696, mc_cs = 34968757136, 
            mc_rflags = 472446402665, mc_rsp = 154618822688, mc_ss = 416611827827, mc_len = 34903020160, mc_fpformat = 468151435359, 
            mc_ownedfp = 34902619728, mc_fpstate = {…}, mc_fsbase = 450971566127, mc_gsbase = 438086664302, 
            mc_xfpustate = 201863463023, mc_xfpustate_len = 493921239137, mc_spare = {450971566126, 438086664302, 146028888175, 
              450971566112}}, uc_link = 0x200000006e, uc_stack = {ss_sp = 0x2000000020, ss_size = 180388626479, ss_flags = 41}, 
          uc_flags = 102, __spare__ = {105, 108, 101, 61}}
        curthread = 0x8290a3000
        in_sigsuspend = 0
        cancel_enable = 1
        cancel_point = 0
        sigfunc = 0x0
        err = <optimized out>
        cancel_async = <optimized out>
#4  0x00000008270a9b5f in thr_sighandler (sig=6, info=0x8205bbcb0, _ucp=0x8205bb940) at /freebsd/src/lib/libthr/thread/thr_sig.c:246
        act = {__sigaction_u = {__sa_handler = 0x21c740 <CRT_handleSIGSEGV>, __sa_sigaction = 0x21c740 <CRT_handleSIGSEGV>}, sa_flags = 20, 
          sa_mask = {__bits = {2147417823, 4294967295, 4294967295, 4294967295}}}
        err = <optimized out>
        curthread = 0x8290a3000
        ucp = <optimized out>
        usa = <optimized out>
#5  <signal handler called>
No symbol table info available.
#6  thr_kill () at thr_kill.S:4
No locals.
#7  0x00000008244071f4 in __raise (s=s@entry=6) at /freebsd/src/lib/libc/gen/raise.c:52
        id = 102132
#8  0x00000008244b8be9 in abort () at /freebsd/src/lib/libc/stdlib/abort.c:67
        act = {__sigaction_u = {__sa_handler = 0x82911404c, __sa_sigaction = 0x82911404c}, sa_flags = 0, sa_mask = {__bits = {4294967263, 
              4294967295, 4294967295, 4294967295}}}
#9  0x0000000000238a5e in fail () at XUtils.c:26
No locals.
#10 0x00000000002395b8 in xSnprintf (buf=0x8205bc81e "155445687", len=10, fmt=0x203609 "%3dy") at XUtils.c:248
        vl = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x8205bc7b0, reg_save_area = 0x8205bc6b0}}
        n = 11
#11 0x000000000022a698 in Process_printTime (str=0x8205c1a50, totalHundredths=18446744073709551537, coloring=true) at Process.c:215
        years = 1554456877
        daysLeft = 201
        buffer = "155445687"
        len = 256
        totalSeconds = 184467440737095515
        hours = 51240955760304
        days = 2135039823346
        minutes = 18
        seconds = 35
        hundredths = 37
        yearColor = 2109440
        dayColor = 10240
        hourColor = 2048
        defColor = 0
#12 0x000000000022d7f7 in Process_writeField (this=0x829225480, str=0x8205c1a50, field=ELAPSED) at Process.c:871
        buffer = "19:24 \000\000/$#\000\000\000\000\000 \000\000\000 \000\000\000 \000\000\000 \000\000\000\060\000\000\000 ", '\000' <repeats 11 times>, "\006\000\000\000 \000\000\000t#\\ \b\000\000\000\334\311[ \b\000\000\000P\311[ \b\000\000\000\006\000\000\000T\000\000\000T\000\000\000\001\000\000\000\a\000\000\000\000\000\000\000p\311[ \b\000\000\000\006\000\000\000N\000\000\000\260\312[ \b", '\000' <repeats 11 times>, "P\032\\ \b\000\000\000\000\000\000\000\006\000\000\000\000\000\000\000 ", '\000' <repeats 27 times>, "\035\364N\244\002\361\305cP\312[ \b\000\000\000"...
        n = 256
        attr = 0
        coloring = true
#13 0x000000000023c865 in FreeBSDProcess_writeField (this=0x829225480, str=0x8205c1a50, field=ELAPSED) at freebsd/FreeBSDProcess.c:81
        fp = 0x829225480
        buffer = …
        n = 256
        attr = 0
#14 0x000000000022e181 in Process_display (cast=0x829225480, out=0x8205c1a50) at Process.c:979
        i = 8
        this = 0x829225480
        fields = 0x8290e9200
#15 0x0000000000228828 in Panel_draw (this=0x8291ef000, force_redraw=false, focus=true, highlightSelected=true, hideFunctionBar=false)
    at Panel.c:274
        itemObj = 0x829225480
        item = {chlen = 54, chptr = 0x8205c1a60, chstr = {…}, highlightAttr = 0}
        itemLen = 96
        amt = 96
        i = 24
        line = 24
        size = 27
        scrollH = 0
        y = 9
        x = 0
        h = 37
        header_attr = 14848
        headerLen = 92
        first = 0
        upTo = 27
        selectionColor = 15872
#16 0x0000000000233830 in ScreenManager_drawPanels (this=0x8290aa140, focus=0, force_redraw=false) at ScreenManager.c:132
        panel = 0x8291ef000
        i = 0
        nPanels = 1
#17 0x0000000000232f73 in ScreenManager_run (this=0x8290aa140, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:165
        prevCh = -1
        result = IGNORED
        quit = false
        focus = 0
        panelFocus = 0x8291ef000
        oldTime = 16489634802.1481
        ch = -1
        closeTimeout = 0
        timedOut = true
        redraw = true
        force_redraw = false
        rescan = false
        sortTimeout = 1
        resetSortTimeout = 5
#18 0x0000000000219536 in CommandLine_run (name=0x2050a9 "htop", argc=1, argv=0x8205c4378) at CommandLine.c:376
        lc_ctype = 0x0
        status = STATUS_OK
        flags = {pidMatchList = 0x0, commFilter = 0x0, userId = 4294967295, sortKey = 0, delay = -1, useColors = true, enableMouse = true, 
          treeView = false, allowUnicode = true, highlightChanges = false, highlightDelaySecs = -1, readonly = false}
        ut = 0x829099008
        dc = 0x8290c9020
        dm = 0x0
        pl = 0x8290cf000
        settings = 0x8290f5000
        header = 0x8290e6090
        panel = 0x8291ef000
        state = {settings = 0x8290f5000, ut = 0x829099008, pl = 0x8290cf000, mainPanel = 0x8291ef000, header = 0x8290e6090, 
          pauseProcessUpdate = false, hideProcessSelection = false}
        scr = 0x8290aa140
#19 0x0000000000213d9c in main (argc=1, argv=0x8205c4378) at htop.c:15
No locals.

The interesting part here is that xSnprintf called fail which indicates that the internal call to snprintf failed or was truncated.

NB: If you provide a backtrace from GDB the filenames/lines and symbols are usually reliable enough such that the objdump output can be skipped.

[BenBE]

There seems to be something off with determining the start time of processes.

#11 0x000000000022a698 in Process_printTime (str=0x8205c1a50, totalHundredths=18446744073709551537, coloring=true) at Process.c:215

That second parameter is way off.

Can you set a breakpoint on ProcessList_goThroughEntries in freebsd/FreeBSDProcessList.c around line 511 (after the value of proc->starttime_ctime is set) and check both that value AND the value of super->realtimeMs?

[BenBE]

Please test the following patch (untested):

diff --git a/Process.c b/Process.c
index 77e78f04..4aad37b7 100644
--- a/Process.c
+++ b/Process.c
@@ -871,7 +871,7 @@ void Process_writeField(const Process* this, RichString* str, ProcessField field
       Process_printLeftAlignedField(str, attr, cwd, 25);
       return;
    }
-   case ELAPSED: Process_printTime(str, /* convert to hundreds of a second */ this->processList->realtimeMs / 10 - 100 * this->starttime_ctime, coloring); return;
+   case ELAPSED: Process_printTime(str, /* convert to hundreds of a second */ this->processList->realtimeMs / 10 < 100 * this->starttime_ctime ? this->processList->realtimeMs / 10 - 100 * this->starttime_ctime : 0, coloring); return;
    case MAJFLT: Process_printCount(str, this->majflt, coloring); return;
    case MINFLT: Process_printCount(str, this->minflt, coloring); return;                                                                                                                    
    case M_RESIDENT: Process_printKBytes(str, this->m_resident, coloring); return;                                                                                                           
diff --git a/freebsd/FreeBSDProcessList.c b/freebsd/FreeBSDProcessList.c                                                                                                                     
index 54697116..b25407a9 100644                                                                                                                                                              
--- a/freebsd/FreeBSDProcessList.c                                                                                                                                                           
+++ b/freebsd/FreeBSDProcessList.c                                                                                                                                                           
@@ -509,6 +509,9 @@ void ProcessList_goThroughEntries(ProcessList* super, bool pauseProcessUpdate) {                                                                                         
          proc->pgrp = kproc->ki_pgid;                                                                                                                                                       
          proc->st_uid = kproc->ki_uid;                                                                                                                                                      
          proc->starttime_ctime = kproc->ki_start.tv_sec;
+         if (proc->starttime_ctime < 0) {
+            proc->starttime_ctime = super->realtimeMs / 1000;
+         }
          Process_fillStarttimeBuffer(proc);
          proc->user = UsersTable_getRef(super->usersTable, proc->st_uid);
          ProcessList_add(super, proc);

...

I will attach "objdump" output & backtrace. For future, is backtrace needed when "objdump" output is also provided?

The objdump is usually used to cross-reference the addresses of the backtrace to the actual source location. If the backtrace you provide references the actual code files+lines in the htop source you can skip the objdump. The reason the default output of our crash reporter asks for it is that on most systems people don't have the source available and debug symbols aren't usually installed either. Thus given the disassembly from the objdump and the backtrace is usually sufficient to cross-reference the actual source code for a given crash location (Due to inlining you can't usually trust the function name given in the backtrace for some functions).

Thanks much for explaining the purposes of backtrace & "objdump" output.

Please test the following patch (untested):
...

Still same enough crash happens. Should I upload the backtrace from the patched version?

I could not get all the environment aligned such that compiling would continue for more than a few seconds; AND manually typing "continue", "n 15", "n" commands in gbd session would enter if (!preExisting) block; AND htop would update fast enough.

[BenBE]

I think it should be manageable without the backtrace now now that the basic error location is roughly clear.

In gdb you might be able to only break whenever you hit that assignment of proc->starttime_ctime inside the added condition.

If that condition is never hit, try to update the < to <= and see if you hit that update line in that case.

On the display side (first hunk/change) Process_printTime should usually be called with a time below about 365 * 86400 * 100 hundreds of a second (3153600000, 3 with 9 zeros to approximate) AKA one year.If you notice calls exceeding that value inside Process_printTime please provide a bt full, print this->processList->realtimeMs, and print *this (for the Process_writeField frame).

[BenBE]

One further change, which will mask the crash, but keep the display issue is this patch:

$ git diff
diff --git a/Process.c b/Process.c
index 4aad37b7..0f8c6325 100644
--- a/Process.c
+++ b/Process.c
@@ -192,7 +192,7 @@ void Process_printCount(RichString* str, unsigned long long number, bool colorin
 }
 
 void Process_printTime(RichString* str, unsigned long long totalHundredths, bool coloring) {
-   char buffer[10];
+   char buffer[20];
    int len;
 
    unsigned long long totalSeconds = totalHundredths / 100;

While this should fix the reason for the final crash, this does not fix the reason for the invalid data (that I'm still looking to understand) … But please test to see, if this avoids the crash (the other changes still apply).

[rickhg12hs]

Same symptoms on Fedora 35.

FATAL PROGRAM ERROR DETECTED
============================
Please check at https://htop.dev/issues whether this issue has already been reported.
If no similar issue has been reported before, please create a new issue with the following information:
  - Your htop version: '3.1.2'
  - Your OS and kernel version (uname -a)
  - Your distribution and release (lsb_release -a)
  - Likely steps to reproduce (How did it happen?)
  - Backtrace of the issue (see below)

Error information:
------------------
A signal 6 (Aborted) was received.

Setting information:
--------------------
htop_version=3.1.2;config_reader_min_version=2;fields=3 0 48 17 18 38 39 40 2 46 47 49 53 50 109 110 1;sort_key=46;sort_direction=-1;tree_sort_key=0;tree_sort_direction=1;hide_kernel_threads=1;hide_userland_threads=0;shadow_other_users=0;show_thread_names=0;show_program_path=0;highlight_base_name=0;highlight_deleted_exe=1;highlight_megabytes=1;highlight_threads=1;highlight_changes=0;highlight_changes_delay_secs=5;find_comm_in_cmdline=1;strip_exe_from_cmdline=1;show_merged_command=0;tree_view=0;tree_view_always_by_pid=0;all_branches_collapsed=0;header_margin=1;detailed_cpu_time=0;cpu_count_from_one=0;show_cpu_usage=1;show_cpu_frequency=1;show_cpu_temperature=1;degree_fahrenheit=0;update_process_names=0;account_guest_in_cpu_meter=0;color_scheme=0;enable_mouse=1;delay=15;hide_function_bar=0;header_layout=two_50_50;column_meters_0=AllCPUs Memory Swap Zram;column_meter_modes_0=1 1 1 1;column_meters_1=Tasks LoadAverage Uptime DateTime Battery DiskIO NetworkIO;column_meter_modes_1=2 2 2 2 2 2 2;

Backtrace information:
----------------------
htop(+0x121bb)[0x55e06d14f1bb]
htop(CRT_handleSIGSEGV+0xf9)[0x55e06d1581d9]
/lib64/libc.so.6(+0x42750)[0x7fafe627d750]
/lib64/libc.so.6(+0x8f88c)[0x7fafe62ca88c]
/lib64/libc.so.6(raise+0x16)[0x7fafe627d6a6]
/lib64/libc.so.6(abort+0xd3)[0x7fafe62677d3]
htop(+0x2d394)[0x55e06d16a394]
htop(xSnprintf+0xd3)[0x55e06d16ca43]
htop(Process_printTime+0x2d6)[0x55e06d161946]
htop(+0x334ab)[0x55e06d1704ab]
htop(Process_display+0x31)[0x55e06d15ac11]
htop(Panel_draw+0x284)[0x55e06d164434]
htop(ScreenManager_run+0x1bb)[0x55e06d165e3b]
htop(CommandLine_run+0x3f9)[0x55e06d158699]
/lib64/libc.so.6(+0x2d560)[0x7fafe6268560]
/lib64/libc.so.6(__libc_start_main+0x7c)[0x7fafe626860c]
htop(_start+0x25)[0x55e06d14d4a5]

# uname -a
Linux mycoolhost 5.16.18-200.fc35.x86_64 #1 SMP PREEMPT Mon Mar 28 14:10:07 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

htop.objdump.zip