Re: GCC 4.8 out of memory

[Frank Wille <frank%phoenix.owl.de@localhost>]

I wrote:

> This would mean there is not a single byte left for heap (MAP_ANON)
> allocations. Or am I missing something again?

Calling pmap(1) with a MAXDSIZ=416MB kernel answers my question:

# pmap
00002000    112K read/exec           [ ?? 0x36eb5c ?? ]
0001E000      8K read/write          [ ?? 0x36eb5c ?? ]
00020000      8K read/write          [ anon ]
00022000    888K read/write          [ anon ]
1A01E000     56K read/exec           [ ?? 0x36eb5c ?? ]
1A02C000     80K read/write          [ anon ]
1A040000    136K read/exec           [ ?? 0x36eb5c ?? ]
1A062000     24K read/write          [ ?? 0x36eb5c ?? ]
1A068000      8K read/write          [ anon ]
1A06A000     48K read/exec           [ ?? 0x36eb5c ?? ]
1A076000      8K read/write          [ ?? 0x36eb5c ?? ]
1A078000     48K read/exec           [ ?? 0x36eb5c ?? ]
1A084000      8K read/write          [ ?? 0x36eb5c ?? ]
1A086000   1080K read/exec           [ ?? 0x36eb5c ?? ]
1A194000    144K read/write          [ ?? 0x36eb5c ?? ]
1A1B8000     64K read/write          [ anon ]
1A200000   1024K read/write          [ anon ]
1C000000  30720K                     [ stack ]
1DE00000   1920K read/write          [ stack ]
1DFE0000    128K read/write          [ stack ]
 total     5792K

It looks like the whole address space for MAXDSIZ (0x1a000000) is reserved,
before the space for heap and shared objects starts at 0x1a01e000. This is
not the case for MAXTSIZ. Does that make sense? Or is this a bug?

But it clearly shows that I can allocate 30MB in this state, before running
out of memory, which is what I have observed.

-- 
Frank Wille