htop
htop copied to clipboard
hishamhm
Remove a double free in OpenBSDProcess.c.
No, I'm afraid it doesn't.
The *_done functions never free the object itself. They free its fields:
https://github.com/hishamhm/htop/blob/f1f805f29f6358aafc392c07d3569d143786961e/Process.c#L487-L490
OK. Maybe I was wrong in the commit message or using the word "object" there or talking about *_done, but there is a double-free or a use-after-free for sure, the OpenBSD malloc doesn't lie :)
Here is the backtrace:
Thread 1 (process 14150):
#0 0x00000bfe8b1f687a in thrkill () at <stdin>:2
No locals.
#1 0x00000bfe8b1f1f39 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
mask = 4294967263
sa = {
__sigaction_u = {
__sa_handler = 0xe,
__sa_sigaction = 0xe
},
sa_mask = 2335150211,
sa_flags = 3070
}
#2 0x00000bfe8b1d4279 in wrterror (msg=0xbfe8b2fd378 "use after free", p=0xbfe49ebb300)
at /usr/src/lib/libc/stdlib/malloc.c:283
iov = {{
iov_base = 0xbfc38f245e0 <__progname_storage>,
iov_len = 4
}, {
iov_base = 0x7f7ffffbe3c0,
iov_len = 11
}, {
iov_base = 0xbfe8b2fd387,
iov_len = 7
}, {
iov_base = 0xbfe8b2fe290,
iov_len = 8
}, {
iov_base = 0xbfe8b2fd378,
iov_len = 14
}, {
iov_base = 0x7f7ffffbe3a0,
iov_len = 14
}, {
iov_base = 0xbfe8b2f9083,
iov_len = 1
}}
pidbuf = "(14150) in \000\376\v\000\000\300\017px"
buf = " 0xbfe49ebb300\000\000@\263\353I"
saved_errno = 2
#3 0x00000bfe8b1d584c in validate_junk (p=<optimized out>)
at /usr/src/lib/libc/stdlib/malloc.c:1235
r = <optimized out>
pool = <optimized out>
byte = 0
sz = 13187883690106
#4 ofree (p=0xbfe49ebb300) at /usr/src/lib/libc/stdlib/malloc.c:1306
i = 8
pool = 0xbfec4e43b50
r = <optimized out>
sz = <optimized out>
#5 0x00000bfe8b1d58ee in free (ptr=0xbfe80684200)
at /usr/src/lib/libc/stdlib/malloc.c:1340
saved_errno = 2
#6 0x00000bfc38b1780d in Process_delete (cast=0x0) at openbsd/OpenBSDProcess.c:197
No locals.
#7 0x00000bfc38b138a8 in Vector_remove (this=0xbfea1ad08a0, idx=<optimized out>)
at Vector.c:225
removed = 0x0
#8 0x00000bfc38b10259 in ProcessList_scan (this=0xbff244a7300) at ProcessList.c:322
p = 0x6
i = 0
#9 0x00000bfc38b10c2f in checkRecalculation (timedOut=<optimized out>,
rescan=<optimized out>, redraw=<optimized out>, sortTimeout=<optimized out>,
oldTime=<optimized out>, this=<optimized out>) at ScreenManager.c:133
pl = 0xbff244a7300
tv = {
tv_sec = 1455481867,
tv_usec = 528326
}
#10 ScreenManager_run (this=0xbfe49ebb340, lastFocus=0x0, lastKey=0x0)
at ScreenManager.c:184
result = <optimized out>
focus = 0
panelFocus = 0xbfef49ad000
oldTime = 14554818675.28326
ch = -1
closeTimeout = 0
timedOut = false
redraw = false
rescan = false
sortTimeout = 0
#11 0x00000bfc38b0b7d4 in main (argc=<optimized out>, argv=<optimized out>)
at htop.c:230
lc_ctype = <optimized out>
ut = 0xbfe51758490
pl = 0xbff244a7300
settings = 0xbff06a30680
header = 0xbfecca1aac0
panel = <optimized out>
state = {
settings = 0xbff06a30680,
ut = 0xbfe51758490,
pl = 0xbff244a7300,
panel = 0xbfef49ad000,
header = 0xbfecca1aac0
}
scr = 0xbfe49ebb340
I need to get a better understanding of what's going on. Process_delete does free(this) in all platforms, it's that's function's responsibility. The stack trace seems to show that this is being freed before Process_delete is being called, as cast is arriving as 0x0:
#6 0x00000bfc38b1780d in Process_delete (cast=0x0) at openbsd/OpenBSDProcess.c:197
This means that something else is wrong before it hits Process_delete. We need some more investigation. @mmcco, any ideas?
@juanfra684 @falsovsky What are the steps to reproduce this bug? Does it crash immediately or after a while? Did you enable something in particular to catch the problem (compiler flags, etc)?
Just leave it running for about 5 minutes, and then F10 to exit, and it normally crashes.
# Beware! This file is rewritten by htop when settings are changed in the interface.
# The parser is also very primitive, and not human-friendly.
fields=0 48 17 18 38 39 2 46 47 49 1
sort_key=46
sort_direction=1
hide_threads=0
hide_kernel_threads=1
hide_userland_threads=0
shadow_other_users=0
show_thread_names=0
show_program_path=1
highlight_base_name=0
highlight_megabytes=1
highlight_threads=1
tree_view=0
header_margin=1
detailed_cpu_time=0
cpu_count_from_zero=0
update_process_names=0
account_guest_in_cpu_meter=0
color_scheme=0
delay=15
left_meters=AllCPUs Memory Swap
left_meter_modes=1 1 1
right_meters=Tasks LoadAverage Uptime
right_meter_modes=2 2 2
I haven't been able to trigger this, even with a very strict malloc.conf (CFJSUG). Still trying.
@mmcco I installed an OpenBSD VM just because of this issue, and I haven't been able to trigger it either. Perhaps it's a version-specific issue?
@juanfra684 @falsovsky what versions of OpenBSD and gcc are you using? (And any other versions you might consider relevant.)
OpenBSD 5.9-current (i.e. use the snapshots). Download this file https://devio.us/~juanfra684/tmp/htop.tar.gz . Go to /usr and run cvs -q [email protected]:/cvs get -P ports. cd /usr/ports/sysutils, copy here the htop directory from the tarball, cd htop and run make install. If you want to build htop without the patches, run mv patches patchesold.
htop will run fine with our defaults. You need to enable the malloc options to reproduce the bug. Go to /etc and run ln -s 'CFJSUG' malloc.conf. Now run htop.
I was finally able to trigger this by running htop along with dpb. I'll share a backtrace and start debugging tomorrow.
First backtrace:
#0 0x0000045084c3e89a in thrkill () at <stdin>:2
#1 0x0000045084c39f59 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2 0x0000044de211797f in CRT_handleSIGSEGV (sgn=Variable "sgn" is not available.
) at openbsd/OpenBSDCRT.c:20
#3 <signal handler called>
#4 0x0000000000000001 in ?? ()
#5 0x0000044de2108be2 in SingleColCPUsMeter_draw (this=Variable "this" is not available.
) at CPUMeter.c:207
#6 0x0000044de210acce in Header_draw (this=0x45008434400) at Header.c:194
#7 0x0000044de2110b48 in ScreenManager_run (this=0x45075bb0380, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:142
#8 0x0000044de210b824 in main (argc=Variable "argc" is not available.
) at htop.c:231
Second backtrace:
#0 0x00000bdcfbe8b89a in *_libc_getenv (name=Variable "name" is not available.
) at /usr/src/lib/libc/stdlib/getenv.c:80
#1 0xffffffdf00000202 in ?? ()
#2 0x0f04d066c347eed3 in ?? ()
#3 0x00007f7ffffdeaa0 in ?? ()
#4 0x00000bdcfbe69299 in _citrus_utf8_ctype_wcsnrtombs (
dst=0xbdcfbf932b0 "\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237"..., src=0x7, nwc=13043748119463, len=10, pspriv=0x7f7ffffdeac0) at /usr/src/lib/libc/citrus/citrus_utf8.c:366
#5 0x0000303061313966 in ?? ()
#6 0x00000bdcda595ca0 in ?? ()
#7 0x00000bdceb4b0cf8 in ?? ()
#8 0x6920293035333728 in ?? ()
#9 0x00000bdcbc00206e in ?? ()
#10 0x00000bdceb4b0cf8 in ?? ()
#11 0x0f04d066c347eed3 in ?? ()
#12 0x00000bdcbc988fd0 in ?? ()
#13 0x00000bdc65f91a00 in ?? ()
#14 0x00000bdc73c6bc00 in ?? ()
#15 0x000000000000000e in ?? ()
#16 0x00000bdc767a0a80 in ?? ()
#17 0x00000bdcfbe6a86c in ofree (p=Variable "p" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:1327
#18 0x00000bdcfbe6a90e in ofree (p=0xbdcfc2a842c) at /usr/src/lib/libc/stdlib/malloc.c:1303
#19 0x000000000000006d in ?? ()
#20 0x000000000000006d in ?? ()
#21 0x00000bda45d10308 in ProcessList_scan (this=0xbdd00e02b00) at ProcessList.c:327
#22 0x00000bda45d10d08 in ScreenManager_run (this=0x1, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:133
#23 0x00000bda45d0b824 in main (argc=Variable "argc" is not available.
) at htop.c:231
These crashes seem to be in really random places!
The first one looks like ->draw was set to 1 instead of a valid pointer.
The second one looks like a stack corruption.
These are really random and I'm unable to reproduce any of this on Linux with Valgrind (which is as strict with memory accesses as it gets).
Also, did you build with make debug? (Asking just because of the "variable not available" messages.)
Another backtrace:
#0 0x00000c5054a5d87a in thrkill () at <stdin>:2
#1 0x00000c5054a58f79 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2 0x00000c5054a3b379 in wrterror (d=0xc5069f05770, msg=0xc5054b643a1 "use after free", p=0xc510ff90a80) at /usr/src/lib/libc/stdlib/malloc.c:286
#3 0x00000c5054a3c7a9 in ofree (pool=0xc5069f05770, p=0xc510ff90a80) at /usr/src/lib/libc/stdlib/malloc.c:1248
#4 0x00000c5054a3c86b in free (ptr=0xc509da15b40) at /usr/src/lib/libc/stdlib/malloc.c:1354
#5 0x00000c4e4890b4ed in Hashtable_remove (this=0xc511c513c20, key=36497) at Hashtable.c:130
#6 0x00000c4e48912660 in ProcessList_remove (this=0xc5116607700, p=0xc507c67f500) at ProcessList.c:153
#7 0x00000c4e48912e5b in ProcessList_scan (this=0xc5116607700) at ProcessList.c:332
#8 0x00000c4e489138be in checkRecalculation (this=0xc511e165740, oldTime=0x7f7ffffe0410, sortTimeout=0x7f7ffffe0434, redraw=0x7f7ffffe0445, rescan=0x7f7ffffe0444,
timedOut=0x7f7ffffe0446) at ScreenManager.c:133
#9 0x00000c4e48913ae9 in ScreenManager_run (this=0xc511e165740, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:184
#10 0x00000c4e4890c761 in main (argc=3, argv=0x7f7ffffe0568) at htop.c:231
Full backtrace:
#0 0x00000c5054a5d87a in thrkill () at <stdin>:2
No locals.
#1 0x00000c5054a58f79 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
mask = 4294967263
sa = {__sigaction_u = {__sa_handler = 0xe, __sa_sigaction = 0xe}, sa_mask = 1421213827, sa_flags = 3152}
#2 0x00000c5054a3b379 in wrterror (d=0xc5069f05770, msg=0xc5054b643a1 "use after free", p=0xc510ff90a80) at /usr/src/lib/libc/stdlib/malloc.c:286
iov = {{iov_base = 0xc506630d200, iov_len = 4}, {iov_base = 0x7f7ffffe0190, iov_len = 11}, {iov_base = 0xc5054b643b0, iov_len = 7}, {iov_base = 0xc5054b652d0,
iov_len = 8}, {iov_base = 0xc5054b643a1, iov_len = 14}, {iov_base = 0x7f7ffffe0170, iov_len = 14}, {iov_base = 0xc5054b60083, iov_len = 1}}
pidbuf = "(49064) in \000\177\177\000\000\030"
buf = " 0xc510ff90a80\000\000\000\000\000"
saved_errno = 3
#3 0x00000c5054a3c7a9 in ofree (pool=0xc5069f05770, p=0xc510ff90a80) at /usr/src/lib/libc/stdlib/malloc.c:1248
i = 10
r = Variable "r" is not available.
And another:
#0 0x00001aaddeef587a in thrkill () at <stdin>:2
#1 0x00001aaddeef0f79 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2 0x00001aab2361cd8e in CRT_handleSIGSEGV (sgn=Could not find the frame base for "CRT_handleSIGSEGV".
) at openbsd/OpenBSDCRT.c:20
#3 <signal handler called>
#4 0x00001aab2361bb7e in Platform_setCPUValues (this=0x1aae08f2a500, cpu=8) at openbsd/Platform.c:218
#5 0x00001aab23608e45 in CPUMeter_setValues (this=0x1aae08f2a500, buffer=0x7f7ffffdc3e0 " 27.2%", size=255) at CPUMeter.c:65
#6 0x00001aab2360d8b3 in BarMeterMode_draw (this=0x1aae08f2a500, x=84, y=4, w=80) at Meter.c:268
#7 0x00001aab23609967 in SingleColCPUsMeter_draw (this=0x1aad37769480, x=84, y=4, w=80) at CPUMeter.c:207
#8 0x00001aab2360bf11 in Header_draw (this=0x1aae23754640) at Header.c:194
#9 0x00001aab23613913 in checkRecalculation (this=0x1aae23754080, oldTime=0x7f7ffffdc690, sortTimeout=0x7f7ffffdc6b4, redraw=0x7f7ffffdc6c5, rescan=0x7f7ffffdc6c4,
timedOut=0x7f7ffffdc6c6) at ScreenManager.c:142
#10 0x00001aab23613ae9 in ScreenManager_run (this=0x1aae23754080, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:184
#11 0x00001aab2360c761 in main (argc=3, argv=0x7f7ffffdc7e8) at htop.c:231
Full:
No locals.
#1 0x00001aaddeef0f79 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
mask = 4294967263
sa = {__sigaction_u = {__sa_handler = 0x7f7ffffdbcc0, __sa_sigaction = 0x7f7ffffdbcc0}, sa_mask = 51, sa_flags = 0}
#2 0x00001aab2361cd8e in CRT_handleSIGSEGV (sgn=Could not find the frame base for "CRT_handleSIGSEGV".
) at openbsd/OpenBSDCRT.c:20
No locals.
#3 <signal handler called>
No symbol table info available.
#4 0x00001aab2361bb7e in Platform_setCPUValues (this=0x1aae08f2a500, cpu=8) at openbsd/Platform.c:218
i = 32639
perc = 6.9261942544885949e-310
pl = (OpenBSDProcessList *) 0x1aadcd30f300
cpuData = (CPUData *) 0x1aadcb97c000
new_v = {8555434, 287, 10098937, 4446, 49578658}
diff_v = {137438955520, -6422425931244899075, 29331427421952, 140187732394793, 0}
scratch_v = {29331427421952, 29331427421952, 158913789952, 0, 0}
v = (double *) 0x1aae23754d40
size = 40
mib = {1, 71, 7}
#5 0x00001aab23608e45 in CPUMeter_setValues (this=0x1aae08f2a500, buffer=0x7f7ffffdc3e0 " 27.2%", size=255) at CPUMeter.c:65
cpu = 8
percent = 6.0134700169990685e-154
#6 0x00001aab2360d8b3 in BarMeterMode_draw (this=0x1aae08f2a500, x=84, y=4, w=80) at Meter.c:268
buffer = " 27.2%\000\000\021W\032", '\0' <repeats 18 times>, "0\177\177", '\0' <repeats 14 times>, "\001", '\0' <repeats 11 times>, "\001\000\000\000\001\000\000\000\000\000\000\000\003\000\000\0000K/11.3G\0004G\000\032\000\000\220\177\177\000\000\177\177\000\000\003", '\0' <repeats 23 times>, "a#\032\000\000 \003\000\000\000\000\000\000\000\204o_\032\000\000\000\204o_\032\000\000\000'\032\000\000\177\177\000\000\000\000\000\000\000\000\000\200l\032", '\0' <repeats 11 times>, "A\032\000\000\000\000\000\000\000\000\000\000"...
captionLen = 3
bar = 0x7f7ffffdc2e0 "0\177\177"
blockSizes = {10, 0, 12, 0, -146640, 32639, 0, 0, 0, 0}
offset = 22
items = 4
#7 0x00001aab23609967 in SingleColCPUsMeter_draw (this=0x1aad37769480, x=84, y=4, w=80) at CPUMeter.c:207
i = 3
meters = (Meter **) 0x1aae02796b00
start = 4
count = 4
#8 0x00001aab2360bf11 in Header_draw (this=0x1aae23754640) at Header.c:194
meter = (Meter *) 0x1aad37769480
y = 1
i = 0
meters = (Vector *) 0x1aadc865c760
col = 1
height = 9
pad = 2
width = 80
x = 84
#9 0x00001aab23613913 in checkRecalculation (this=0x1aae23754080, oldTime=0x7f7ffffdc690, sortTimeout=0x7f7ffffdc6b4, redraw=0x7f7ffffdc6c5, rescan=0x7f7ffffdc6c4,
timedOut=0x7f7ffffdc6c6) at ScreenManager.c:142
pl = (ProcessList *) 0x1aadcd30f300
tv = {tv_sec = 1460348387, tv_usec = 241484}
newTime = 14603483872.414841
#10 0x00001aab23613ae9 in ScreenManager_run (this=0x1aae23754080, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:184
prevCh = 6829
result = 3442537216
quit = false
focus = 0
panelFocus = (Panel *) 0x1aada2cc0000
oldTime = 14603483872.414841
ch = -1
closeTimeout = 0
timedOut = true
redraw = true
rescan = true
sortTimeout = 1
resetSortTimeout = 5
#11 0x00001aab2360c761 in main (argc=3, argv=0x7f7ffffdc7e8) at htop.c:231
lc_ctype = 0x0
flags = {pidWhiteList = 0x0, userId = 4294967295, sortKey = 0, delay = 1, useColors = true}
ut = (UsersTable *) 0x1aad3f2ade10
pl = (ProcessList *) 0x1aadcd30f300
settings = (Settings *) 0x1aad37769800
header = (Header *) 0x1aae23754640
panel = (MainPanel *) 0x1aada2cc0000
state = {settings = 0x1aad37769800, ut = 0x1aad3f2ade10, pl = 0x1aadcd30f300, panel = 0x1aada2cc0000, header = 0x1aae23754640}
scr = (ScreenManager *) 0x1aae23754080
As Hisham pointed out, these seem really disparate. They're reasonably hard to trigger, too.
By the way, I've run htop in Valgrind for hours when doing a bulk port build (which entails tons of resource use and short-lived processes) and couldn't find anything other than ncurses-related memory leaks.
Does anyone have ideas for tools that might help us catch this? Maybe there's a Valgrind option that makes it stricter in its observation of writes?
@mmcco, are you building the binary with -O2 or with -O0? if you're using the former, then change to -O0. Maybe there is some UB in the code somewhere.
The best tool is probably gcc/clang+libubsan but we have not a port for this. So, maybe clang scan-build or cppcheck could find something.
Not willing to shift away blame, but if it happens only with OpenBSD 5.9-current, is there a chance this is a bug in some other component? (I assume 5.9-current is the in-development version, is that correct?)
Valgrind is not finding anything on Linux, and it is really strict about memory accesses, so if there is a memory bug it is probably in the openbsd/ subdirectory... but it is still strange if CFJSUG can't trigger it in the latest stable OpenBSD but it does in the snapshots... what's different in the snapshots?
In any case, I'm updating my GCC here on Linux and will try htop with libubsan...
Definitely possible. On the other hand, OpenBSD uses very strong memory sanitization, and most (or all?) of us are only seeing these bugs with particularly brutal sanitization settings. Even in those cases, the crashes seem only occasional. I therefore haven't really had an intuition for whether it's in the OpenBSD-specific htop code, the platform-generic htop code, or one of OpenBSD's libraries.
I just upgraded GCC to 5.3.0, rebuilt htop with make CFLAGS="-O0 -fsanitize=undefined -fno-sanitize-recover". From the get-go, the only problem to get htop running in this mode was this:
diff --git a/Process.c b/Process.c
index dddd7fc..c6275de 100644
--- a/Process.c
+++ b/Process.c
@@ -394,7 +394,7 @@ void Process_writeField(Process* this, RichString* str, ProcessField field) {
int indent = (this->indent < 0 ? -this->indent : this->indent);
for (int i = 0; i < 32; i++)
- if (indent & (1 << i))
+ if (indent & (1U << i))
maxIndent = i+1;
for (int i = 0; i < maxIndent - 1; i++) {
int written;
because 1 << 31 is undefined for signed int. Apart from that, it is running. I'll keep it running to see if any other UB comes up.
If you want to check the code with cppcheck, use this command: cppcheck --enable=warning --language=c --std=posix --std=c99 --platform=unix64 -D__OpenBSD__ -q --suppress=ignoredReturnValue yourrepo. I see some similar warnings.
On OpenBSD 5.9-current (without using any special malloc options), when pressing F2 to enter the setup view, then F10 to go back to the main screen, and doing this multiple time, I usually get a segmentation fault after a few seconds while hammering the keys.
Segmentation fault (core dumped)
Here is a backtrace :
(gdb) backtrace
#0 strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:152
#1 0x0000009701a13c80 in RichString_append (this=0x7f7ffffc0440, attrs=0, data=0x1 <Address 0x1 out of bounds>)
at RichString.c:165
#2 0x0000009701a0cc6d in ListItem_display (cast=0x99d5323e80, out=0x7f7ffffc0440) at ListItem.c:53
#3 0x0000009701a1003c in Panel_draw (this=0x9932718000, focus=false) at Panel.c:323
#4 0x0000009701a144a7 in ScreenManager_drawPanels (this=0x9939ac7300, focus=0) at ScreenManager.c:151
#5 0x0000009701a1460b in ScreenManager_run (this=0x9939ac7300, lastFocus=0x7f7ffffc26c8, lastKey=0x7f7ffffc26e4)
at ScreenManager.c:188
#6 0x0000009701a1a20c in Action_runSetup (settings=0x99ddd91080, header=0x9987abdac0, pl=0x994ee00200) at Action.c:109
#7 0x0000009701a1ab53 in actionSetup (st=0x7f7ffffc2870) at Action.c:338
#8 0x0000009701a0a300 in MainPanel_eventHandler (super=0x991c69c000, ch=266) at MainPanel.c:95
#9 0x0000009701a148a2 in ScreenManager_run (this=0x9939ac7500, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:256
#10 0x0000009701a0ca75 in main (argc=1, argv=0x7f7ffffc2958) at htop.c:231
Sometimes though, I get another type of crash :
assertion "Vector_isConsistent(this)" failed: file "Vector.c", line 277, function "Vector_get"
Abort trap (core dumped)
Here is a backtrace :
(gdb) backtrace
#0 0x00000b1f73a2f9fa in thrkill () at <stdin>:2
#1 0x00000b1f73a2b0f9 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2 0x00000b1f739aac04 in *_libc___assert2 (file=Variable "file" is not available.
) at /usr/src/lib/libc/gen/assert.c:52
#3 0x00000b1d29818886 in Vector_get (this=0xb1f525ebb40, idx=0) at Vector.c:277
#4 0x00000b1d2981448e in ScreenManager_drawPanels (this=0xb1fc007cf80, focus=0) at ScreenManager.c:150
#5 0x00000b1d2981460b in ScreenManager_run (this=0xb1fc007cf80, lastFocus=0x7f7ffffe7108, lastKey=0x7f7ffffe7124)
at ScreenManager.c:188
#6 0x00000b1d2981a20c in Action_runSetup (settings=0xb1fa246cc00, header=0xb1ff1373500, pl=0xb1fe86c5600)
at Action.c:109
#7 0x00000b1d2981ab53 in actionSetup (st=0x7f7ffffe72b0) at Action.c:338
#8 0x00000b1d2980a300 in MainPanel_eventHandler (super=0xb1fe5f6b000, ch=266) at MainPanel.c:95
#9 0x00000b1d298148a2 in ScreenManager_run (this=0xb1fca7f8380, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:256
#10 0x00000b1d2980ca75 in main (argc=1, argv=0x7f7ffffe7398) at htop.c:231
@fcambus Thank you! This is useful for investigating! In the cases when it crashes (not with the Vector_isConsistent assert), do the backtraces always look like this? (I mean, strlen called by RichString_append with data=0x1)
@hishamhm Yes, I tested again and was able to trigger three new crashes and backtraces are always similar.
Just had a different backtrace, this one happens when htop crashes immediately at the first F2 keypress:
(gdb) backtrace
#0 0x0000175483236c50 in _nc_wgetch (win=0x1753f6906f00, result=0x7f7ffffc23f0, use_meta=1)
at /usr/src/lib/libcurses/base/lib_getch.c:623
#1 0x0000175483237523 in wgetch (win=0x1753f6906f00) at /usr/src/lib/libcurses/base/lib_getch.c:558
#2 0x00001751a9f1462d in ScreenManager_run (this=0x17547b2aaf00, lastFocus=0x0, lastKey=0x0) at ScreenManager.c:193
#3 0x00001751a9f0ca75 in main (argc=1, argv=0x7f7ffffc25b8) at htop.c:231