Hi,
Unfortunately still a lot of crashes even at lowest resolution and texture quality:
https://pastebin.com/keH8rjvm
https://pastebin.com/HbqL2zbL
https://pastebin.com/aDm6xdLn
https://pastebin.com/qFy2tRD6
Viewing post in Windows XP Compatibility
For optimal performance, you will need to have roughly 1.4GB of free space in the user address space before starting the game. Is that the case for your system?
As the crash always seems to occur once your user address space gets close to the 2GB mark (note, the game alone won't hit that mark, it is the sum of active programs running under your user space) we wonder why your OS does not make any use of the pagefile. Can you think of any reason why the pagefile stays empty?
We tried our best to reproduce the crashes you have but even with the highest textures and AA options at FullHD, the 32 bit version works without any issues here.
Hi,
I thought so, as it usually happens with mem usage around 1,7-1,8GB. So I guess you forgot to check return value of some malloc()-Alike functions (VirtualAlloc, HeapAlloc, ..), and so...
;-)
As for the Win7 system, I only booted it an started up the game, so no other applications taking up memory. Pagefile is turned on, so OS should be able to do paging. I once accidentally started ROTT on Windows XP machine twice and there I was in paging hell...
I saw that your executable is large-address-aware:
dumpbin /headers RotT-Win32.exe
.... Application can handle large (>2GB) addresses
32 bit word machine
But I don't use the /PAE and /3GB switches in boot.ini (or its equivalent in Win7, if there is something like that), so could that be something to try? I think it was causing some troubles for me or my drivers and also it's not really recommended to be used, so that I didn't enable it. Without PAE and 3GB switch, 2GB per-process limit is still kicking in, even if executable is LAAW. Still wondering what is sucking up so much memory, though... Paging won't help if 2GB barrier gets hit somehow.
To reproduce the error, maybe you can try to use https://github.com/lowleveldesign/process-governor and enforce a tighter memory limit on the process on your machine?
We don't get a mem usage of 1.7-1.8GB. Our game usually is somewhat between 1GB-1.2GB or 1.2-1.4GB (later on with more characters in the game).
The video is great, but as we use the Unity Engine (C#/mono), we don't do any malloc(). So it's not really our fault, though if we find a repro-case, we'd happily report this to the Unity devs or see if we can find a workaround.
It is a mystery why the OS does not start paging but crashes the software instead if one of those processes gets close to the 2GB mark. Of course, paging won't help if the app needs more than 2GB, but your crashes seem to occur once your user address space exceeds 2GB - which is not the same. All your background apps/services run under your user address space, not just our game.
Definately try the /3GB switch. Though we didn't see our game using more than 1.4GB of RAM. Is there a scenario where the game uses more than 2GB user address space?
We tried to reproduce the error with the process governor but the first part of the game works flawlessly (max Textures, 2xAA, FullHD). When do your crashes occur and what are your settings?
The crashes always occur in BatchDeleteObjects call and always at the same location:
55BC8C8A | je unityplayer.55BC8CE0 |
55BC8C8C | lea ecx,dword ptr ds:[eax+eax*2] |
55BC8C8F | mov eax,dword ptr ds:[esi+11C] |
55BC8C95 | lea edx,dword ptr ds:[eax+ecx*2] |
55BC8C98 | mov eax,dword ptr ds:[esi+10C] |
55BC8C9E | movzx ecx,word ptr ds:[eax+edi*2] |
55BC8CA2 | movzx eax,word ptr ds:[edx] |
55BC8CA5 | shl eax,10 |
55BC8CA8 | or ecx,eax |
55BC8CAA | mov eax,dword ptr ss:[ebp-10] | <-- EAX is NULL here
55BC8CAD | mov dword ptr ds:[eax],ecx | <-- Bret Hart is right!
https://forum.unity.com/threads/batchdeleteobjects-crash-unity-5.321080/
Someone suggested to run a manual cleanup routine. Maybe you could try that?
I tried patching it to check for a null pointer and bail out, but then next times it comes with a pointer of 0x1000000, because it probably didn't clean up properly, so this is also pointless.
On my machine, it's enough to turn on highest resolution and Ultra HD Texture quality to immediately trigger it (by i.e. loading my last saved game now or opening a new game and leaving Bernards room). This always crashes it. If you want, I can give you TeamViewer access or remote debugging session to my test machine.
The bug report does not really fit into this scenario, as it is clearly linked to mobile, has been fixed and occured in a very old version of Unity which we are not using. Also, we can't try out the workarounds from the thread because they don't apply to our setup.
We suggest on your Win7 machine you should try the 4GB-Tuning (BCDEDIT /Set IncreaseUserVa 3072) or PAE (BCDEdit /set PAE ForceEnable). We cannot help with the crashes on XP, though.
Also, we are preparing an update which allows you to reduce the scene cache size. That may help, too.
Just a little note. I found debug symbols for Unity3D and therefore was able to find out that it crashes in crnd::crn_unpacker::unpack_dxt5
Fortunately, this code seems to be available on the net:
https://github.com/toji/webgl-texture-utils/blob/master/crunch/crn_decomp.h
bool unpack_dxt5(uint8** pDst, uint32 dst_size_in_bytes, uint32 row_pitch_in_bytes, uint32 blocks_x, uint32 blocks_y, uint32 chunks_x, uint32 chunks_y);
So pDst is an array of pointers that gets filled by the unpacker, some of them being possibly NULL because allocation failed, as you suspected.
In line
uint8* CRND_RESTRICT pRow = pDst[f];
there needs to be a check:
if (!pRow) return false;
to fix the crash. I can add it in assembly code, maybe the game then will at least shut down properly.
I now tried it with 3GB usermode address space, and now was able to play it through. Wow, what a great game, thank you! :-)
It took approx 2.3GB of memory during playing, so we definitely hit the 2GB barrier. Nevertheless fixing missing null-pointer checks couldn't hurt, maybe file a bug report to Unity developers, now that the issue is nailed down to a function.