Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161559 - top segfaults when resizing konsole
Summary: top segfaults when resizing konsole
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: procps
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2005-07-11 11:29:31 UTC


Attachments (Terms of Use)
valgrind --tool=memcheck log (deleted)
2005-06-26 18:15 UTC, pemmes
no flags Details
bug fix patch (deleted)
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):
procps-3.2.3-5.2

How reproducible:
Always

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
gnome-termiinal.

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.