this ctd bug has got to stop!

[ratatosk]

I've posted it a couple of times before, now again!

[Mon Jan 05 19:44:54 1970] Netcode2:209.144.109.145 Opening 209.144.109.145...

[Mon Jan 05 19:44:54 1970] Netcode2:209.144.109.145 Opened

[Mon Jan 05 19:44:59 1970] Netcode2:209.144.109.145 Established

Date and time: 11/19/2010 20:59:47

Program compile time: Oct 14 2010 16:38:24

File version: 1, 32, 4, 255

GL Vendor: NVIDIA Corporation

Renderer: GeForce GTX 260/PCI/SSE2

C++ Exception: class std::runtime_error 'Out of memory' at address 758FB727

OS-Version: 6.0.6002 (Service Pack 2) 0x300-0x1

[758FB727] (KERNELBASE): : RaiseException

[00CB1B7F] (ww2): :

[00793759] (ww2): :

[00957F04] (ww2): :

[0095A7AB] (ww2): :

It is inconceivable to me that with 9GB of RAM on Win7/64 and 1892MB on the nvidia card, I could hit out of memory absent a severe memory leak in the game itself given that nothing else was running other than Chrome.

Latest drivers, yada yada.

pffft

[membrain]

I'm so irritated with this bug that everytime I send a report right when I spawn back in...(after logging in twice and suffering through the extra 45 second side delay penalty... not counting overpop delay)

[bronco69]

im getting 20+ CTD/CTHLs per day...

[leparc]

im getting 20+ CTD/CTHLs per day...

good.

Seriously...If they fixed this I would play more.

[AHWULF]

CTHL is a different problem.

> C++ Exception: class std::runtime_error 'Out of memory' at address 758FB727

is the cause of most of the CTD's on the PC version.

To expand on what Gophur said in his production note:

Short version is 32bit apps on Windows (any version) are limited to 2GB of virtual addresses, which translates into 1.7GB (more or less) of actual usable memory per process. When you hit the '2GB' limit (again at around 1.7GB) the OS tells the app 'sorry charlie no memory'. Right now the client uses a max of about 1.3GB of client data, and OpenGL further backs up all the textures in the application memory of around 400MB. Thus depending on what you do, what you are, what driver you have, etc. you may hit the limit a lot or just below.

As an aside the Mac version never gets these as OSX's limit is 4GB.

It's not a memory leak, it simply that the client with all the new features needs a little size reduction. Martini and I are pouring Slim Fast into the code with a goal of eliminating 150MB thus sparing you more colorful metaphors.

It's not one thing, we have to solve a number of separate problems without affecting your gameplay or making something else go all colorful. But it's quite doable it just takes time and care.

Right now the easiest solution is to turn on the 'Low Memory' option in preferences; at the expensive of occasional stutters you won't use enough memory to ever hit the limit.

Edited November 20, 2010 by AHWULF

[noparty]

I'm getting constant CTHL which I never had before....I posted at length about it elsewhere noting exactly what happens.

While this may not be the issue on this thread it would be nice to know what is being done about the CTHL issue.

[delems]

One draw back to the low memory option is the city search function stops working correctly.

[AHWULF]

One draw back to the low memory option is the city search function stops working correctly.

It's ticketed for a fix.

[mynick]

Once every 5 sorties.

[ratatosk]

Short version is 32bit apps on Windows (any version) are limited to 2GB of virtual addresses, which translates into 1.7GB (more or less) of actual usable memory per process. When you hit the '2GB' limit (again at around 1.7GB) the OS tells the app 'sorry charlie no memory'. Right now the client uses a max of about 1.3GB of client data, and OpenGL further backs up all the textures in the application memory of around 400MB. Thus depending on what you do, what you are, what driver you have, etc. you may hit the limit a lot or just below.

Yeah I understand all of that, what I don't understand is why PAE and/or /3GB is not used to get around it until the windoze version of the game can be made 64 bit? And it still feels like there is a problem with resources being tied up after they are no longer needed (i.e., a memory leak). I typically get the ctd when spawning into a new mission after playing for a while in another one which seems very odd to me.

Anyway, I hope that you guys get this untangled, it is extremely frustrating.

[AHWULF]

/3GB its not something an app can do by itself. However it apparently has other drawbacks that make it not a good idea.

Regarding PAE from MS: "Microsoft Windows implements PAE if booted with the appropriate option, but current 32-bit desktop editions enforce the physical address space within 4GB even in PAE mode. According to Geoff Chappell, Microsoft limits 32-bit versions of Windows to 4GB due to a licensing restriction, and Microsoft Technical Fellow Mark Russinovich says that some drivers were found to be unstable when encountering physical addresses above 4GB." Note also that 2GB are reserved for Windows which is why we are stuck with 2GB. The /3GB limit squeezes the OS into half the normal size, and not all drivers and systems work well that way either.

Basically the only sane approach is to slim the app down a bit. We try to load stuff early to keep it from stuttering later.

[martinv]

I'm so irritated with this bug that everytime I send a report right when I spawn back in...(after logging in twice and suffering through the extra 45 second side delay penalty... not counting overpop delay)

Thats exactly what I get too! glad it's not just me

[noons]

Right now the easiest solution is to turn on the 'Low Memory' option in preferences; at the expensive of occasional stutters you won't use enough memory to ever hit the limit.

Trying this as of last night and perhaps needs to be stickied somewhere if it aint already. I can handle the CTHL's I understand that but the CTD's are a different story.

[ratatosk]

Regarding PAE from MS: "... According to Geoff Chappell, Microsoft limits 32-bit versions of Windows to 4GB due to a licensing restriction....

hahaha. that's hilarious and explains a lot. Just for the record, the 32 bit server OS's don't run any worse with PAE than without and, as a practical matter, have to use PAE to run SQLServer with a database of any significant size/usage.

My assumption is that the desktop licensing was limited to prevent people from attempting to use them as servers and avoiding the CALs, etc. Typical scheming.

Anyway, thanks for digging this out.

[AHWULF]

hahaha. that's hilarious and explains a lot. Just for the record, the 32 bit server OS's don't run any worse with PAE than without and, as a practical matter, have to use PAE to run SQLServer with a database of any significant size/usage.

My assumption is that the desktop licensing was limited to prevent people from attempting to use them as servers and avoiding the CALs, etc. Typical scheming.

Anyway, thanks for digging this out.

MS for you. I can see how a server app would benefit. But put gaming video card drivers into the mix (which are unstable enough) and who knows what you get.

[GOPHUR]

It's ticketed for a fix.

The fix is remove the low memory option.

[jwilly]

It would seem that, while the low memory option remains in-game, players with plenty of system memory could avoid the CTDs and avoid stutters by loading the game into a ramdisk...a virtual solid-state drive...so that content switches occur at memory speeds.

A few players have done this over the years. What if it were actually designed into the client, along with a requirement for enough system memory to make it work?

It's been discussed elsewhere that the current client's total quantity of models is close to topped out in regard to available memory space...and just about everyone can think of a bunch of stuff they'd like to see added to the game. Maybe such a memory-usage approach, combined with more aggressive gameplay management to permit unloading of early-tier stuff so that later-tier stuff can take its place, could be a tactic for fitting more models into the client.

[jwilly]

A USB2 memory stick is a cheap alternative to an SSD, and trivially easy to use compared to a ramdrive.

NewEgg has 4GB USB2 sticks for $6.

They're limited-cycle-life, of course, but how many accesses to a given address would the game make in a given session using the Low Memory option?

[AHWULF]

Won't help. Stutters are client related, not disk related.

With the lower memory usage in the current version out of memory issues are way down so less need for the 2GB option (unless that's all you have).

[ratatosk]

Won't help. Stutters are client related, not disk related.

With the lower memory usage in the current version out of memory issues are way down so less need for the 2GB option (unless that's all you have).

I am sorry to say that you are imagineering. Even with a fairly badass rig that is set to use low memory option and with nvidia GA driver from 10/25, I wound up with:

[Fri Jan 02 01:55:21 1970] Netcode2:209.144.109.147 Opening 209.144.109.147...

[Fri Jan 02 01:55:21 1970] Netcode2:209.144.109.147 Opened

[Fri Jan 02 01:55:27 1970] Netcode2:209.144.109.147 Established

Date and time: 12/17/2010 0:07:32

Program compile time: Dec 14 2010 15:27:16

File version: 1, 32, 8, 255

GL Vendor: NVIDIA Corporation

Renderer: GeForce GTX 260/PCI/SSE2

Access violation: Illegal read by 008D1D32 at 00000000

OS-Version: 6.0.6002 (Service Pack 2) 0x300-0x1

[008D1D32] (ww2): :

I think it would be fair to say that until you simply eliminate 32 bit clients, this will be an issue. I am glad my living does not depend on that.

[dsix]

Your memory explanation is spot on with the exceptions of people running a 64bit client. For those useres there are in theory no upper memory limits with todays hardware in the operating system. The limit is in the x86 emulator (WOW64) that allows 32 bit applications to run in 64 bit operating system. This is what allows a 32 bit application to run in the 64 bit world. This does not however remove the physical 32 bit limitations imposed to windows applications. The application still only is able to use 2GB of memory. In addition the /3GB and /PAE are not supported (they are not needed) on a 64 bit operating system.

The MAC approach to memory is totally different that the Microsoft approach. While the Mac OS memory model, with all its inherent problems, remained this way right through to Mac OS 9, due to severe application compatibility constraints, the increasing availability of cheap RAM meant that by and large most users could upgrade their way out of a corner. The memory wasn't used efficiently, but it was abundant enough that the issue never became critical. This is perhaps ironic given that the purpose of the original design was to maximise the use of very limited amounts of memory. Mac OS X finally does away with the whole scheme, implementing a modern sparse virtual memory scheme. A subset of the older memory model APIs still exist for compatibility as part of Carbon, but map to the modern memory manager underneath.