Jump to content

Out of Memory error


Recommended Posts

I keep getting this error message along with the game not responding. It is during a pretty large battle(Battalion of infantry along with a company of tanks for each side. Does this mean out of Video Memory, Virtual Memory, or Physical Memory.

I have a Qosmio X505 with Intel i7 Q720. It has 6gigs of Physical Memory, 1 gig of Dedicated video Memory (nVidia Geforce GTS 250M), 12 gigs of virtual memory. I do have a small 50gig solid state hard drive that has my system and some other stuff on it. I just cleared 3 gigs of garbage off of it giving a total of 6.6 gigs free. Could it be that it is running out of room during the game?

Link to comment
Share on other sites

I've had several of these crashes playing a Huge size QB. My laptop has 4 GB, with about 3.2 available, running Win 7 64.

I've noticed that if I exit out of the QB but don't exit completely out of the game, then load the saved game, it runs slower and crashes. So now if I exit the game I'm playing I make sure to exit completely out of the game and restart CMBN before loading it again.

Link to comment
Share on other sites

Yeah Its happened to me a few times too. I think the game is 32bit so it only uses a max of 2 gigs of ram. I'm not sure whether it writes to virtual memory after the physical memory is all used up (sort of like Photoshop writes to a scratch disk). If that is the case... If I have more "scratch disk/virtual memory", will the game go longer before I get this crash? Hopefully at some point they will switch to 64bit so more ram can be allocated to it.

Link to comment
Share on other sites

Warning - geek stuff ahead! I do this in my day job :)

Out of memory in this case means out of virtual address space, which as you say is 2 GB for a normal 32-bit process (the OS is mapped into the other 2 GB). Everything accessed in a particular run of the game, both code and data, needs to find somewhere to sit in that 2 GB. The operating system handles all of this for the programmer, who just says "link this DLL" or "allocate some heap space": the operating system then decides where to put those new objects in the 2 GB address space. Then the 2 GB of virtual addresses are mapped onto real physical addresses in RAM during execution - but these physical addresses change on the fly as bits of code and data are paged in and out of RAM to disk. Your code still has the illusion that "hey, I've got 2 GB of virtual addresses, no problem!" no matter whether it's running on a 1 GB, 2 GB, or 4 GB machine. This is why machines with low physical RAM can run large programs - just verrrrry slowwwwly, because they are constantly swapping code and data in and out of RAM.

An out of memory error means the program tried to load or create something new, and the operating system said "your 2 GB of virtual addresses is full, tough luck!", at which point most programs just roll over and die (it's VERY hard to reliably recover from out-of-memory errors). This isn't always because the 2 GB is actually full - it just means that it's gotten so fragmented that the only free space left is in very small bits, and your code is asking for a contiguous range of addresses that won't fit in any of the small bits left. Sadly there is no way to "defragment" your virtual address space. In my day job I work with code that bumps up against the 1.6-1.7 GB range - once we get to 1.8 GB, a crash is almost certain to occur.

Root causes can be just trying to load too much (very large scenarios), and/or a slow memory leak which gradually fills up the 2 GB with allocated objects that aren't being properly freed (this shows itself as a crash after some playing time). Obviously if you have a very large scenario AND a slow memory leak, then you'll crash sooner.

If you want to look at the virtual address space of a process, then the free VMMap tool from SysInternals (now bought out by Microsoft) is the #1 choice. You can get it from http://technet.microsoft.com/en-us/sysinternals/dd535533.

Here's a VMMap screenshot showing what CMBN's address space looks like just after launch: the important numbers are to the right of the top three bars. Note that it has "committed" (used) 239,856 KB out of that 2 GB, and of that 125,848 KB is in my working set (i.e. in RAM at this instant)

VMMap-Launch.png

Now I load a turn into CMBN, and look how the numbers have shot up. I'm up to 641,500 KB committed, and all of the growth is in heap space (the orange section of the bar), which makes sense since that's used to store game data

VMMap-Turn.png

My bet is that if you load a huge scenario, play for a while, and then take a VMMap snapshot, you'll see that the committed space is up above 1.5 GB. If you keep playing and it keeps steadily increasing, that's probably a leak. And it'll crash before you get to 2 GB.

Link to comment
Share on other sites

Excellent detective work Pondscum. I've been suffering these crashes in Shock Force repeatedly and it was my guess that it was a memory leak of sorts. However, my O/S is Win 7 64 bit so how do you think that fits into this? I haven't played any massive scenario in Normandy yet and have so far had a totally smooth experience.

Link to comment
Share on other sites

Not so much detective work, more a "Virtual Memory 101" introduction :) Good to hear that Battlefront is tracking down the leak.

