bin/129706: top(1) corrupts SIZE field when a process allocates 2048GB memory

[Garrett Cooper]

The following reply was made to PR bin/129706; it has been noted by GNATS.

From: "Garrett Cooper" <yanefbsd at gmail.com>
To: "Bruce Cran" <bruce at cran.org.uk>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: bin/129706: top(1) corrupts SIZE field when a process allocates 2048GB memory
Date: Tue, 16 Dec 2008 22:51:42 -0800

 On Tue, Dec 16, 2008 at 10:30 PM, Bruce Cran <bruce at cran.org.uk> wrote:
 >
 >>Number:         129706
 >>Category:       bin
 >>Synopsis:       top(1) corrupts SIZE field when a process allocates 2048GB memory
 >>Confidential:   no
 >>Severity:       non-critical
 >>Priority:       low
 >>Responsible:    freebsd-bugs
 >>State:          open
 >>Quarter:
 >>Keywords:
 >>Date-Required:
 >>Class:          sw-bug
 >>Submitter-Id:   current-users
 >>Arrival-Date:   Wed Dec 17 06:40:01 UTC 2008
 >>Closed-Date:
 >>Last-Modified:
 >>Originator:     Bruce Cran
 >>Release:        7.1-RC1
 >>Organization:
 >>Environment:
 > FreeBSD 7.1-RC1 amd64
 >>Description:
 > When a process allocates over 2TB, top can corrupt the SIZE field and display a series of characters instead.  It only appears to happen on TB boundaries - i.e 2048GB, 3072GB etc.  7.1-RC1 and 8-CURRENT (from 2008-12-15) both show the problem.
 >>How-To-Repeat:
 > Compile the following code and once running run top to see the process listed.
 >
 > #include <stdlib.h>
 > int main(void)
 > {
 >  char *c = malloc(2048LL*1024*1024*1024);
 >  getchar();
 >  return 0;
 > }
 
 Although I'd love to say it's top, it sounds more like a weird corner
 case dealing with overflow / underflow and vmem allocation.
 -Garrett