Bug 161559 - top segfaults when resizing konsole
top segfaults when resizing konsole
Product: Fedora
Classification: Fedora
Component: procps (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-06-24 07:08 EDT by pemmes
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-11 07:29:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
valgrind --tool=memcheck log (18.47 KB, text/plain)
2005-06-26 14:15 EDT, pemmes
no flags Details
bug fix patch (2.40 KB, patch)
2005-06-28 09:19 EDT, Karel Zak
no flags Details | Diff

  None (edit)
Description pemmes 2005-06-24 07:08:26 EDT
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):

How reproducible:

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.

Additional info:
Comment 1 Karel Zak 2005-06-26 11:49:18 EDT
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.
Comment 2 pemmes 2005-06-26 14:14:36 EDT
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.
Comment 3 pemmes 2005-06-26 14:15:37 EDT
Created attachment 115989 [details]
valgrind --tool=memcheck log

Log file from running valgrind --tool=memcheck
Comment 4 pemmes 2005-06-26 14:17:30 EDT
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.
Comment 5 Karel Zak 2005-06-28 07:50:00 EDT
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
signal handler...

top.h: PUFF():

_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
about it?
Comment 6 Karel Zak 2005-06-28 08:29:59 EDT
I can reproduce it with "top -d 0.1".
Comment 8 pemmes 2005-06-28 16:43:30 EDT
I tried the test SRPM, the segfault is no longer reproducible.
Comment 9 Karel Zak 2005-06-28 17:12:39 EDT
Note upstream: s/static sigatomic_t Screen_resized/static int Screen_resized/
Comment 10 Karel Zak 2005-07-11 07:29:31 EDT
Fixed in procps-3.2.5-6.3 (FC4) and procps-3.2.3-5.3 (FC3).
Comment 11 Albert Cahalan 2007-05-28 00:10:35 EDT
fixed, but more of this crap exists

Note You need to log in before you can comment on or make changes to this bug.