Memory Leak?

Thanks for this info. I hope that 1.2Gb vs. 700Mb miracle has really wandered off... meaning I am writing my patch in the same total-allocation sitution as the others would use it in...
 
Private_pAuLa
Your savegame is much weaker than the one I use for testing... You don't have entire map open and you don't have each tile improved (and having a road).

Here is my profiling of your savegame:
1. 1.09 with my patch: 494Mb
2. 1.09 w/o my patch: ~610Mb
3. 1.00 - won't load since savegame is version 101

I also tried to set 'low textures', but this didn't help. I didn't notice any texture to become worse, only earth texture from the main menu became worse. Neither it reduced any memory consumption.
 
Harkonenn, from reading many, many other posts I am starting to believe your theory about memory being allocated for game based on speed of cpu.

You say your system is P3(can't remember cpu speed) and your huge games (only) use around 650mb, where as mine is p4(3.4gz) and use around 1.2 GB. But we both have same physical Ram 512 MB (am I right?) My graphics are the basic Intel Pci Express the machine came with, so that shouldn't affect the huge Ram allocation decision.

To test , I will send my next huge lategame map (with v1.09) to you if that is ok.
 
i think i found something...

the ctd is only showing if VM is full.
the game is putting away unneeded information into swapfile so the RAM consumtion there is ok.
but this time the game is filling up swapfile with 30 - 40 MB chunks.
means: the game is still flooding the swap file untill it is full and then crashes when no more memory is to be allocated 'cause the swapfile limit is reached.

i din't test this theory, but going to do so soon...


btw:
hark you should not post your e-mail in plain text
better migth be someting like this:
headdenATkarelia.ru
 
Private_pAuLa
Sometimes I catch crashes with 2Gb swap file. Also there is 2Gb VRAM limit per process (originating with 32bit nature) which will lead to CTD in any case.

I know about e-mail, but this e-mail is spammed already to the hell (~50 junk mails a day), so I don't care publicly posting it :)
 
Ok, this time I need some profiling over number of systems.

Please check http://www.sampo.ru/~headden

There you will see two DLL files - python24.dll and PatchByHarkonnen.dll

Place both into your civ4 folder, overwriting original python24.dll

Python DLL was built from original most recent sources and I added a string to load my patch DLL there.

Then please start civ4 and load your most hugest savegame. When it loads, minimize the game (DON'T QUIT), and make back-up copy of two files:

c:\civ4_mem.log
c:\civ4_d3d.log

Please send those files over to me: headden@karelia.ru

Please tell me your CPU and OS (2K/XP) along with e-mail.

(make sure that files you attach correspond to game most-loaded state. they are updated every 5 seconds from secondary thread, so if you quit to main menu or even to desktop, memory load reported will be less than in-game state which I am most interested of)

I am especially interested in systems where it consumes around 1.2-1.5Gb. I bet those are P4/Athlon systems.

Thanks in advance!
 
Harkonnen said:
P.S: This version does not improve anything, it's just a profiler.
Hark -
Can you post a savegame in your website to use so we all use the same one? This may help to standardize the evaluation issues....

...besides, I have been unable to play a huge game and have no huge save....:blush: ;)
 
I'm the using last save game that loads without crashing (1937) and its a fairly large one. I just finished composing an email that contains the save, dxdiag report, and the two logs hark wanted.

But thats a great idea oldStatesman, here is one I'm using if anyone else would like. If there is a better one to test I'm all for it.

View attachment 105275
 
hi harkonnen,
just sent you an email with the requested info.
used melatonin's save.
sounds like a good idea to use it as a standard.
 
I have followed the thread with interest since start, much good reading, great thread.
I must report something that I never was expected.
Edited a huge map last night with the worldbuilder, scrolled all over the map, and then ctd :eek: And it was a clean map with only default units from the beginning of the game. I have suffered many times in the game play with the memory leak, but never in the worldbuilder before now (last patch). So it can also happen with a clean map as long as you can reveal it. The crash occurred in the same way as an ordinary cdt. Also needed to reboot my computer after the first crash, since it messed up the desktop. After second and third crash, I was able to launch the game. I finished my improvement after three attempt :crazyeye:

So, is it any connections of whats going on in the worldbuilder, and in the ordinary gameplay?
 
Dragon67
I think the issue you described is connected to 1.09 patch. I am not sure 100%, but Firaxis has changed something with it, so it CTD's more often. I also have spotted a small memory usage INCREASE. Probably it is not so small with systems where it consumes 1.2Gb normally, and thus may cause CTD even with clean map.
 
well, i tried...

harkonnen_01.gif
 
AsnoT
It looks like some other stuff is hooking in. Please send me "c:\hook.dat" - that's machine code of some D3D or CRT function my patch was unable to disassemble.

If you are running some adware removal tool like SpySweeper, it might be the case. As for SpySweeper, turning it off requires restart to make it really off.
 
maybe this helps:
harkonnen_02.gif


and here's the hook.dat
 

Attachments

Harkonnen said:
AsnoTIf you are running some adware removal tool like SpySweeper, it might be the case. As for SpySweeper, turning it off requires restart to make it really off.

look at the processes running:
 

Attachments

AsnoT (and all others having "... sz != UINT_MAX ..." problem.

I have updated PatchByHarkonnen.dll at my site.

If you have that problem again, please send c:\hook.dat over to headden@karelia.ru - it appears each time this error is fired.

Such issues come from different Windows versions. Usually these problems become resolved in at most 3-4 iterations.
 
with the new dll, the game just hangs on savegame load. no go, sorry.
 
Back
Top Bottom