Crashes in PhysicsScene2D::UpdateJoints(float)

I've not seen any crash reports and there are no existing bug reports unfortunately in this area. That particular line is where it iterates joints that have a non-infinite break force/torque limit set. It iterates all those joints and gets the break force and torque before comparing it to what happened. The specific line above is getting the property "BreakForce" on the joint so the joint pointer must be corrupt and I've no idea how that can happen.

 

Nope, that function hasn't changed in a very long time but it's also so simple and the only thing that can be wrong is that the joint pointer is invalid so something indirect is causing that elsewhere.

Are you using multiple local physics scenes? Are you actually using joints with non-infinite break limits? Are joints destroyed explicitly?

 

I can see several editor crash reports for "PhysicsScene2D::UpdateJoints" on our Crash Analyzer but only on Windows:

- 2018.4.3f1 on 5th, 10th & 23rd July 2019
- 2019.1.1f1 on 4th July 2019
- 2018.3.3f1 20th April 2019
- 2018.3.7f1 12th March 2019

None are associated with a bug report unfortunately but instead are automatic editor crash reports.

The only thing I can think of to isolate the issue is to set-up a serious stress test doing exactly what you're doing. Being as you have better knowledge of the behaviour, it would be good if you could help there. It sounds like a bunch of joints (many?) breaking limits but also joints being explicitly destroyed and I can assume more joints being added?

If you do have anything that could be used to stress this and could send it to me then I'd be happy to help isolate the issue.

 

A crash in the same method doesn't mean it's the same thing although in this case it's likely and I've never seen a bug report for this.

If you can reproduce this in a simple project in a bug report then it can be looked at.

That method is where the joint-limits are processed so it sounds like (somehow) joints are removed but their list of joint-limits are not which is very strange. A quick look through the code doesn't show anything obvious and the unit test shows them being removed so something more complex is happening. Still, it has to be related to joint-limits not being removed.

 

So today I finally got a bug report on this issue (2 years after the first post here) which I believe is from you (was created this month). QA are trying to duplicate it and I've spent several hours going through to see what could possibly cause this. I've not seen anything conclusive but I have spotted something even though it's not clear how it might cause the issue.

I could certainly make a modification and produce you a custom build that would allow you to test to see if it resolves it. Obviously QA here will continue doing the same.

The bug report project is 2020.3.4f1 so it'd be a build based on the latest 2020.3. Note that the build version would NOT be supported and would not guarantee anything else being 100% functional but would be to test this issue only. Basically a bunch of words to say, don't use this in production, for testing only.

If you are willing to do that then I can produce a build. Please don't get your hopes up too high though because this is a total guess but certainly something that is wrong that should be fixed. Given how long this seems to have been going on and the fact that this is the first time I've had a bug report on it, I'd like to expedite possible fixes. If it doesn't fix it then we know and we can look at other stuff while QA try to isolate it.

Any build links would be sent privately, not to be distributed. I've set a build package running on our build farm.

 

I have responded to your bug report by providing you with a custom build for you to test. I would appreciate if you could acknowledge that you've received it.

Thanks.

 

Unfortunately there's no way to give you anything resembling an accurate answer. The fix is already in progress however it has to land in our mainline trunk first at which point all the backports can then go into their respective branches. Whenever the next release is for those branches is when you'll see it. It'll be at least a few weeks before it's in an actual release.

I'll post back here as each lands if that'll help.

 

I've just queued the fix PR against our trunk (2022.1) and backport PRs to 2021.2, 2021.1 and 2020.3 which will land sometime after trunk has landed.

 

Impossible to say without you actually saying which version.

 

The problem has been around for many years (it's in Unity 5) but nobody submitted a single bug report so we've been unable to resolve and verify a fix until now.

 

I'm not sure how I can explain how the engine code causes this or what good it would do you. You cannot "avoid" it.

We can look at seeing if it'd be allowed backported to 2019.4 but it's already going to be in three backports (which is exceptional) including a LTS.

 

I've just added a PR for 2019.4 but I cannot guarantee it'll be allowed.

I've also activated a public link so you can track the progress here: https://issuetracker.unity3d.com/issues/crash-in-fixedjoint2d-when-playing-in-player

Note that the 2019.4 PR might take a little while to show on the link above.

 

Just an update.

It has landed in

• 2022.1.0 a4
• 2021.2.0 b6
• 2021.1.17f1
  
• 2020.3.16 f1

It hasn't yet landed in:

• 2019.4

 

Final note, it has also now landed in 2019.4.30f1 so available there too when it's released.

That concludes the fixes. If you could confirm that you no longer see it, I'll pass that info along to QA to close the cases.

NOTE: It might still show as "in review" in the link but the fixes have landed. Only when the QA closes those cases will it show correctly.