Greetings, and thanks! I've worked around this for now. In general, I was assuming that a successful brk call guaranteed the corresponding allocation of memory, even though it is common for the pages to not actually be added to the process until written. On kfbsd, I limit the break to PHYS_PAGES from sysconf. Linux seems to give a brk failure when the actual allocation would fail, though my testing here is preliminary.
Take care, Robert Millan <r...@debian.org> writes: > 2013/6/25 Camm Maguire <c...@maguirefamily.org>: >> Greetings, and thanks for your reply! This is on falla. The code >> probes for the maximum allocatable data segment at runtime. The ENOMEM >> does not appear conservative enough, as I'm apparently allowed 34Gb, but >> the system has much less virtual memory. > > Might be related to: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661283#53 > > > -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
