I have program that allocates four 768MB blocks of contiguous memory (total of 3GB = 4x768MB) and runs some operations on them. The after the first call (which successfully allocates the memory), the next 3 return NULL as if there was no memory available. Well... The system I work on is an Enterprise 420R 4xUltraSPARC II 400MHz with 4GB RAM. Running 'top' shows that right before running, there is 3667MB of free RAM, and 1024MB of swap available. This should be more than enough to allocate 3GB of RAM, or at least one more 768MB block (for a total of 1.5GB). I compiled this program as a 64 bit program using GCC, so I don't think it should be hitting the line for > 32 bit pointers. Even still, an x86 box could theoretically run this program too. I have successfully compiled and tested the program under Solaris 10, so I don't think there is an error in my source code. Running 'prstat' on Solaris 10 (similar to 'top' if you haven't used Solaris) shows the appropriate 3072MB of allocated RAM. FreeBSD should be able to allocate > 3GB of RAM on a 64 bit architecture, especially a 64 bit architecture. Fix: Allow large allocations? Patch attached with submission follows: How-To-Repeat: Run the test program included. Fails every time at allocation #2. $ gcc -m64 -O3 dist_fma.c -o dist_fma $ ./dist_fma
State Changed From-To: open->feedback Could you see whether you still have the same problem on more recent releases (6.3 or 7.0)? I've been able to run your program on 7.0, with top showing PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 875 gahr 1 120 0 3077M 64K RUN 0:32 32.14% dist_fma
State Changed From-To: feedback->closed Feedback timeout (~1 year). This is believed to be fixed, and appears to work on 7.0. To submitter: if this is still an issue, we can reopen this PR.