Re: SIGKILL on kbsd

2013-07-04 Thread Camm Maguire
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

SIGKILL on kbsd

2013-06-25 Thread Camm Maguire
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. (sid_kfreebsd-amd64-dchroot)camm@falla:~/gcl-2

Re: SIGKILL on kbsd

2013-06-25 Thread Robert Millan
2013/6/25 Camm Maguire : > 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 rela

Re: SIGKILL on kbsd

2013-06-24 Thread Robert Millan
2013/6/25 Camm Maguire : > Greetings! > > If I can allocate memory with (s)brk, why do I get a SIGKILL when > reading it on kbsd, but not on Linux? > > (see http://pastebin.com/c1dCDc9U) This doesn't say much. Can we see your sbrk() calls? Btw I vaguely recall the sbrk() syscall not being the sam

SIGKILL on kbsd

2013-06-24 Thread Camm Maguire
Greetings! If I can allocate memory with (s)brk, why do I get a SIGKILL when reading it on kbsd, but not on Linux? (see http://pastebin.com/c1dCDc9U) Thanks! -- Camm Maguirec...@maguirefamily.org =