Segmentation fault 11

[Nanduhirion]

htop version: 3.5.0-dev-3.4.1-264-g92b065f
OS/kernel: Darwin Mac-mini-von-Paul.local 25.2.0 Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:55 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T8103 arm64
Distro/release: macOS 26.2 (25C56)
Steps: Just running sudo htop for a long time

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

Setting information:
--------------------
htop_version=3.5.0-dev-3.4.1-264-g92b065f;config_reader_min_version=3;fields=0 48 17 18 38 39 2 46 47 49 50 1;hide_kernel_threads=1;hide_userland_threads=0;hide_running_in_container=0;shadow_other_users=1;show_thread_names=1;show_program_path=1;highlight_base_name=1;highlight_deleted_exe=1;shadow_distribution_path_prefix=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=1;header_margin=1;screen_tabs=1;detailed_cpu_time=1;cpu_count_from_one=0;show_cpu_usage=1;show_cpu_frequency=0;show_cached_memory=1;update_process_names=1;account_guest_in_cpu_meter=1;color_scheme=6;enable_mouse=1;delay=100;hide_function_bar=0;header_layout=two_50_50;column_meters_0=LeftCPUs2 Memory Swap GPU DiskIORate;column_meter_modes_0=1 1 1 1 2;column_meters_1=RightCPUs2 DateTime Uptime LoadAverage Tasks;column_meter_modes_1=1 2 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_MEM TIME NLWP 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                                0x0000000100fb6f50 CRT_handleSIGSEGV + 288
1   libsystem_platform.dylib            0x000000019e13f744 _sigtramp + 56
2   libsystem_c.dylib                   0x000000019dfceb64 strcasestr_l + 132
3   htop                                0x0000000100fccf0c String_contains_i + 156
4   htop                                0x0000000100fc27ac Process_rowMatchesFilter + 108
5   htop                                0x0000000100fcb388 Table_rebuildPanel + 372
6   htop                                0x0000000100fc5a44 ScreenManager_run + 452
7   htop                                0x0000000100fb4d60 CommandLine_run + 1816
8   dyld                                0x000000019dd6dd54 start + 7184

zsh: segmentation fault sudo htop
See attached for output from otool -tvV $(which htop) > ~/htop.otool.txt: htop.otool.txt

[fasterit]

Can you please apply

