Re: More toolchain issues

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

On Sun, 27 Sep 2009, Frank Wille wrote:

> >   Can you tell (perhaps from pmap(1)) where the data memory is being
> > allocated.  I'm guess that perhaps at least jemalloc allocates memory
> > by mmaping address space outside the 'reserved' space for a process.
>
> This is from nmap, while segfaulting when having reached the 64MB limit:

  And it shows what I suspected...

> 00002000    736K read/exec         /usr/pkg/bin/nmap
> 000BA000    280K read/write          [ anon ]

  The process text starts at 00002000, with the data area starting at 
000BA000.  The data area would be the initial data and bss of the 
executable.  The 128MB from 000BA000 to 080BA000 is the space 'reserved' 
for the process data.

  Shared library text and data are mmapped starting at 080BA000.

> 080BA000     48K read/exec         /libexec/ld.elf_so
> 080C6000     16K read/write          [ anon ]
> 080CA000      8K read/exec           [ uvm_aobj ]
> 080CC000     32K read/write          [ anon ]
...
> 084BE000     56K read/write          [ anon ]
> 084CC000     24K read/exec         /lib/libcrypt.so.0.2
> 084D2000      8K read/write        /lib/libcrypt.so.0.2
> 084D4000     56K read/write          [ anon ]

  This is likely where malloc() allocated memory - outside the area where 
the process data is normally expected to be.

> 08500000   1024K read/write          [ anon ]
> 08600000   1024K read/write          [ anon ]
...
> 0BE00000   1024K read/write          [ anon ]
> 0BF00000   1024K read/write          [ anon ]

  And we have now allocated all the remaining user address space and hit 
the stack area - well less than the 128MB memory limit.

> 0C000000  30720K                     [ stack ]
> 0DE00000   1920K read/write          [ stack ]
> 0DFE0000    128K read/write          [ stack ]
> total    67736K

  Most ports probably don't see this behaviour because they are configured 
with a much larger user address space and most likely have plenty of space 
between the shared libraries and stack to allocate memory.

  I would say this is partially the fault of jemalloc because it does not 
utilize the process address space 'reserved' for user data (and possibly
the kernel because it starts mmap memory after the max user (text + data) 
address space), and partially because of the amiga's small user address 
space configuration.

  That limited user address space configuration is apparently due to 
trying to compatible with SunOS.  I'm not sure if it's really necessary to 
have the USRSTACK at 0x0e000000 to remain compatible, and I think I may 
have run an old sunos mosaic binary I have with an expanded user address 
space (but I can't remember for sure).  I think the amiga could easily
move USRSTACK to 0x1c000000 [any larger will run into a pmap limitiation 
that can allow user programs to crash a 680[46]0 system].

--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA