[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] SIGKILL on kbsd
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] SIGKILL on kbsd |
Date: |
Thu, 04 Jul 2013 11:40:54 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) |
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 <address@hidden> writes:
> 2013/6/25 Camm Maguire <address@hidden>:
>> 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 address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Gcl-devel] SIGKILL on kbsd,
Camm Maguire <=