Red Hat Bugzilla – Bug 161559
top segfaults when resizing konsole
Last modified: 2007-11-30 17:11:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4
Description of problem:
Resizing konsole while top is running in it causes top to segfault.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Launch konsole, resize it to have more than 25 rows.
2. From konsole, run top.
3. Resize konsole to decrease its height.
Actual Results: top segfaults.
Expected Results: top doesn't segfault.
Please, are you really sure that you run top from procps-3.2.3-5.2? This bug
should be fixed exactly in this version. It works for me in xterm or
Can you try install procps-debuginfo and run the 'top' in gdb and add to
bugzilla backtrace ('bt') output? Thanks.
This is reproducible with procps-3.2.3-5.2. I get the segfault every time even
in xterm. Unfortunately I couldn't get the backtrace because when running top in
gdb the terminal size change is not passed to top correctly.
Created attachment 115989 [details]
valgrind --tool=memcheck log
Log file from running valgrind --tool=memcheck
Hopefully the attached log file helps. I compiled top manually from the SRPM and
took logs from top built with debug info intact. Segfault seems to occur in
wins_resize during call to alloc_r.
Sorry, but I still cannot reproduce it.
There was problem with screen resizing (see bug #150580) and some other bugs in
PUFF() macro in the top. But it should be fixed in procps-3.2.3-pseudo.patch now.
There's possible that top still crash durring terminal resize, but it's very
very unlikely event:
I think that the top code logic for SIGWINCH is bad. It calls realloc() in
_ptr = &Pseudo_scrn[Pseudo_row++ * Pseudo_cols];
/* ---> what's happend if we catch SIGWINCH exactly here and realloc()
reallocate Pseudo_scrn ???
I think SIGSEGV in memcpy() ...
if (memcmp(_ptr, _str, _len))
memcpy(_ptr, _str, _len);
It's non-trivial fix and it requires change by upstream. Albert, any comment
I can reproduce it with "top -d 0.1".
Created attachment 116059 [details]
bug fix patch
I tried the test SRPM, the segfault is no longer reproducible.
Note upstream: s/static sigatomic_t Screen_resized/static int Screen_resized/
Fixed in procps-3.2.5-6.3 (FC4) and procps-3.2.3-5.3 (FC3).
fixed, but more of this crap exists