Path: utzoo!utgpu!watserv1!ria!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rutgers!bellcore!uunet!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.unix.questions
Subject: Re: sbrk(2) question
Message-ID: <4312@skye.ed.ac.uk>
Date: 13 Mar 91 15:42:43 GMT
References: <1991Mar8.180132.12025@Think.COM> <4296@skye.ed.ac.uk> <6582@auspex.auspex.com>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 44

In article <6582@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>Umm, why would it not be zero in that situation?  If the memory has
>truly been released, as in "handed back to the kernel", it should be
>re-zeroed if allocated to a process again.

Yes, of course.

> (I.e., calling "sbrk()" with
>a negative argument, in most if not all versions of UNIX, doesn't just
>set some user-mode pointer so that the memory stays in the address space
>of the process.)

Even if it does this, will it not release memory in page-size units?
A quick check on a Sun, Sequent, BSD Vax and Orion all reveal that the
bytes before the first page boundary in the (re-)allocated space are
unzeroed (and indeed contain the data unchanged from before).

So you can't rely on sbrk() space to be completely zeroed, unless you're
sure nothing has already allocated and freed memory.  And you can't be
sure of that (maybe the system did it before calling main(), for example).

While experimenting, I was reminded of another hazard of sbrk().  For
example, this program produces a segmentation fault on a Sun4 under
SunOS 4.1:

    #include <stdio.h>
    
    extern char *sbrk();
    
    main()
    {
        sbrk(100000);
        printf("hello world\n");
        sbrk(-100000);
        printf("hello again\n");
    
        exit(0);
    }

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin