std:bad_alloc error

[Defyant]

Hey guys. I'm getting an error - std:bad_alloc - whenever I start up a game on a map such as Epic and OverCrudeWater32. Note: this happens no matter what mod I'm using, be it CA or THIS. No error log is produced either, the game just CTD's, and then 'FATAL ERROR: std:bad_alloc' pops up in a message box on my screen.
I am running Win7 64-bit, with an Intel i7 CPU (windoze says it has 8 cores, but I doubt that), a ATi Radeon Gigabyte 5870 with 6gb of RAM.

Does anyone have any idea what is causing this and how to fix this?

Also, I get a CTD with another map, TMA-0. An error log is produced, but there is no 'std:bad_alloc' message.

Thanks

[FLOZi]

Windows 7 shows 8 cores because i7s are hyperthreaded, essentially there are 2 logical cores for each of the 4 physical cores.

Anyway, you should probably make a report on mantis:

http://springrts.com/mantis/

Sorry I can't be of any more help.

[AF]

Epic and over crude water are huge maps, hence the name 'Epic'

The likely explanation is you simply ran out of memory trying to load the map, by which I mean both ram, and maxed out your page file.

[oksnoop2]

Yes you ran out of ram.

[Defyant]

So would there be a workaround? Or do I just have to live with that? :\

[enetheru]

buy more ram?

[SirArtturi]

Well, it refers to ram usage, but cmon' the guy has 6gb ram, shouldnt it be enough? Or maybe you are running some heavy programs background?

[BrainDamage]

http://msdn.microsoft.com/en-us/library ... ory_limits

spring is compiled in 32 bit mode and with IMAGE_FILE_LARGE_ADDRESS_AWARE off, therefore even if his OS is 64 bit, and he has 6 GB ram, spring can only use 2 GB

if IMAGE_FILE_LARGE_ADDRESS_AWARE would be enabled, it would allow 4 GB to be used even in 32 bit mode, but the only "real" fix would be a 64 bit build to use all ram available

[oksnoop2]

Is there 64 bit spring for windows yet?

[BrainDamage]

no, and doubt it'll be very easy because generally crosscompiling is usually a giant pain in the ass, not to mention, all other programs would have to be rebuilt too for 64 bit ( lobby, settings, etc ) otherwise they won't be able to access unitsync anymore

[oksnoop2]

There's a 64 bit build for linux right?

[BrainDamage]

yes, but that's native, not cross compiled, also compiling in linux is much easier than windows ( I don't want to start a flamewar about dev-friendliness, so please take my statement as personal opinion and strictly linked to spring )

also, the linux builds are not done by spring devs, each linux distro has it's own with it's own maintainer

[rein08]

You just have to have ram.
That's it.
Good day.




Spartoo voucher

[Drone]

i once had this

people told me i needed to update my graphics drivers

[BrainDamage]

if you had an ati card, some old drivers used to leak ( constantly and progressively waste more and more memory needlessy ), if that's the case it was a sound advice

[AF]

I still think its a good idea to take unitsync.dll and replace it with unitsync32.dll and unitsync64.dll on windows, with the existing unitsync.dll defaulting to 32bit. It would be of enormous help, especially with Java projects, AFLobby on a 64bit Java VM was a nightmare since it couldnt communicate directly with 32bit unitsync

[hoijui]

if you give us stable 64bit mingw cross compiling instructions...