Automatic segfaults / crashes on macOS Sequoia

[ylluminarious]

After recently updating htop to 3.4.1 via MacPorts, I ran sudo htop for 2 hours and then this crash occurred. I did nothing except start the program and leave it running. Prior to this crash, an identical segfault occurred after running it for only 20 seconds.

The following is the requested information generated by the error message:

---

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.4.1
• Your OS and kernel version (uname -a):

      Darwin my_hostname 24.4.0 Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:47 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6000 arm64
  

• Your distribution and release (echo "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion) $(uname -m)"):

      macOS 15.4.1 24E263 arm64
  

• Likely steps to reproduce (How did it happen?): I ran sudo htop for 2 hours and then this crash occurred. I did nothing except start the program and leave it running. Prior to this crash, an identical segfault occurred after running it for only 20 seconds.
• Backtrace of the issue (see below)

Error information:
------------------
A signal 11 (Segmentation fault: 11) was received.

Setting information:
--------------------
htop_version=3.4.1;config_reader_min_version=3;fields=0 48 6 17 18 38 39 2 46 47 49 1;hide_kernel_threads=0;hide_userland_threads=0;hide_running_in_container=0;shadow_other_users=0;show_thread_names=0;show_program_path=1;highlight_base_name=1;highlight_deleted_exe=1;shadow_distribution_path_prefix=0;highlight_megabytes=0;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;header_margin=1;screen_tabs=0;detailed_cpu_time=0;cpu_count_from_one=1;show_cpu_usage=1;show_cpu_frequency=0;show_cached_memory=1;update_process_names=0;account_guest_in_cpu_meter=0;color_scheme=5;enable_mouse=1;delay=15;hide_function_bar=0;header_layout=two_50_50;column_meters_0=AllCPUs Memory Swap;column_meter_modes_0=1 1 1;column_meters_1=Tasks LoadAverage Uptime;column_meter_modes_1=2 2 2;tree_view=0;sort_key=47;tree_sort_key=0;sort_direction=-1;tree_sort_direction=1;tree_view_always_by_pid=0;all_branches_collapsed=0;screen:Main=PID USER TTY PRIORITY NICE M_VIRT M_RESIDENT STATE PERCENT_CPU PERCENT_MEM TIME Command;.sort_key=PERCENT_MEM;.tree_sort_key=PID;.tree_view_always_by_pid=0;.tree_view=0;.sort_direction=-1;.tree_sort_direction=1;.all_branches_collapsed=0;

Backtrace information:

----------------------
0   htop                                0x0000000104f1bb40 CRT_handleSIGSEGV + 288
1   libsystem_platform.dylib            0x000000018d0cf624 _sigtramp + 56
2   htop                                0x0000000104f31224 DarwinProcess_scanThreads + 472
3   htop                                0x0000000104f3167c ProcessTable_goThroughEntries + 540
4   htop                                0x0000000104f1fdc4 Machine_scanTables + 172
5   htop                                0x0000000104f29058 ScreenManager_run + 364
6   htop                                0x0000000104f19f20 CommandLine_run + 1872
7   dyld                                0x000000018ccf6b4c start + 6000

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:

   otool -tvV `which htop` > ~/htop.otool

Link: https://gist.github.com/ylluminarious/0d8daa5c6e1dc27df2c446742ca9f87b

[BenBE]

Please check if this still happens when running the latest version from the main branch (AKA HEAD).

[chenzhuoyu]

@BenBE I can confirm this still happens with HEAD

[ylluminarious]

@BenBE Yes, I can corroborate what @chenzhuoyu says. I tried running a HEAD build yesterday and it crashed again after about 3.5 hours. This time, there was no error message, just: [1] <PID> killed sudo htop

[BenBE]

Could you try a debug build under gdb (bt full at the crash site)?

@ylluminarious : That dump from otool looks strange/truncated somehow. Considering the provided addresses in the backtrace you usually should be able to calculate an offset for where htop was loaded which is a multiple of 4K; doing this with the above dump yields 0x4f14320, which doesn't look right. And leaving that aside, I get some offsets (e.g. for DarwinProcess_scanThreads) that point to outside the range covered by that otool dump.

Also given that this still happens in HEAD, this means, an issue I assumed might be related (1d2d384 for #1650) was not the cause for this.

[simonmichael]

I saw this today on macos 15.4.1, here's another disassemby: https://pub.microbin.eu/upload/seal-jaguar

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.4.0-dev'
  - 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 11 (Segmentation fault: 11) was received.

Setting information:
--------------------
htop_version=3.4.0-dev;config_reader_min_version=3;fields=0 48 17 18 38 39 2 46 47 49 1;hide_kernel_threads=1;hide_userland_threads=0;hide_running_in_container=0;shadow_other_users=0;show_thread_names=0;show_program_path=1;highlight_base_name=0;highlight_deleted_exe=1;shadow_distribution_path_prefix=0;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;header_margin=1;screen_tabs=1;detailed_cpu_time=0;cpu_count_from_one=0;show_cpu_usage=1;show_cpu_frequency=0;show_cached_memory=1;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=LeftCPUs Memory Swap;column_meter_modes_0=1 1 1;column_meters_1=RightCPUs Tasks LoadAverage Uptime;column_meter_modes_1=1 2 2 2;tree_view=0;sort_key=46;tree_sort_key=0;sort_direction=-1;tree_sort_direction=1;tree_view_always_by_pid=0;all_branches_collapsed=0;screen:Main=PID USER PRIORITY NICE M_VIRT M_RESIDENT STATE PERCENT_CPU PERCENT_MEMTIME Command;.sort_key=PERCENT_CPU;.tree_sort_key=PID;.tree_view_always_by_pid=0;.tree_view=0;.sort_direction=-1;.tree_sort_direction=1;.all_branches_collapsed=0;

Backtrace information:
----------------------
0   htop                                0x0000000102c67b60 CRT_handleSIGSEGV + 288
1   libsystem_platform.dylib            0x0000000182497624 _sigtramp + 56
2   htop                                0x0000000102c7d20c DarwinProcess_scanThreads + 444
3   htop                                0x0000000102c7d654 ProcessTable_goThroughEntries + 540
4   htop                                0x0000000102c6bdd0 Machine_scanTables + 152
5   htop                                0x0000000102c7505c ScreenManager_run + 364
6   htop                                0x0000000102c65f40 CommandLine_run + 1872
7   dyld                                0x00000001820beb4c start + 6000

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:

   otool -tvV `which htop` > ~/htop.otool

[BenBE]

@simonmichael

I saw this today on macos 15.4.1, here's another disassemby: https://pub.microbin.eu/upload/seal-jaguar

• Your htop version: '3.4.0-dev'

Please test again with a version directly compiled from main, like e.g. 3.5.0-dev-3.4.1-47-g36ea1ef. Your crash was with version 3.4.0, which has a known bug (#1650), that has already been fixed (1d2d384).

NB: Your otool file was complete and had a sensible offset (0x2C60000).

[chenzhuoyu]

@BenBE I tested htop 3.5.0-dev-3.4.1-48-g1cf2e67 it can run several days without problem if I run htop with normal user, but crashes after random amount of time (hours to days) with Killed: 9 if ran with sudo htop.

I have tried to attach htop with lldb, but it just reports "Process exited with 9" without any backtraces :(

I need to run with sudo because without it the CPU percent looks wrong :(

[chenzhuoyu]

@BenBE Any updates on this?

[tirlarim]

Also note that the settings are reset after a crash. The columns are reset to the default order. This is unexpected behavior. I expected it to save the settings in some file and random exits/crashes would not affect it.

[BenBE]

Also note that the settings are reset after a crash. The columns are reset to the default order. This is unexpected behavior. I expected it to save the settings in some file and random exits/crashes would not affect it.

Settings are only stored on normal termination. After changing columns, terminate htop normally once (not Ctrl+C) and settings should be saved as expected.