Thanks that explains why the pool error keeps happening after building.
I wasn't able to set ulimit at 8GB + a little bit because other libraries 
need to be loaded

with 8.5GB on the ulimit
Warning: error initializing module CHOLMOD:
ErrorException("could not load module libcholmod: libblas.so.3: failed to 
map segment from shared object: Cannot allocate memory")
Warning: error initializing module LinAlg:
ErrorException("could not load module libopenblas: 
/usr/lib/libopenblas.so.0: failed to map segment from shared object: Cannot 
allocate memory")


but at 9GB everything is fine. I use ulimit to prevent myself from doing 
something that uses way more memory than I expected it to. I would rather a 
process die than swap forever.

On Friday, April 10, 2015 at 7:16:31 PM UTC-4, [email protected] wrote:
>
> See also https://github.com/JuliaLang/julia/issues/10390
>
> On Saturday, April 11, 2015 at 6:44:43 AM UTC+10, James Fairbanks wrote:
>>
>> I ran into this problem today and removing the ulimit -v in my .bashrc 
>> resolved it. 
>> Is this a real bug or just the fact that you need a lot of memory to 
>> build everything and if the memory limit is too low this is the error 
>> message?
>>
>> On Sunday, March 22, 2015 at 11:02:38 AM UTC-4, [email protected] 
>> wrote:
>>>
>>> I confirm that removing  "ulimit -Sv 5000000" from .bashrc allows me to 
>>> build Julia, or at least advances me to the next, unrelated problem.
>>> Thanks.
>>>
>>> On Tuesday, March 3, 2015 at 4:40:40 PM UTC+1, Jonathan Anderson wrote:
>>>>
>>>> I have the same problem (user janders cannot build julia: 
>>>> https://gist.github.com/JonathanAnderson/7fa10f187c564c864817). I 
>>>> thought it might be related to a ulimit restriction placed on my userid so 
>>>> I built with a different userid that has no limit.
>>>>
>>>> This userid is able to build everything successfully on the same host 
>>>> that my build failed on.
>>>>
>>>> The following data point is also interesting.... 
>>>>
>>>> I copied the built software onto a NFS partition that ignores ownership 
>>>> and everything is a+rwx
>>>> * When I run this build as the userid that built the software, I can 
>>>> run the build
>>>> * If I run as the userid researcher, I can run this build
>>>> * If I run as my original userid (janders) I get the "could not 
>>>> allocate pools"
>>>>
>>>> Here is janders' ulimit -a
>>>>
>>>> ulimit -a
>>>> -t: cpu time (seconds)         unlimited
>>>> -f: file size (blocks)         unlimited
>>>> -d: data seg size (kbytes)     unlimited
>>>> -s: stack size (kbytes)        8192
>>>> -c: core file size (blocks)    unlimited
>>>> -m: resident set size (kbytes) unlimited
>>>> -u: processes                  256722
>>>> -n: file descriptors           1024
>>>> -l: locked-in-memory size (kb) unlimited
>>>> -v: address space (kb)         8000000
>>>> -x: file locks                 unlimited
>>>> -i: pending signals            256722
>>>> -q: bytes in POSIX msg queues  819200
>>>> -e: max nice                   40
>>>> -r: max rt priority            unlimited
>>>> -N 15:                         unlimited
>>>>
>>>> What else can I provide to debug this?
>>>>
>>>> On Friday, February 27, 2015 at 7:18:55 AM UTC-6, [email protected] 
>>>> wrote:
>>>>>
>>>>> Anyone know something about this ?
>>>>>
>>>>> I did not build the latest Julia (master branch) since about 30 days.
>>>>> Now, when I do 'git pull' and 'make' I am getting various error 
>>>>> messages:
>>>>>
>>>>>    could not allocate pools
>>>>>    Aborted
>>>>>    Makefile:165: recipe for target 
>>>>> '/home/jlapeyre/software_source/julia/usr/lib/julia/sys0.o' failed
>>>>>
>>>>> This was a few days ago, so I 'pulled' every once in a while, hoping 
>>>>> the problem would go away.
>>>>> I tried make clean, make cleanall, make distcleanall. Then 
>>>>> dependencies also fail to build
>>>>> I removed even the packages with   make -C deps distcleanall.
>>>>>
>>>>> I have not changed my tool chain since the last successful build. I 
>>>>> can't recall, but there is a
>>>>> chance (but, I think not) that I moved the entire repository from one 
>>>>> place to another.
>>>>>
>>>>> Since I don't see any noise about this, something tells me its not a 
>>>>> common problem.
>>>>>
>>>>> --John
>>>>>
>>>>

Reply via email to