Most 32-bit processes will act exactly the same whether run on 32-bit or 64-bit Windows. A very few applications, typically server apps, are written to be "large address space aware". This means that instead of the 4 GB of possible 32-bit addresses being split into 2 GB for the application and 2 GB for the OS, the split is 3 GB for the application and 1 GB for the OS - but this only used to work if you booted your 32-bit Windows OS with a special option! Nowadays, if you run one of these apps on 64-bit Windows, then it gets a full 4 GB for the application. However, CMBN isn't one of those apps.

Link to comment
Share on other sites

I've been getting this too.

The only way I found to solve it for now is to delete some saved games. That seems to work. Don't know how or why.

All that I know is the problem started when I attempted to save a game during "Bloody Dawn". I had already saved 24 times and was on my 25th attempt (+1 from a prior scenario) when I received the out of virtual memory report. I restarted the game and attempted to restart the saved game from the 25th save file but it did not work. I tried to restart the same 25th save file twice. I noticed the last saved file (25th file) was half as large as the the rest of the saved files from the same scenario. So I assumed it did not save properly. I then erased that last saved file. I restarted the game and restarted the 24th save file and all worked fine...for a while. I would momentarily get another out of virtual memory report after another 10 save games or so...there about. I would then erase the 5 save game files from the top of the save list. It would work after that. I had run that same evolution once more, until I beat the scenario.

I normally try to save after every turn. I might forget once in a while, but I usually get most turns saved.

I have started at the top of the scenario list and gone down starting with "A Delaying Action" and skipping "Barkmann's Corner". I did not play the tutorial. I have only experienced this with "Bloody Dawn" so far. I plan on starting "Bois de Baugin" soon.

HP Pavilion Laptop dv6

AMD Phenom II N620 Dual-Core 2.8GHz

Win 7 64 bit

4 GB Ram

Hope this helps.

Link to comment
Share on other sites

Thanks for the explanation pondscum. I think I halfway understand. Little over my head. The virtual memory is hard disk space though right? I think till last night I only had a total of about 3 gigs free on the start up drive and it was I'm sure fragmented. Would that compound the issue? Say if it needed to write to 100 contiguous block but I only had 50 contiguous free. Anyway I have almost 7 gig free now and I'm gonna remove CMSF from start up drive and put it on my secondary drive. I think that will give me about 10 gig free.

Link to comment
Share on other sites

The virtual address space of a process is just that - virtual, i.e., imaginary :) The key concept here is that every process on a computer, every single program you're running, has it's *own* virtual address space. They each think that they have 2 GB to play with, even if you have 50 programs running on a little 1 GB computer. It's all a big illusion, and the master illusionist is the operating system, who gets to parcel out little pieces of its RAM to each program as and when it needs them. To keep this illusion going, it needs disk space, so that the *rest* of every program (the bit not actually in RAM at any particular instant in time) can always be fetched from disk.

Note that you don't actually need 2 GB of disk space for every process, because (a) only a few of them ever get close to using that 2 GB of virtual address space, and (B) you only need room on disk to store their heap data - all the code is already on disk, and the operating system knows where to go to find it.

Disk fragmentation will never *stop* of this from happening, although it can potentially slow it down just because it takes longer to read fragmented files. So a defragmented disk is always at least marginally better than a fragmented one.

Likewise, having just 3 GB free shouldn't stop you from running CMBN. However, I'd be very twitchy if that were my system - you're running near the limit, your filesystem will be slowing down, and bad things are in your future. So making more free space is also always a good idea :)

Link to comment
Share on other sites

  • 7 years later...
On 5/24/2011 at 6:52 PM, PondScum said:

Warning - geek stuff ahead! I do this in my day job :)

 

