I keep having VS2019 hanging whilst debugging and the SITcore program also freezes. I have to hold down APP button and reset the board to get it back again.
At first, I thought this was because the source was located in a OneDrive folder but even when I move it out of there, it still freezes.
What I think I found is that I had made Program app as a global variable and the same with DisplayController. Moving these to local in Main() fixed the issue and I can now debug and run as normal.
I hit something similar regularly and have debugged into it on the PC side. I can repro hard hangs by placing breakpoints on delegates that get fired from firmware, and certain other operations (mostly single stepping). One of the hang scenarios is rooted in how the debugger walks the call stack, but another seems rooted in the firmware and I don’t have the ability to debug into that. Both issues may require firmware changes.
If you are not single-stepping or using breakpoints, then your failure scenario may be different than mine, but then again, if you are not single-stepping or using breakpoints (i.e., just watching the debug output) you can do that from the TinyCLR app and should not hit the hangs if they’re the same ones that I am seeing.
The nasty thing about it is that it is not a deterministic failure, but when it happens, what I see is a stack overflow in the debugger code that exits the debugger (VS goes back to edit mode, or exits entirely), but which leaves the interpreter in a stopped state, waiting for the debugger and the only recovery is to reboot the board.
Rearranging your code and avoiding breakpoints in callbacks may reduce the frequency of the hangs, but it’s mostly guesswork and good luck. This is going to take someone with a repro, SDK source, and the ability to do firmware debugging (i.e., GHI).
I finally tracked it down to a null string being applied to a TextBox.Text element. I had forgotten to initialise the string before I used it. Once I sorted this out, it has been very stable.
It should handle and return an exception. I have posted this on GITHUB.
Fwiw, I seem to write plenty of shit code, and on a handful of occasions when an unhandled exception is thrown, I will get into the situation where a reset/reboot doesn’t bring the device back to usability.
Now this in and of itself may not seem surprising if programming was reexecuting the exception on every restart, but that isn’t the case. Even when the exception needs to be otherwise triggered, this proves to me something is perpetually locked up after the exception.
And then only using LDR to first fully erase the device and then reapply the fw will allow me to get on with finding the exception before getting locked up again.
I’ve started wrapping my entire main methods in a try catch to see if it tends to help.
A thrown exception means you can fix your code to handle the problem but the issue with the one I found is that there is no exception thrown, it simply hangs your code and the debug connection.
I’ll have a go at creating a simple prog that demonstrates the issue and GHI can look at a fix in the UI library for it.
An exception thrown by your code with a debugger connected first has to be reported to the debugger as a first-chance exception (even if you are not breaking on first-chance exceptions) before your code will see it. So, if there is an bug in the debugger’s code (an exception, or the stack overflow that I see) while walking the stack trace, then you won’t see a first or second chance exception in your code - it will just hang.
So you are right that under normal circumstances, your code will get notified of an exception, but if the debugger is broken, then neither your code nor the debugger will report that exception.
Other manifestations that I have seen:
Stack overflow on breakpoints in code called from firmware (delegate code)
Breakpoints that get skipped
F10 single-step that hangs or runs free like an F5 instead of stopping on the next line
F11 step-into that hangs or runs free instead of stopping on the first line of the callee
Lots of these seem to boil down to stack walking errors or code offset calculation failures because of some of the new CIL structures that were added by the Roslyn compiler.
I stated that in my experience having an UNHANDLED exception, but what l should have added as @mcalsyn reports is they all seem to manifest as UNREPORTED exceptions, and the subsequent hangup.
It seems to me, and even in @Dave_McLaughlin case, the root trigger (not root cause) is indeed an exception regardless. But what do I know.
