koobas.hobune.stream
Steps For Debugging Lockup Issue of Unknown Nature
Hi folks!
I'm in Month 32 of a solo project, and a lockup-inducing bug has been cropping up intermittently for about six months now. I thought I'd have found it by now, but the game is nearly complete and I'm no closer to identifying the cause.
The lockups aren't that difficult to duplicate, but I can't pin down precise conditions. I have discovered that they only occur after the game has been left paused for a while, OR after the application has switched out of focus for a while. But I can't always trigger the problem on purpose.
There's so much logic that might be responsible (even given these isolated criteria), I really cannot fathom how to approach finding the cause(s).
The first error reported is always that my "supervisor" singleton instance is nullified. Because so many classes call this expecting it to be non-null, knowing this doesn't tell me anything about why it's happening.
All subsequent errors seem related to this one, but in the same frame, it stops producing new errors and locks up, requiring me to terminate the process.
I'm very confident that there's no logic that should be capable of nullifying this instance, so I'm really at a loss for what's happening. I don't even know what to try first to find out. I'm also not sure it has anything to do with the root of the problem. In fact it seems more likely it's only a primary symptom.
Any advice? Really any at all might help. I'm unfamiliar with debugging "complete unknowns" in a complex project.
This is nearly impossible to answer as there are way too many unknown variables involved. You haven't given any useful information about your project.
Some questions:
Do you use thread and locking anywhere in your project?
That singleton you talk about, how does it look like? Do you use a property or just a public static variable?
What kind of class is that singleton? A MonoBehaviour derived class or a normal class?
Do you use recursive method calls or endless loops somewhere? Even a coroutine can lock up your application when you don't reach any yield inside an infinite loop. Infinite loops can be hidden (i.e. the loop itself looks fine but something else changes a shared variable which leads to the infinite loop).
What kind of "pause" do you talk about? Do you mean the Pause button inside the editor? Or do you mean your own pause mechanics in-game (i.e. Time.timeScale)? What's "for a while" in terms of seconds / minutes / hours?
In case you use threading and this problem is related to threaded code you're officially screwed if you didn't program everything thread-safe.
In the other cases it's not that hard to figure out why or where your singleton is lost / destroyed. First if you just use a public static variable you should replace it with a public static property and use a private backing field. This allows you to log every get and set call of your singleton. You also make the singleton read-only that way.
In case you already use a property and your object is a MonoBehaviour derived class, you might want to add an additional null-check inside the getter and execute Debug.Break() if it's null. This should pause the editor right after this frame.
If it still locks up it has to be directly related to the null-value of your singleton. -
Thanks for the extended write-up! Sorry for the poor communication. I'll look into this advice. $$anonymous$$uch obliged for the help,
Accepting, as this certainly qualifies as "steps for debugging". $$anonymous$$ight revisit the issue in a more refined question once I better grasp what's happening. Thanks again,
