From kargl@troutmask.apl.washington.edu  Fri Jan 20 20:12:09 2006
Return-Path: <kargl@troutmask.apl.washington.edu>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id ECD5016A41F
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 20 Jan 2006 20:12:09 +0000 (GMT)
	(envelope-from kargl@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5678143D46
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 20 Jan 2006 20:12:09 +0000 (GMT)
	(envelope-from kargl@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k0KKC87J026618
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 20 Jan 2006 12:12:08 -0800 (PST)
	(envelope-from kargl@troutmask.apl.washington.edu)
Received: (from kargl@localhost)
	by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k0KKC8HM026617;
	Fri, 20 Jan 2006 12:12:08 -0800 (PST)
	(envelope-from kargl)
Message-Id: <200601202012.k0KKC8HM026617@troutmask.apl.washington.edu>
Date: Fri, 20 Jan 2006 12:12:08 -0800 (PST)
From: "Steven G. Kargl" <kargl@troutmask.apl.washington.edu>
Reply-To: "Steven G. Kargl" <kargl@troutmask.apl.washington.edu>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: top(1) aborts in redzone
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         92074
>Category:       bin
>Synopsis:       [patch] top(1) aborts in redzone
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    edwin
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 20 20:20:06 GMT 2006
>Closed-Date:    Thu Sep 25 21:21:49 UTC 2008
>Last-Modified:  Thu Sep 25 21:21:49 UTC 2008
>Originator:     Steven G. Kargl
>Release:        FreeBSD 7.0-CURRENT amd64
>Organization:
APL/UW
>Environment:
System: FreeBSD troutmask.apl.washington.edu 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Jan 19 13:50:25 PST 2006 kargl@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64


	
>Description:
	
75 processes:  5 running, 70 sleeping
CPU states: 98.3% user,  0.0% nice,  1.7% system,  0.0% interrupt,  0.0% idle
Mem: 586M Active, 1202M Inact, 200M Wired, 20K Cache, 214M Buf, 9752M Free
Swap: 17G Total, 17G Free

top: (malloc) Corrupted redzone 1 byte after 0x2020056f0 (size 1975) (0x0)D
Abort (core dumped) 1 132    0   295M   257M RUN    0   5:07 93.95% scat   
troutmask:kargl[202]  132    0   295M   257M RUN    0   5:02 93.26% scat

The above happened as I was resizing an xterm with an
actively run top(1).  This is on amd64 with malloc.c
v 1.100.

>How-To-Repeat:

>Fix:



>Release-Note:
>Audit-Trail:

From: Giorgos Keramidas <keramida@freebsd.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/92074: top(1) aborts in redzone
Date: Mon, 23 Jan 2006 05:28:17 +0200

 Adding to audit trail:
 
 % Date: Fri, 20 Jan 2006 21:20:59 +0100
 % From: Fredrik Lindberg <fli+freebsd-current@shapeshifter.se>
 % Subject: Re: top(1) aborts in redzone
 % To: Giorgos Keramidas <keramida@ceid.upatras.gr>
 % Cc: freebsd-current@freebsd.org, jasone@freebsd.org,
 %         Steve Kargl <sgk@troutmask.apl.washington.edu>
 %
 % It's writing past its buffer when a line gets truncated.
 % Either increase the buffer by one, or decrease the offset on the
 % places where it is manupulating the buffer.
 % Both solutions work (I tried them), the easiest one is attached.
 %
 % Fredrik Lindberg
 %
 % Index: display.c
 % ===================================================================
 % RCS file: /home/ncvs/src/contrib/top/display.c,v
 % retrieving revision 1.9
 % diff -u -r1.9 display.c
 % --- display.c   19 May 2005 13:34:19 -0000      1.9
 % +++ display.c   20 Jan 2006 20:18:03 -0000
 % @@ -114,7 +114,7 @@
 %      }
 %
 %      /* now, allocate space for the screen buffer */
 % -    screenbuf = (char *)malloc(lines * display_width);
 % +    screenbuf = (char *)malloc(lines * (display_width + 1));
 %      if (screenbuf == (char *)NULL)
 %      {
 %         /* oops! */
 
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Tue Jul 10 15:49:12 UTC 2007 
State-Changed-Why:  
Closed at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92074 
State-Changed-From-To: closed->open 
State-Changed-By: linimon 
State-Changed-When: Wed Jul 11 22:20:26 UTC 2007 
State-Changed-Why:  
Although submitter has lost interest in this one, on second examination 
it sounds as though it might still be a problem, so reopen. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92074 

From: Jaakko Heinonen <jh@saunalahti.fi>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/92074: top(1) aborts in redzone
Date: Fri, 15 Feb 2008 19:52:31 +0200

 --n8g4imXOkfNTN/H1
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 
 I can reproduce this bug. After a research I found three bugs from
 top(1):
 
 1) Off-by-one error mentioned earlier in this PR.
 
 2) In u_process bufferline is not NULL-terminated. It's later passed to
 strlen(3) in line_update().
 
 3) line_update() references an invalid memory location when
 display_width is 0 (terminal is one character wide).
 
 The attached patch should fix these.
 
 -- 
 Jaakko
 
 --n8g4imXOkfNTN/H1
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="top-resize-crash.diff"
 
 Index: display.c
 ===================================================================
 RCS file: /home/ncvs/src/contrib/top/display.c,v
 retrieving revision 1.10
 diff -u -r1.10 display.c
 --- display.c	18 Jan 2008 01:43:13 -0000	1.10
 +++ display.c	15 Feb 2008 12:36:03 -0000
 @@ -139,7 +139,7 @@
      }
  
      /* now, allocate space for the screen buffer */
 -    screenbuf = (char *)malloc(lines * display_width);
 +    screenbuf = (char *)malloc(lines * display_width + 1);
      if (screenbuf == (char *)NULL)
      {
  	/* oops! */
 @@ -801,6 +801,7 @@
  
      /* truncate the line to conform to our current screen width */
      newline[display_width] = '\0';
 +    bufferline[display_width] = '\0';
  
      /* is line higher than we went on the last display? */
      if (line >= last_hi)
 @@ -1137,6 +1138,9 @@
      fputs(new, debug);
      fputs("\n-\n", debug);
  #endif
 +
 +    if (display_width < 1)
 +        return;
  
      /* start things off on the right foot		    */
      /* this is to make sure the invariants get set up right */
 
 --n8g4imXOkfNTN/H1--
State-Changed-From-To: open->feedback 
State-Changed-By: edwin 
State-Changed-When: Thu Sep 25 15:53:39 UTC 2008 
State-Changed-Why:  
> The above happened as I was resizing an xterm with an 
> actively run top(1).  This is on amd64 with malloc.c 
> v 1.100. 

Resizeing from which size to which size? I had it here in an xterm 
of 1x3 and 1200x400 and it kept working. 

I would like to see if this is resolved with the upgrade to 3.8b1 
so I need to know how to reproduce it. 



Responsible-Changed-From-To: freebsd-bugs->edwin 
Responsible-Changed-By: edwin 
Responsible-Changed-When: Thu Sep 25 15:53:39 UTC 2008 
Responsible-Changed-Why:  
I'll trakc it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92074 

From: Jaakko Heinonen <jh@saunalahti.fi>
To: edwin@FreeBSD.org
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/92074: [patch] top(1) aborts in redzone
Date: Thu, 25 Sep 2008 22:19:32 +0300

 Hi,
 
 On 2008-09-25, edwin@FreeBSD.org wrote:
 > Resizeing from which size to which size? I had it here in an xterm
 > of 1x3 and 1200x400 and it kept working.
 > 
 > I would like to see if this is resolved with the upgrade to 3.8b1
 > so I need to know how to reproduce it.
 
 The bugs that I describe in the audit trail are real. You may need a
 malloc debugger reproduce the crash reliably.
 
 Here's how to reproduce it with devel/ElectricFence:
 
 1) make sure that devel/ElectricFence port is installed
 2) start xterm
 3) $ sh
    $ LD_PRELOAD=/usr/local/lib/libefence.so.0 top
 4) reduce the terminal width to one column
 
 A quick look at top 3.8b1 suggests that the bug(s) has been fixed. (The
 code in question has changed and I can't reproduce.)
 
 Thank you for working on top(1).
 -- 
 Jaakko
State-Changed-From-To: feedback->closed 
State-Changed-By: edwin 
State-Changed-When: Thu Sep 25 21:21:09 UTC 2008 
State-Changed-Why:  
Thanks to Jaakko the problem was determinable and confirmed not to happen 
anymore in the 3.8b1 version of top(1). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92074 
>Unformatted:
