Unity (the game engine) is just really ruining my week. This program is crashing in a way that the actual Unity process (standalone exe or the Editor) just crashes, hard C crashes inside Unity's closed source code. I'm reduced to turning objects on and off and seeing the minimal set of objects to cause a crash, but I still have no idea what [my] C# code was doing before [Unity's] C++ code crashed!
I wish I could get, like… a trace of every unmanaged to managed transition. Every C# entry point.
@mcc
It's frustrating that this is almost solvable with Mono (so... Editor).
Mono has a --trace=NAME_OR_GLOB option. You can pass options to mono through environment variables (so potentially even if Unity doesn't expose the functionality). unmanaged-to-managed transitions are totally a thing that we can see.
But unmanaged-to-managed wrappers have a name that the --trace=NAME_OR_GLOB option can't parse properly. It's probably not too hard to make it work. but... we never did.
@lambdageek Last month I was doing some stuff with the MS C# stack and it was actually very nice because the C and C# stacks were just interleaved and Visual Studio could show me both. (Though that wouldn't help in this particular situation because what's happening is my code appears to be doing some state change [probably creating a resource] which later causes other Unity code possibly on a different thread to crash [probably when it iterates over resources]… none of my code is in the stack…)
@mcc Arg. Yep. I lost a whole month to this on Void Bastards, with a bug that took several minutes to reproduce and didn't do so consistently.
I'm struggling to remember details, but it turned out to be a result of using two of their systems, one of which was a means of sending http requests that we used for playtesting metrics.
I spent most of the last five years developing exclusively on open source game engines, and while it's not NICE to have to step into someone else's code with a C debugger, it's certainly better than the alternative (… not even having the option to step into the code)
Like, the really killer problem is I've got all this code, but I don't know in what order it was invoked. You make your scene graph, and Unity just pingpongs all over calling its Starts and Updates and OnPreRenders and what order it does this in (i.e., which component it calls into when) appears to be entirely undefined. I believe right before the crash some piece of my code is loading an invalid texture, but I can't know WHICH code unless I add Debug.Logs to EVERY method in this giant codebase
@mcc Oh, I've seen much worse. Like the library that put one exception handler in its main loop, and reported everysingle error with the same message on the same line number...
@mcc suggestion: you could convert the twitter.com/mcclure111 links present in your archive into twitter.runhello.com links, as I tried to follow the link in the reply tweet and it tried to go to the Bad Place
(also, I wonder if I should archive my old tweets too or just let them rot!)
@beeoproblem@mcc That, or the Java way: Catch some exceptions (that you usually can't do anything about anyway), then rethrow them with a different message. Then catch and rethrow, catch and rethrow, until it comes out of the exception processor(*) with a 300-line backtrace. Then log all of that that with no state/context to show why it might have been thrown.
(*) You know what a food processor does to food? That.
Though the first option is fine by me since I feel checked exceptions are a misfeature. Not going to go into why since that's a bit longwinded. EDIT "throws Exception" is normally frowned on AFAIK my own opinion aside
@beeoproblem If you can sensibly do something about an exception at some point, then catch it and fix the problem and don't report it (or log a non-exception message).
If you can't fix the problem the exception represents, don't do anything, and let it bubble up to a higher level.
Agreed. That's part of why I strongly dislike checked exceptions. Nobody likes writing boilerplate and the path with the least boilerplate involves catching early and often instead of being more thoughtful.
@beeoproblem There's an argument in favour of catching and throwing a different exception across major layer boundaries: for example, between a protocol-independent internal service and the protocol-specific layer, where the exception from the protocol layer is turned into a specific response.
For example, "ThingNotFound" thrown by the service, rethrown as "NotFound" in an HTTP wrapper to return a 404. (Where, say, a SOAP wrapper would expect a different exception for the SOAP response).
There definitely is nuance in how exceptions are presented in different levels of code. I bias toward not wrapping exceptions unless there's a case where multiple different low level exceptions correspond to the same problem.
Like, in your example, if a service I provide internally uses multiple data sources for a query I might catch NotFoundFoo, NotFoundBar etc and wrap them in ThingNotFound so higher level code only needs to catch one exception for a thing not being found.
Java mostly notwithstanding the distinction between expected and unexpected problems is... problematic.
For example an exception thrown on a SQL query execution timeout should be checked. An exception thrown on bad query syntax on the other hand isn't so clear cut. The question of whether the failure is expected or not is only knowable by the caller, not the callee. However it's the callee that is expected to say whether the problem is expected.
@argv_minus_one@darkling Assuming the SQL library uses checked exceptions for bad query syntax (because it should): if the caller knows bad query syntax should never happen it's now forced to catch and rethrow the exception as an unchecked exception.
Alternatively it forces the checked exception to bubble up despite it representing a program bug which normally isn't supposed to be checked AFAIK.
My problem is it adds boilerplate out of proportion to the value it delivers IME.
@argv_minus_one@darkling sorry for the reply storm. I find checked exceptions quite frustrating because, fundamentally, I agree with you. But in practice I find it leads to code working around it resulting in either code that's buried in boilerplate or much harder to diagnose bugs due to catches in bad places.
I sometimes wonder if some form of static analysis tools could provide some kind of solution here. 🤔
Add comment