Date: Wed, 17 Dec 2008 07:00:05 GMT From: "Garrett Cooper" <yanefbsd@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/129706: top(1) corrupts SIZE field when a process allocates 2048GB memory Message-ID: <200812170700.mBH705si075271@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR bin/129706; it has been noted by GNATS.
From: "Garrett Cooper" <yanefbsd@gmail.com>
To: "Bruce Cran" <bruce@cran.org.uk>
Cc: freebsd-gnats-submit@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@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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812170700.mBH705si075271>