Bug 161559 - top segfaults when resizing konsole
Summary: top segfaults when resizing konsole
Alias: None
Product: Fedora
Classification: Fedora
Component: procps
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-24 11:08 UTC by pemmes
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-11 11:29:31 UTC
Type: ---

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

Description pemmes 2005-06-24 11:08:26 UTC
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 15:49:18 UTC
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 18:14:36 UTC
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 18:15:37 UTC
Created attachment 115989 [details]
valgrind --tool=memcheck log

Log file from running valgrind --tool=memcheck

Comment 4 pemmes 2005-06-26 18:17:30 UTC
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 11:50:00 UTC
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 12:29:59 UTC
I can reproduce it with "top -d 0.1".

Comment 8 pemmes 2005-06-28 20:43:30 UTC
I tried the test SRPM, the segfault is no longer reproducible.

Comment 9 Karel Zak 2005-06-28 21:12:39 UTC
Note upstream: s/static sigatomic_t Screen_resized/static int Screen_resized/

Comment 10 Karel Zak 2005-07-11 11:29:31 UTC
Fixed in procps-3.2.5-6.3 (FC4) and procps-3.2.3-5.3 (FC3).

Comment 11 Albert Cahalan 2007-05-28 04:10:35 UTC
fixed, but more of this crap exists

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