Hey all,
I make a 2D physics puzzle game for iOS. The game is live on App Store and I keep receiving a lot of crash reports in xCode. I cannot reproduce this crash and my question is: what will be my next steps to fix this bug? My game utilizes a lot of 2d joints, I use 2019.1.11f1.
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?
One scene, a lot of spring joints and hinge joints, spring joints have non-infinite break forces and yes, many springs and hinges are 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.
Has there been progress on this issue ?
I’ve been encountering the same thing, and it’s very weird to me…
I have a simulation-type project where Joint2D can be created and destroyed at will by the agents so my guess is that a lot of them are created/destroyed. The issue usually occurs after 10 to 20 hours of runtine so it’s very hard to isolate what caused the error and to replicate it.
Not all users report that crash but it’s indeed concerning since the purpose of the game is to allow for long-running simulations.
Is there something I can do to help solve that issue? A bug repport I can make? Something like that?
Thanks a lot
I think it won’t be in progress unless we have a simple project to reproduce it easily and quickly.
It has still been happening in our project.
And the only thing I know is it happens after destroying the joints with limits at very random moment.
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.
It seemed to have resolved the issue, I did not manage to reproduce the error using the custom build!
It’s hard to 100% guarantee considering the nature of the crash/bug, but I think it’s reliable enough
Thanks a lot !
Would you know what kind of timeframe we can expect before the fix is available with an official release?
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.
I’m glad to see this problem will be resolved
I would appreciate if there is anyway to avoid the problem from old version or someone know the most possible reason caused the crash.
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.
isplay: