Re: tlug: gcc question

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Fredric" == Fredric Fredricson <fredric.fredriksson@example.com> writes:

    Fredric> "Stephen J. Turnbull" wrote:

    >> No, because GNU malloc (some version of which is used in all
    >> Linux systems AFAIK) breaks up the memory it gets from sbrk()
    >> into reasonably-sized pieces.  In old GNU malloc, you only get
    >> all the raw memory as returned by sbrk if you are allocating
    >> more memory than the malloc BLOCKSIZE, which is 2048 bytes on
    >> 32 bit systems.  I don't know what Doug Lea malloc does,
    >> though.

    Fredric> Eh... I dont't quite follow you here. It's probably me...

My point was simply that malloc is designed to allocate memory in
multiples of the pagesize if I understand the code correctly.  As long
as you use only malloc (and don't call sbrk directly) you cannot tell
that sbrk is there.  Apparently the malloc blocksize is too small (2k
vs. sbrk's 4k, the docs don't say for sbrk---I thought sbrk was in 1k
pages, but the test program clearly shows 4k), in which case you would
be able to tell (if you could figure out where malloc's pool
supposedly ends).

    Fredric> Malloc use sbrk(2) (or brk(2)) to ask the kernel for more
    Fredric> memory when it needs it (there are btw probably also
    Fredric> other ways than sbrk(2) to do this).

The man page doesn't say so, but there may be a POSIX way to get
memory (brk and sbrk are not POSIX).

    Fredric> Consider the following c program:

It works for me too, although I don't know how offhand to determine
whether malloc is requesting integral multiples of the pagesize from
sbrk.

However, I do not get all the way to the end of the segment; in my
case, the stdout buffer doesn't get flushed before the SEGV occurs.
What version of glibc do you have?  (Mine is glibc 2.1.2, Debian
package revision 10.)

    Fredric> There may be more than one way to interpret the result
    Fredric> above but my interpretation is that the process can have
    Fredric> more memory assigned to it than sbrk(2) reports.

Strictly speaking, sbrk doesn't report how much memory you have, just
whether you can use as much memory as you requested or not.

But you are correct that sbrk requests 4kB at a crack, so that a
malloc block of 2kB will only fill half the page and you can
(presumably, I don't know how to test this offhand since malloc
doesn't tell you where it is relative to sbrk's pointers) write beyond
what malloc reports.

    Fredric> The existence of this package also suggests that it is
    Fredric> not standard malloc procedure to do so.

No, it's not; this would be a very inefficient thing to do.

    Fredric> When I use my S.u.s.e. 6.3 Linux to compile and examine
    Fredric> the heap it sure looks like there are some data between
    Fredric> the allocated memory chunks that probably is part of the
    Fredric> malloc data structures. Looks like 5 bytes if data. Maybe
    Fredric> this data is redundant.

I could be wrong; I didn't read the code carefully, but it looked to
me like all the accounting information for the old GNU malloc was kept
in a separate data structure.  The new Doug Lea malloc used in recent
glibc may use a variant on the classic "link pointer plus flag bits"
strategy, which keeps that information inside the (system) allocated
block.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
-------------------------------------------------------------------
Next Technical Meeting: January 14 (Fri) 19:00
* Topic: "glibc - current status and future developments"
* Guest Speaker: Ulrich Drepper (Cygnus Solutions)
* Place: Oracle Japan HQ 12F Seminar Room (New Otani Garden Court)
-------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan