We’re having an access violation crash (e.g. “Write to location 3f5e7000 caused an access violation.”) regularly as of Unity 3.4 on Windows XP 32-bit systems. I don’t have the full error report on my now, but from the stack reported when crashing with a Development Build, it’s crashing following the Skinned Mesh SSE2 function on tr_flush_block.
The scene it’s crashing in is quite large (many thousands of objects). We’re still in the process of narrowing down exactly what elements of our project are affecting it as it doesn’t occur when we delete certain large elements from the scene. One of these large elements that when removed stops the crashes does not contain any skinned meshes, so it does not appear to be related to the number of skinned meshes in scene.
If we can’t narrow down the problem and either fix it or compile a bare-bones project for reproducing the issue to send with a bug report, the best option in the sort term may be to disable SSE.
Is there a way built into Unity 3.4 to disable SSE (e.g. command line arg or linker option we can add to the built exe) or does anyone know a way to globally disable SSE in Windows XP? Some BIOSs have the option to disable it, but it appears many (including the ones we need) do not.
You can not disable SSE2 no. the only way to get through without SSE2 is going back to Unity 3.3
But on CPUs that don’t support it (the only case it should fail) it isn’t used, though such cpus don’t exist as the hardware support for them was dropped with Unity 3 already (the old DX6-7 dinosaur support)
I would actually see if the platform drivers for your board and cpu offer an update, sounds like something on that end fails. Or actually the bios not fully supporting the cpu sticked in
It’s been tested on more than 15 Windows XP machines and half a dozen machines with Windows XP running in VMWare and can be reproduced 100%. Different hardware and latest drivers, etc.
I’ll probably end up going into work tomorrow (on a public holiday, sigh) and debugging it more to try and narrow down the factors that trigger it. Rolling back to 3.3 will be a very disappointing solution so hopefully it can be resolved one way or another. Obviously sending a full bug report through to Unity is in order, but our project is over 10GB so it would be best to wait until we can reproduce it with less.
And it fails on all?
Just with using normal animation etc, not some code that messes into the animation states and alike?
Also cpus aren’t overclocked or running otherwise “out of sync”?
Windows is on XP SP2 or better SP3? (Microsoft fixed a few problems)
Also ensure to have security software removed, there are different ones that hook that heavy into the thread activity that they messup this kind of stuff.
That VMWare might fail is possible, unity does not support any virtualization solution of any kind and that for good reasons, would consider it possible that it messes the state and leads to mangled accesses to the SSE2 driven streams
And yupp try to replicate it with something simpler, perhaps you will in the end identify an issue with something inside the project where a “trick is pulled of” that on prior unity versions worked and now under the recent bug fixes no longer works for example.
I personally have nearly none of the reported probs of 3.4+ windows that spread over the board here, I still think its similar to 2.6 and 3.0 - overly agressive antivirus guards that messup the state completely … Avast, Antivir, AVG, ESET NOD32 in default - since I went to Kaspersky I got rid of all of these problems basically
Our dev machines are Windows 7 64-bit and don’t have the problem. Have not yet tried putting a Unity editor on one of the Windows XP machines so I don’t know if that will have the same problem as the built exes we’re testing with.
It fails on all machines tested. It’s not always at the same time and can happen within 20 seconds or after 10 minutes. Generally it’s within the first 2 minutes. The non-VMWare Windows XP machines are using SP3 and the VMWare machines are have SP2. CPUs aren’t overclocked.
I’m fairly certain there is no security/antivirus software in play, but that’s something to check too. It’s probably unlikely to be external software causing the issue as there are a few very different (both hardware and software) machine configurations we’ve tested on.
We do have code that modifies the animation states, but an element we can remove from the scene to stop the crashing from occurring (or atleast stop it within it from occurring for 30 mins+) contains no skinned mesh renderers. Time or normalized time is being set on animation states on objects in it, but the animation of those objects is sub-mesh driven, no skinning.
I’m wondering if perhaps the new skinned mesh threading results are being copied back into the main thread at a time that could conflict with other operations. Maybe Windows XP handles this differently than later Windows versions?
Another thought is that because we do have a fairly large number of skinned meshes in the scene, some of which with a fairly high vert count, perhaps there is a lot of data being passed around for SSE2 instructions and it’s causing a stack overflow.
I’ve too had no editor crashes in 3.4 on my Windows 7 machine. I do have issues with very large animations importing far slower than in previous versions presumably to do with the bounding volume calculation.
submesh driven means with the animation editor and animation curve?
Hmm then I would see if you can replicate it with multiple dummy animations especially such operating on the same bones / transform … I’m unsure on the state on that end as I stopped touching it at all due to the limitations, I use iTween instead for my nerves sake
I edited my post as you guys were replying and added:
The animations are from Max and are driving child bones/mesh transforms, they aren’t created in the animation editor. This is something we utilise quite a lot as skinning performance prior to 3.4 was so poor and it’s obviously the best option for rigid objects that don’t require > 1 bone. I will investigate if perhaps this is involved in the problem, perhaps Unity are running the SSE2 instructions based on enabled animations rather than updating skinned meshes, but that would seem strange.
There’s no shader related issue as far as I know hippocoder. I’ve replicated the crash running at lowest quality at a low resolution, but I have not stripped all our shaders. I don’t think that’s related. I don’t think VMWare is causing any addition problem we aren’t seeing without it. Errors are the same either way.
I appreciate your help and thoughts on this problem. Please keep posting with any more questions and ideas and we might stumble on the answer :).
Does it still occur if you set the cpu affinity for unity to just the single core? it may well be a genuine unity bug, and I think they’d appreciate the heads up here to fix it.
well it doesn’t crash on me but the output is pretty hectic - are you sure you don’t have error on your end?
EDIT: same if i explicitely disable sse in source code. So should be error somewhere at your code
My particular issue has been resolved, it came down to the boneWeights having boneindex’s higher than the actual bones of the SkinnedMeshRenderer. Could a value check/ error message on incorrect boneindex’s be put in there to prevent crashing?
(0x00A02950) (Unity): (filename not available): SkinSSE2_2Bones_Pos_AABB
(0x0051881D) c:\buildagent\work\842f9557127e852\runtime\filters\mesh\meshskinning.cpp (1153): SkinMeshSSE2
========== END OF STACKTRACE ===========
Can anyone confirm if this can safely assumed to indicate boneindex issues in the boneweights? We have a hell of a lot of assets this could be related to, and I’d really like to be sure of what I’m looking for in all of this.