I seem to excel at crashing (and quite often freezing) unity. I keep hoping that a new beta version will improve the situation, but 5.6b9 is crashing almost every time I run my game. Sometimes it crashes right when I start it, other times after 5 minutes, or 10 minutes. There seems to be no rhyme or reason to it. The same with the freezing. Freezing could happen if the code gets caught in a loop but if this was the case, the freeze should be repeatable. It’s not, it just happens at random times. The Unity error logs always contain errors that say:
"134217728 MB user address space [134213005 MB free].
Read from location c09246c0 caused an access violation.
"
I think this must be a generic message that is written regardless of the cause, because it’s the same every time. Only the hex value changes. In the Stack Trace of the error log, the only readable text is:
0x2cfcfd20: 73796850 78502e58 70615373 7061732e PhysX.PxsSap.sap
0x2cfcfd30: 61647055 6f576574 00006b72 00000000 UpdateWork…
It’s clear that there is something about my project that Unity dislikes, but it’s a really large project and I have no idea how to troubleshoot this. Does anyone have any thoughts?
Hey!
We’ve been hearing these reports in the wild for the past couple of betas, but we were unable to reproduce them locally. Furthermore, we suspect that there is a bug in our crash handling code which makes it crash processing the crash, therefore failing to launch our bug reporter (and it also makes us not receive any information about such crashes). I assume you’re facing one of those, right?
Since you seem to have a good way to reproduce those crashes (as you say they happen often), could you help us out and modify your registry to automatically collect crash dumps on any crashed process as outlined in this document?
Use DumpType value of “2”. As you collect a few dumps, zip them up, submit a bug report with them attached and post the bug number here. Hopefully with your help we can figure those issues out :).
Hi,
Thanks for reporting the issue!
Looks like a symptoms of memory corruption.
It would be very helpful to run Unity Editor x64 with -debugallocator cmdline option. This would help to receive a callstack for the crash which is closer to the actual failure point.
Thanks guys, I don’t have time to follow the above advice immediately, but I will definitely check into doing these things. I will say this: While my project is still crashing sometimes, it seems to be behaving a lot better after reverting to the previous version of the SteamVR plugin. I suppose it could be the case that the latest SteamVR plugin update isn’t working so well with the latest 5.6 beta, so if this is something you can test in-house, you might want to try it. I’m a little disappointed with Valve regarding this latest plugin update as it caused a few different compile issues relating to some method signatures changing. Bad Valve!
I still have the copy of my project (with the new plugin) on hand, so I could test it again, verify that it’s still crashing for me, and follow your suggestion. I’ll definitely try to help with this as I’m highly motivated to have 5.6 release be as stable as possible.
Hey, since I seem to have your ear, I wonder if I can change the subject a bit. I’ve stumbled across something that may or may not be a bug that I’d like to run by you. If it’s a bug, it seems like a bad one. If it’s not a bug, then I have some code to re-write!
I’m wondering if this is broken (From the Object.Instantiate docs:
“When you clone a GameObject or Component, all child objects and components will also be cloned with their properties set like those of the original object.”
Check out the following code:
Rotation childObjectRotation=childObject.GetComponent<Rotation>();
Debug.Log("childObjectRotation activateString=" + childObjectRotation.activateString);
Debug.Log("childObjectRotation testString=" + childObjectRotation.testString);
GameObject bullet = (GameObject)Instantiate(childObject, transform.position + transform.forward * (parentSize + .01f), Quaternion.identity);
Rotation bulletObjectRotation = bullet.GetComponent<Rotation>();
Debug.Log("bulletObjectRotation activateString=" + bulletObjectRotation.activateString);
Debug.Log("bulletObjectRotation testString=" + bulletObjectRotation.testString);
My output looks like this:
childObjectRotation activateString=When Scene Played
childObjectRotation testString=goobers
bulletObjectRotation activateString=
bulletObjectRotation testString=goobers
So in the example above the “testString” of the cloned object matches the value set in the original object (childObject).
But the “activateString” in the cloned object is empty.
Shouldn’t the values for both variables be getting copied by the Instantiate call?
The difference between these two variables is that activateString is a property overridden from an abstract parent class. “testString” is a variable (I’m setting the value to “goobers” in my example) existing in the Rotation.cs class.
public override string activateString { get; set; }
public string testString = "";
Let me know if you have any helpful information about this. If not, then perhaps I’ll find a more appropriate thread to ask this question on. Thanks!
I’m such a dumb ass. For some reason I thought I was just seeing this issue tonight for the first time, but then it occurred to me that just last week, I not only encountered this issue, but wrote code to work around it.
Still I wonder: Should I have needed to write this?
The method I wrote is somewhat hardcoded for my needs, but you can get the idea about what I’m doing.
The script basically copies the script parameters form the original object to the clone object. “IPlayable” is the abstract class I mentioned in the previous post.
public static void copyScriptVariables(GameObject originalObject, GameObject cloneObject) {
//For each Iplayable, copy the properties from the original object to the cloned object.
List<GameObject> originalObjects= LogsUtil.GetChildrenByTag(originalObject, "log");
List<GameObject> clonedObjects = LogsUtil.GetChildrenByTag(originalObject, "log");
IPlayable[] originalIPlayables = originalObject.GetComponentsInChildren<IPlayable>();
IPlayable[] cloneIPlayables = cloneObject.GetComponentsInChildren<IPlayable>();
for (int i = 0; i < cloneIPlayables.Length; i++) {
IPlayable ip = cloneIPlayables[i];
IPlayable oip = originalIPlayables[i];
string[] saveParams = ip.getSaveParams().Split(',');
for (int j = 0; j < saveParams.Length; j++) {
string thisPropertyName = saveParams[j];
PropertyInfo pinfo = ip.GetPropertyInfo(thisPropertyName);
if (pinfo.PropertyType == typeof(string)) {
ip.SetPropertyValue(thisPropertyName, (string)oip.GetPropertyValue(thisPropertyName));
} else {
ip.SetPropertyValue(thisPropertyName, (int)oip.GetPropertyValue(thisPropertyName));
}
}
}
//Then call startMe because sometimes important stuff happens here.
IPlayable[] cloneIPlayabless = cloneObject.GetComponentsInChildren<IPlayable>();
for (int i = 0; i < cloneIPlayabless.Length; i++) {
IPlayable ip = cloneIPlayabless[i];
ip.StartMe();
}
}
I just re-tested my code after making a call to this method, and both variables are printing correctly in the cone copy. If it turns out that Unity Instantiate doesn’t include code to copy these kinds of properties, then maybe you should add it! When an object is cloned, it really ought to match the original as much as possible. Right? I’m curious to hear your thoughts on the subject. Thanks.
This is a limitation of Unity serialization system - no support for abstract classes. (See more details in Serialization in Unity blogpost).
Instantiate internally uses the serialization to clone a UnityEngine.Object, thus you don’t see abstract members in the copy.
I see, thanks. At least I found a way to work around this.
Hi, so going back to the original subject, when I ran using -debugallocator, this caused the game to crash every time within seconds. I’m not sure how valuable these crash reports would be given that the debug thingy seemed to be the cause of the crash. I’ve opened Case 886751 and added several (maybe 8 or 9) crash reports that I’ve had in the last day. Tautvydas-Zilys suggested I edit my registry to “collect crash dumps”. Would this provide any benefit over me just collecting the dumps that Unity is creating? I’m more than happy to do whatever else I can to help you troubleshoot these issues, but I don’t want to mess with my registry unless I really need to. Please let me know, thanks. FYI - Currently my game is crashing once every 30-60 minutes. Not great, but at least I can work, unlike the crashes every 2 minutes I had been seeing.
Actually, that’s exactly the point of the debug allocator - it causes Unity to crash as soon as something goes wrong, rather than 10 minutes later when the traces of the thing that went wrong are already cold. Crash dumps are super useful - the reason I asked to make that registry key is that some people reported that unity was not creating dumps - we were worried that our dump creation code sometimes fails and were hoping this would make sure the dump was created. Please send us the dumps you have :).
ok, well I turned it back on and collected a few dumps. My project is crashing Unity within a few seconds. I’m of course highly motivated to help you troubleshoot these kinds of crashes, so let me know if there’s anything else I can do to help!
Case 886900
Thanks, we’re looking at the dumps now.
Did those dumps turn out to be helpful?
Yes! I asked physics devs to comment - it seems that you’re hitting a bug which was super hard for us to reproduce historically.
FYI - I found what seems to be a repeatable bug. When I change PhysicManager Default Solver Velocity from 1 to 10, Unity freezes every time without opening the bug window. I took a dump using the Task Manager attacked to Case 888871
Also opened Case 888908 because I’m now seeing freezes even when I’m not adjusting the PhysicsManager settings. Once again, I attached a dump for this freeze. thanks.
Hi, I’m guessing that the Physics devs are still looking at this, and that 5.6b11 does not contain any fixes. Is this correct? I ask because I’ve had an especially bad day of both crashes and freezes, so decided to try 5.6b11. It seems that 5.6b11 is crashing just as often.
Yeah, it’s still under investigation.
Also running on the same issue as OP :
0x005fd9d0: 73796850 78502e58 70615373 7061732e PhysX.PxsSap.sap
0x005fd9e0: 61647055 6f576574 00006b72 00000000 UpdateWork…
Is there a link to the issue tracker with this issue ?
Running on 5.2.2p2.