The default malloc in 1.66, tbb4i or whatever, is pretty much the best available malloc already. I forgot when that change was made (fairly recent IIRC) but I think trying different mallocs is slightly outdated.

@marceldev89 mate, you're not understanding this. Programming is my day job so I know how memory works. Committed memory != virtual memory in Windows. Virtual memory has addresses, that's the entire point of virtual memory - to create the address space. I have said over and over again how Arma's filemapping is great but has limited uses as how having 12GB in a pagefile is not the same as an application using 12GB of RAM.

@tupolov it certainly does!

@SpyderBlack723 thats what I do.

@marceldev I'm not quite sure what "in-use" memory means in Task Manager, but as I said above, "in-use" memory does not necessarily mean "memory currently residing in RAM". Committed memory isn't even necessarily used - committed memory is just the OS saying "hey, this memory is available, so you can use it". So, not sure what you're getting at. Tools like RAMmap and Resource Monitor all show the working set size (actual live memory in RAM) of my ARMA processes to be less than 2GB.

Update: I tried a combination of fixes I mentioned - reducing graphics levels, removing some unit mods like RHS, and reducing spawn distances in ALiVE, and that seems to have completely removed any crashes I'm experiencing. I don't think there's a leak in ALiVE or ARMA at this point, and whatever I was doing was simply too demanding on the engine.

There are lot of misconceptions about memory usage in ARMA in this thread, so let me clear some up:

• ARMA is currently a 32-bit process. This will change to 64-bit soon, but until then, ARMA cannot utilize more than 2GB of RAM on a 32bit OS, and about ~3.5GB of RAM on a 64bit OS. This can be seen in our RPT files - look at "Process Working Set". So upgrading RAM beyond ~6GB does almost nothing for ARMA (of course it helps in general, more room for the operating system, etc.) If you're not running any additional applications while running ARMA, 6GB of RAM would be more than enough.
• ARMA makes excellent use of the pagefile/filesystem memory, as noted in the link, but this system has limits. Not everything can be stored on the disk, because disk access is *orders of magnitude* slower than RAM. So ARMA is probably storing things like textures, units not onscreen, etc on the disk. Basically, think of the pagefile as "things ARMA doesnt need right this second, but needs quick-ish access to later". It seems like this pagefile can get rather large (~10GB) but, again, only certain things can be stored there, and definitely not things that the ARMA engine needs to render the current scene.
• All of our RPT files posted so far contain valuable information - none of us are exhausting the free space of our pagefiles, and we're all running out of virtual memory space. That clearly indicates that the current scene/whatever ARMA is trying to render is too complex.

So, to go back to OP - @raditz5 your spawn ranges and spawn limits are too aggressive. Turn 'em down. I haven't tried them in isolation, but mods and graphics settings may be an aggravating factor.

@marceldev89 I'm not saying that the suggestion isn't valid in any case, I'm saying that @raditz5 's rpt file doesn't suggest it will help. Here's my rpt file from a similar crash .

Both rpts show the same thing - exhaustion of virtual memory, large pagefile, and plenty of page space free. I, for example, have an 8 GB pagefile set on my SSD.

I'm willing to guess as well that there's some kind of pagefile size limit, either imposed by ARMA or Windows. The numbers I've seen in my RPT file, @raditz5 's report file, and the numbers here on the BIS feedback app are all very similar. We all have about ~3.2-3.4 gb pagefiles with large amounts of page file space still free.

If I had to guess, here would be some things that would solve this crash (haven't tested yet):

• Turning down draw distance
• Turning down AI spawn distances in ALiVE
• Lower graphics settings (maybe not - I would think this affects video memory memory, which isn't an issue)

ARMA can only page out memory to the pagefile if it isn't currently required by the engine - so running out of virtual memory here suggests that we're just placing too high a load on the engine and need to dial it back, thus my suggestions above.

I don't see how changing the paging file would help in this case, as the virtual address space has been exhausted. Changing the swap/pagefile size doesn't change that situation. You can also see in his RPT that he has over 1.7GB free in the pagefile.

The reporter (and I) are coming up against fundamental memory limits of a 32bit process. That can either be caused by a leak or simply just trying to use too much memory at once. Either of these is possible.

I'm having the same problem.

@SpyderBlack723 - a 32-bit process cannot allocate more than 4GB of virtual memory on a 64-bit OS. So you can't just "increase the virtual memory" given to ARMA.

This is probably a leak, as I only see the OOM crash after going in and out of SP preview in the editor a few times. The new 64-bit client will probably partly fix this, although then we're gonna start running out physical RAM rather than virtual. At least it will take longer! :D