top crash with resize at mininum

[Mario]

Well, I got a crash with top when resised at minimum the gnome or kde terminal.
I tried with gnome-terminal and konsole. The backtrace in gdb is:

backtrace
==========
(gdb) backtrace
#0 0x0804b587 in ?? ()
#1 0x0806c1f0 in ?? ()
#2 0x0806c1f0 in ?? ()
#3 0xb7fb8e30 in _nc_flush () from /lib/libncurses.so.5
Previous frame inner to this frame (corrupt stack?)

and...
mario@mario:~$ dpkg -l | grep procps
ii procps 3.2.4-1ubuntu1 The /proc file system utilities

PD: Sorry my English, is not my native language ; )

[Craig Small (csmall)]

found 256376 1:3.2.5-1
tags 256376 upstream
--
Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer
csmall at : enc.com.au ieee.org debian.org

[Mario (mario-cfrd)]

Well, I got a crash with top when resised at minimum the gnome or kde terminal.
I tried with gnome-terminal and konsole. The backtrace in gdb is:

backtrace
==========
(gdb) backtrace
#0 0x0804b587 in ?? ()
#1 0x0806c1f0 in ?? ()
#2 0x0806c1f0 in ?? ()
#3 0xb7fb8e30 in _nc_flush () from /lib/libncurses.so.5
Previous frame inner to this frame (corrupt stack?)

and...
mario@mario:~$ dpkg -l | grep procps
ii procps 3.2.4-1ubuntu1 The /proc file system utilities

PD: Sorry my English, is not my native language ; )

[Justin Pryzby (justinpryzby-users)]

clone 256376 -1
reassign -1 xterm
retitle -1 xterm: top in a super-small xterm crashes them both
thanks

Not only does top get SIGSEGV, so does the xterm in which it runs.
Valgrind on a copy of xterm without SGID xterm reports lots of
problems.

[Thomas Dickey (dickey)]

On Fri, Aug 19, 2005 at 08:10:07PM +0200, Justin Pryzby wrote:
> clone 256376 -1
> reassign -1 xterm
> retitle -1 xterm: top in a super-small xterm crashes them both
> thanks
>
> Not only does top get SIGSEGV, so does the xterm in which it runs.
> Valgrind on a copy of xterm without SGID xterm reports lots of
> problems.

hmm - aside from the cosmetic issue you reported with libXt (an overlapping
memcpy is just that), what other warnings are you seeing with valgrind?

(and of course, what version of xterm, what size is "super-small", etc).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[Thomas Dickey (dickey)]

On Fri, Aug 19, 2005 at 08:10:07PM +0200, Justin Pryzby wrote:
> clone 256376 -1
> reassign -1 xterm
> retitle -1 xterm: top in a super-small xterm crashes them both
> thanks

if you don't identify the version of xterm, I can only guess
that you're talking about this, which was fixed in patch #201
(and has been reported on this list 2-3 times since then):

 add a limit check for scrolling margins in a one-line screen,
 overlooked in fixes for patch #198 (Debian #297430).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[Craig Small (csmall)]

On Fri, Aug 19, 2005 at 05:44:48PM -0400, Thomas Dickey wrote:
> On Fri, Aug 19, 2005 at 08:10:07PM +0200, Justin Pryzby wrote:
> > clone 256376 -1
> > reassign -1 xterm
> > retitle -1 xterm: top in a super-small xterm crashes them both
> > thanks
>
> if you don't identify the version of xterm, I can only guess
> that you're talking about this, which was fixed in patch #201
> (and has been reported on this list 2-3 times since then):
>
> add a limit check for scrolling margins in a one-line screen,
> overlooked in fixes for patch #198 (Debian #297430).
Thomas could you do me (procps maintainer) a favour and run top on
a "super-small" (think it is 3 columns or less) of a known fixed xterm
and tell me if top dies?

I'm trying to see if it is/was a top problem, a xterm problem, a library
(eg ncurses) problem or some combination.

 - Craig
--
Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer
csmall at : enc.com.au ieee.org debian.org

[Thomas Dickey (dickey)]

On Mon, Aug 22, 2005 at 10:45:43AM +1000, Craig Small wrote:
> Thomas could you do me (procps maintainer) a favour and run top on
> a "super-small" (think it is 3 columns or less) of a known fixed xterm
> and tell me if top dies?

ok (this afternoon, when I'm home)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[Thomas Dickey (dickey)]

On Mon, Aug 22, 2005 at 10:45:43AM +1000, Craig Small wrote:
> On Fri, Aug 19, 2005 at 05:44:48PM -0400, Thomas Dickey wrote:
> > On Fri, Aug 19, 2005 at 08:10:07PM +0200, Justin Pryzby wrote:
> > > clone 256376 -1
> > > reassign -1 xterm
> > > retitle -1 xterm: top in a super-small xterm crashes them both
> > > thanks
> >
> > if you don't identify the version of xterm, I can only guess
> > that you're talking about this, which was fixed in patch #201
> > (and has been reported on this list 2-3 times since then):
> >
> > add a limit check for scrolling margins in a one-line screen,
> > overlooked in fixes for patch #198 (Debian #297430).
> Thomas could you do me (procps maintainer) a favour and run top on
> a "super-small" (think it is 3 columns or less) of a known fixed xterm
> and tell me if top dies?

I didn't see it die, but running it with valgrind, and resizing xterm (#202)
several times, valgrind does report problems with top, e.g.,

==6004== at 0x804ADD0: (within /usr/bin/top)
==6004== Address 0x1BACBCC0 is 0 bytes after a block of size 240 alloc'd
==6004== at 0x1B90506F: realloc (vg_replace_malloc.c:196)
==6004== by 0x804B40F: (within /usr/bin/top)
==6004== by 0x1B9A7E35: __libc_start_main (libc-start.c:242)
==6004== by 0x8049800: (within /usr/bin/top)
==6004==
==6004== Invalid write of size 1
==6004== at 0x1B905B97: memcpy (mac_replace_strmem.c:298)
==6004== by 0x804ADF1: (within /usr/bin/top)
==6004== Address 0x1BACBCC0 is 0 bytes after a block of size 240 alloc'd
==6004== at 0x1B90506F: realloc (vg_replace_malloc.c:196)
==6004== by 0x804B40F: (within /usr/bin/top)
==6004== by 0x1B9A7E35: __libc_start_main (libc-start.c:242)
==6004== by 0x8049800: (within /usr/bin/top)
==6004==
==6004== Invalid write of size 1
==6004== at 0x1B905B9E: memcpy (mac_replace_strmem.c:299)
==6004== by 0x804ADF1: (within /usr/bin/top)
==6004== Address 0x1BACBCC1 is 1 bytes after a block of size 240 alloc'd
==6004== at 0x1B90506F: realloc (vg_replace_malloc.c:196)
==6004== by 0x804B40F: (within /usr/bin/top)
==6004== by 0x1B9A7E35: __libc_start_main (libc-start.c:242)
==6004== by 0x8049800: (within /usr/bin/top)

> I'm trying to see if it is/was a top problem, a xterm problem, a library
> (eg ncurses) problem or some combination.

I'm thinking it's top, since it's a termcap application - running strings on
the executable shows me that. If it used initscr/newterm, it's still possible
to abuse ncurses' resizeterm, but something for me to verify.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[philips (brandon-ifup)]

Package: procps
Version: 1:3.2.6-2.1
Followup-For: Bug #256376

Hello-

I recompiled procps-3.2.6 with CFLAGS="-ggdb -O" and received the
following backtraces when running from a terminal with a very small
height.

After looking at the code it seems that the
free(*table[curmax]->cmdline) line is only reached when a terminal is
resized to a very tiny height.

Hopefully that can lead someone down the way to a patch.

 Brandon

1107 free(*table[curmax]->cmdline);
(gdb) bt
#0 0x0804b80d in procs_refresh (table=0x80650d0, flags=73) at top.c:1107
#1 0x0804ef25 in summary_show () at top.c:2934
#2 0x08051651 in frame_make () at top.c:3274
#3 0x080518e2 in main (dont_care_argc=1, argv=0x2) at top.c:3339

Program received signal SIGABRT, Aborted.
0xb7e647c7 in raise () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7e647c7 in raise () from /lib/tls/libc.so.6
#1 0xb7e6606b in abort () from /lib/tls/libc.so.6
#2 0xb7e9b545 in __fsetlocking () from /lib/tls/libc.so.6
#3 0xb7ea398e in free () from /lib/tls/libc.so.6
#4 0xb7ea43f9 in realloc () from /lib/tls/libc.so.6
#5 0x0804b2c3 in alloc_r (q=0x0, numb=702) at top.c:898
#6 0x0804e084 in wins_resize () at top.c:2416
#7 0x0805190d in main (dont_care_argc=1, argv=0xb7f6eff4) at top.c:3340

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages procps depends on:
ii libc6 2.3.6-3 GNU C Library: Shared libraries an
ii libncurses5 5.5-1 Shared libraries for terminal hand

Versions of packages procps recommends:
ii psmisc 22.1-1 Utilities that use the proc filesy

-- no debconf information

[Carthik Sharma (carthik)]

Thank you for reporting this bug, and sorry for the much-delayed response.

Is this bug still present in the latest Dapper packages?

If yes, can you please provide a list of steps to try and recreate this bug?

If it is not, or if someone knows that this bug has been fixed by a subsequent upload, please let us know so we can close this. The last activity on this bug was over 5 months ago.

[Craig Small (csmall)]

I think this may of been fixed in procps 3.2.6, it looks like Debian bug #320289

[Vassilis Pandis (pandisv)]

Still an issue on Edgy.

[Vassilis Pandis (pandisv)]

Similar issue in Gentoo's bugtracker http://bugs.gentoo.org/show_bug.cgi?id=132894

[Vassilis Pandis (pandisv)]

Added a debian bug watch - I'm not absolutely sure this is the same problem. The stacktrace here is a different one (and a corrupt one, mind you).

[didier (did447-deactivatedaccount)]

Same on edgy ppc, guess it's a case of doing do much work in signal handler because it doesn't segfault when run with gdb.

[Jeremiah Orem (oremj)]

Package: procps
Version: 1:3.2.7-3
Followup-For: Bug #256376

This patch fixes the top segfault when resizing the terminal to a
small size. It does not reallocate memory for every resize. Instead
it only allocates memory if the new window size is larger than the
current window size.

[Jeremiah Orem (oremj)]

Package: procps
Version: 1:3.2.7-3
Followup-For: Bug #256376

After further review it looks like PUFF is not checking if it has
enough memory to write on. This is a simple fix to the problem.

[Paul van Genderen (paulvg)]

Reproduceable on Feisty beta, both patches here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256376 solve the problem

[Craig Small (csmall)]

On Tue, Mar 13, 2007 at 06:36:32PM -0700, Jeremiah Orem wrote:
> This patch fixes the top segfault when resizing the terminal to a
> small size. It does not reallocate memory for every resize. Instead
> it only allocates memory if the new window size is larger than the
> current window size.
It failed to compile:

top.c: In function 'show_special':
top.c:682: error: incompatible type for argument 1 of 'realloc'
top.c:682: error: incompatible types in assignment
top.c:682: warning: assignment discards qualifiers from pointer target type

I'm not sure what is going on here. I'll have a dig around but you might
want to see for yourself too.

--
Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/ csmall at : enc.com.au
http://www.debian.org/ Debian GNU/Linux, software should be Free

[Ted M Lin (kitlaan)]

Hi,

Just like to add a few comments. I'm running procps 3.2.1-2.
I get the same segfault on my set-up under the console, xterm, and via
ssh/putty.

I have a 24 processor setup, so when I enable the all-cpu view (by pressing
'1'), a regular 80x24 console will cause top to segfault. With a larger
row-count, the display has no problems.

As a sanity check, a 16-processor display will not segfault on 80x24, but
80x18 will.

On a regular uniprocessor setup (3.2.7-3), reducing the terminal to 80x3
will cause the segfault. As seen previously, reducing the terminal size
while top is running causes a segfault (e.g. 80x24 resized to 80x5 or
smaller). Some other resizing caused a realloc() abort (80x4 resized to
something larger).

- Ted

[Jan Christoph Nordholz (hesso)]

tags 256376 + patch
thankyou

Hi Craig,

this update fixes the syntax error and adds another line Jeremiah had
apparently forgotten. Now it Works For Me[tm]... I can resize top at
will (down to 1 line and back to 60) without problems.

Regards,

Jan

[Craig Small (csmall)]

Source: procps
Source-Version: 1:3.2.7-4

We believe that the bug you reported is fixed in the latest version of
procps, which is due to be installed in the Debian FTP archive:

libproc-dev_3.2.7-4_i386.deb
  to pool/main/p/procps/libproc-dev_3.2.7-4_i386.deb
procps_3.2.7-4.diff.gz
  to pool/main/p/procps/procps_3.2.7-4.diff.gz
procps_3.2.7-4.dsc
  to pool/main/p/procps/procps_3.2.7-4.dsc
procps_3.2.7-4_i386.deb
  to pool/main/p/procps/procps_3.2.7-4_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Craig Small <email address hidden> (supplier of updated procps package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 08 Aug 2007 20:27:55 +1000
Source: procps
Binary: procps libproc-dev
Architecture: source i386
Version: 1:3.2.7-4
Distribution: unstable
Urgency: low
Maintainer: Craig Small <email address hidden>
Changed-By: Craig Small <email address hidden>
Description:
 libproc-dev - library for accessing process information from /proc
 procps - /proc file system utilities
Closes: 256376 292721 341272 343620 354255 389395 413383 423704 425492
Changes:
 procps (1:3.2.7-4) unstable; urgency=low
 .
   * top exits with correct code Closes: #341272, #354255
   * sysctl malloc extended by 1 Closes: #423704
   * sysctl.conf has both rp_filter lines Closes: #389395
   * Updated top.c resize patch Closes: #256376
   * Changed /proc message Closes: #292721
   * Correct return code for pgrep Closes: #413383
   * Correct return code for vmstat Closes: #425492
   * init script lost it .sh we dont need it Closes: #343620
   * Adjusted the shlibs so they are more relaxed.
Files:
 74543a6eb230d3d6d17711dc382e261b 612 admin required procps_3.2.7-4.dsc
 3770deba345696cd95cce4f9a400586b 38130 admin required procps_3.2.7-4.diff.gz
 6a15fae9cd0b76978d0bc83cc7151f19 220584 admin required procps_3.2.7-4_i386.deb
 b12e7280f2cae07554547edf32b29788 56086 libdevel optional libproc-dev_3.2.7-4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGubBdx2zlrBLK36URAjefAKCP1UJMJxcLDwEuJ4Ty3Egr91eIWACgnleQ
5e2tbLCAtm9aEn2i/P6nqaY=
=p/cz
-----END PGP SIGNATURE-----

[Debbugs Internal Request (owner-bugs)]

# A New Hope
# A log time ago, in a galaxy far, far away
# something happened.
#
# Magically this resulted in the following
# action being taken, but this fake control
# message doesn't tell you why it happened
#
# The action:
# Bug archived.
thanks
# This fakemail brought to you by your local debbugs
# administrator

[Koen (koen-beek)]

Still happens on gutsy amd64
uname : 2.6.22-14-generic #1 SMP Tue Dec 18 05:28:27 UTC 2007 x86_64 GNU/Linux
procps 1:3.2.7-3ubuntu5

Does not happen on latest hardy amd64 (in vmware)
uname : 2.6.24-4-generic #1 SMP Mon Jan 14 18:19:11 UTC 2008 x86_64 GNU/Linux
procps 1:3.2.7-5ubuntu1

I include a screencastt of what happens on gutsy

[Koen (koen-beek)]

according to the debian bug report this issue was fixed in 1:3.2.7-4 - so fixed in hardy (1:3.2.7-5ubuntu1) -> fix released for ubuntu ?