Out of memory in this case means out of virtual address space, which as you say is 2 GB for a normal 32-bit process (the OS is mapped into the other 2 GB). Everything accessed in a particular run of the game, both code and data, needs to find somewhere to sit in that 2 GB. The operating system handles all of this for the programmer, who just says "link this DLL" or "allocate some heap space": the operating system then decides where to put those new objects in the 2 GB address space. Then the 2 GB of virtual addresses are mapped onto real physical addresses in RAM during execution - but these physical addresses change on the fly as bits of code and data are paged in and out of RAM to disk. Your code still has the illusion that "hey, I've got 2 GB of virtual addresses, no problem!" no matter whether it's running on a 1 GB, 2 GB, or 4 GB machine. This is why machines with low physical RAM can run large programs - just verrrrry slowwwwly, because they are constantly swapping code and data in and out of RAM.

 

An out of memory error means the program tried to load or create something new, and the operating system said "your 2 GB of virtual addresses is full, tough luck!", at which point most programs just roll over and die (it's VERY hard to reliably recover from out-of-memory errors). This isn't always because the 2 GB is actually full - it just means that it's gotten so fragmented that the only free space left is in very small bits, and your code is asking for a contiguous range of addresses that won't fit in any of the small bits left. Sadly there is no way to "defragment" your virtual address space. In my day job I work with code that bumps up against the 1.6-1.7 GB range - once we get to 1.8 GB, a crash is almost certain to occur.

 

Root causes can be just trying to load too much (very large scenarios), and/or a slow memory leak which gradually fills up the 2 GB with allocated objects that aren't being properly freed (this shows itself as a crash after some playing time). Obviously if you have a very large scenario AND a slow memory leak, then you'll crash sooner.

 

If you want to look at the virtual address space of a process, then the free VMMap tool from SysInternals (now bought out by Microsoft) is the #1 choice. You can get it from http://technet.microsoft.com/en-us/sysinternals/dd535533.

 

Here's a VMMap screenshot showing what CMBN's address space looks like just after launch: the important numbers are to the right of the top three bars. Note that it has "committed" (used) 239,856 KB out of that 2 GB, and of that 125,848 KB is in my working set (i.e. in RAM at this instant)

 

VMMap-Launch.png

 

Now I load a turn into CMBN, and look how the numbers have shot up. I'm up to 641,500 KB committed, and all of the growth is in heap space (the orange section of the bar), which makes sense since that's used to store game data

 

VMMap-Turn.png

 

My bet is that if you load a huge scenario, play for a while, and then take a VMMap snapshot, you'll see that the committed space is up above 1.5 GB. If you keep playing and it keeps steadily increasing, that's probably a leak. And it'll crash before you get to 2 GB.

I like Geek Stuff! :D
Any fix or "just" Geeking? :D

Link to comment
Share on other sites

I haven't run in to this issue in CM. But it was a big problem playing Silent Hunter 4 using the bigger conversion mods like Trigger Maru Overhaul. CTDs in many of the most memory-intensive situations, like returning to port (because of cities, port facilities, numerous ships, etc). To fix it I followed the procedure in the following link. I make no claims as to suitability for anyone's particular situation, but it does allow you to make 32-bit programs large address aware with a few clicks. The instructions are perhaps more simple than they first appear. Make a backup of your exe and give it a go.

http://www.subsowespac.org/the-patrol-zone/give-silent-hunter-4-a-memory-boost.shtml

Edit: I see this is a rather old thread, but may still help someone

Edited by landser
Link to comment
Share on other sites

No, no, no. Do not do this!

20 hours ago, landser said:

I make no claims as to suitability for anyone's particular situation, but it does allow you to make 32-bit programs large address aware with a few clicks.

The CM games are already large address aware so best case scenario you will waste your time only to find the flags are already there. Worst case you will mess up your .exe.

Either way you will waste your time.

Once more for emphasis - do not do this.

Link to comment
Share on other sites

  • 1 year later...

@IanL  Do you know (or can you find out) if CM:A is LAA please? 

I'm having terrible issues with 'Out of Memory' errors while testing the stuff I've been working on recently.....I passed one over to @MOS:96B2P to try and he ran into the same issue almost immeiately (within fifteen turns). 

I've put a hell of a lot of time into these CM:A projects and to find that they won't run reliably on my current Win10 rig (the specs of which could reasonably be described as 'ridiculous overkill' for any CM game) is a bit disappointing.  This was a problem on my Win7 machine too, but it seems to be much more frequent on the new one, which is significantly more powerful.

Not a problem with any of the other titles, just CM:A.....CM:SF1 might do it too (it did in Win7), but TBH I've not run anything from that title on this machine yet.

Edited by Sgt.Squarehead
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...