diff --git a/XUtils.c b/XUtils.c
index 94b82d80..9798289e 100644
--- a/XUtils.c
+++ b/XUtils.c
@@ -105,6 +105,10 @@ void* xReallocArrayZero(void* ptr, size_t prevmemb, size_t newmemb, size_t size)
 }
 
 inline bool String_contains_i(const char* s1, const char* s2, bool multi) {
+   // Return false if either string is NULL
+   if (!s1 || !s2)
+      return false;
+
    // we have a multi-string search term, handle as special case for performance reasons
    if (multi && strstr(s2, "|")) {
       size_t nNeedles;

and re-try your long running htop?

As MacOS is less well tested for htop, I expect we get an empty cmdline or mergedCommand.str and this barfs at String_contains_i.

Thanks!
/DLange

[Explorer09]

@fasterit I think we shouldn't change String_contains_i behavior for this bug. String_contains_i is a helper function around strcasestr, the latter has undefined behavior when either input pointer is NULL, and it's best to keep the behavior undefined.

It's difficult to define whether s1 "contains" a substring s2 when s2 is empty. FreeBSD man page says strstr (and strcasestr) return a pointer to s1 when s2 is an empty string. It says nothing about when s1 or s2 is NULL though.

[fasterit]

@Explorer09 The undefined behavior is likely causing the segfault on MacOS. See it from the customer perspective: working software is the more important goal than being right on C semantics.

[Explorer09]

@fasterit No it isn't about the C semantics. It's about you fixing the bug in the wrong way that might open a room for another bug. BTW, since I have a MacBook too, I could look at the bug if there's a easier way to reproduce it.

[Explorer09]

How about this fix? I'm not sure if it works.

diff --git a/Process.c b/Process.c
index cd1c0868..281918ab 100644
--- a/Process.c
+++ b/Process.c
@@ -858,7 +858,7 @@ static bool Process_matchesFilter(const Process* this, const Table* table) {
       return true;

    const char* incFilter = table->incFilter;
-   if (incFilter && !String_contains_i(Process_getCommand(this), incFilter, true))
+   if (incFilter && Process_getCommand(this) && !String_contains_i(Process_getCommand(this), incFilter, true))
       return true;

    const ProcessTable* pt = (const ProcessTable*) host->activeTable;

[fasterit]

That proposed fix doesn't do anything useful.
Please test on an ARM Mac, that would be more helpful.

[Nanduhirion]

I would like to help, if you have agreed on a fix I certainly would like to test it.

[fasterit]

@Nanduhirion try the patch from #1864 (comment) . Let an unpatched htop and one with the patch run in parallel. If either one segfaults on you ... tell us what you saw.

If you can reproduce this easy enough, run the htops under lldb and get us a backtrace from the segfault.

[BenBE]

I prefer the fix by @fasterit as it removes the possibility for undefined behaviour and having the function return false in these cases is expected.

And while the fix by @Explorer09 is legit, it relies on the compiler to perform CSE on the Process_getCommand(this) call. An explicit CSE (asignment of the call's result) would thus be advisable.

Apart from this I'd suggest to investigate why the NULL deref can happen in that place in the first place, if it is expected, and handle it accordingly.

[Explorer09]

@BenBE From the codebase of Process.c, it look like a Process object can have its cmdline and comm members being NULL pointers. Therefore I disagree with the "fix" on String_contains_i. It could bring side effects which are undesirable in the future.

@Nanduhirion From the backtrace it seems you had the Filter (F4) enabled before htop crashed. And there should be a kind of program that could make cmdline or comm to be NULL. I just didn't find out which process caused it. In other words this is a WORKSFORME status until I have more information to reproduce. (Tested on an M2 MacBook Pro running macOS Tahoe.)

[Nanduhirion]

Ok, I am currently running an unpatched version of htop against a patched version, whereby I used the patch of Explorer09. In both cases I started the processes with "sudo lldb htop-[patched/unpatched]", and in both cases I try to reproduce the behaviour by using a filter, so I come close to the use case when htop crashed. I will report back if one of the instances crashes.

[Nanduhirion]

I tried several times running patched / unpatched side-by-side under lldb. Caveat: After running for a couple of hours, both versions mysteriously get shut down by a sigkill signal 9. I don't know why, but this happens only if both versions run under lldb.

But until then, the patched version ran through fine, while the unpatched version stopped due to the already known EXC_BAD_ACCESS exception. The unpatched version crashed 5 out of 6 times, and the 6th time it was - like the patched version - killed by signal 9 for unknown reasons. Don't know what that is all about and didn't find out in the logs via commands like this:

log show --info --debug --predicate 'eventMessage CONTAINS "htop-patched"' --last 24h

The backtrace for the crash of the unpatched htop is here:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000019dfceb6c libsystem_c.dylib`strcasestr_l + 140
    frame #1: 0x0000000100031b74 htop`String_contains_i(s1=0x0000000000000000, s2="clam", multi=true) at XUtils.c:121:14
    frame #2: 0x0000000100021170 htop`Process_matchesFilter(this=0x0000000a21205900, table=0x00000001006a07a0) at Process.c:861:54
    frame #3: 0x00000001000210d0 htop`Process_rowMatchesFilter(super=0x0000000a21205900, table=0x00000001006a07a0) at Process.c:875:11
    frame #4: 0x000000010002ecbc htop`Table_rebuildPanel(this=0x00000001006a07a0) at Table.c:258:27
    frame #5: 0x0000000100027640 htop`checkRecalculation(this=0x00000001006ab3b0, oldTime=0x000000016fdfeb38, sortTimeout=0x000000016fdfeb28, redraw=0x000000016fdfeb2e, rescan=0x000000016fdfeb2c, timedOut=0x000000016fdfeb2f, force_redraw=0x000000016fdfeb2d) at ScreenManager.c:163:7
    frame #6: 0x0000000100026c1c htop`ScreenManager_run(this=0x00000001006ab3b0, lastFocus=0x0000000000000000, lastKey=0x0000000000000000, name=0x0000000000000000) at ScreenManager.c:262:10
    frame #7: 0x0000000100006a90 htop`CommandLine_run(argc=1, argv=0x000000016fdff350) at CommandLine.c:416:4
    frame #8: 0x00000001000007b4 htop`main(argc=1, argv=0x000000016fdff350) at htop.c:17:11
    frame #9: 0x000000019dd6dd54 dyld`start + 7184