C# trick to launch runtime debugger

I have used this trick quite successfully many times to launch a debugger from a running application. It works really well for things that are hard to debug.  Things like DLLs that might be running under a different application, or display tasks that happen periodically and launching the application in the debugger might change the way the application runs and not cause the bug you are looking for.  It works by basically crashing the application with an exception which brings up the dialog to allow you to continue or debug.  You can have visual studio already loaded with the application and choose that instance of VS from the list.  It is a one liner that you add to your code.

So simple. In your C# code, simply add this line.

Debugger.Launch();

You can do this in any language, but I'm using c# at the moment so showing that. This is very handy.

Unity touch debugging

I mentioned this in an earlier post, but thought I would go into more detail. I think this is  a great solution for testing touch input with Unity.

http://docs.unity3d.com/ScriptReference/Input.GetTouch.html

I'm using Visual Studio Pro 2013 to do this and I don't see a way to do it with Mono.  The only other way I've found is to use an actual device and connect a debugger to the device. This way I've found allows me to simply run a Visual Studio project directly on my touch device/development environment and test my touch code.

The first thing is to Build the project using File/Build and Run

 



 Select Windows Store app and then click Build or Build and Run.

 

The default location is to use the winout directory in the current Unity project. This worked well for me so I just used the default.

 

 

This creates a .sln file in that winout directory with all the necessary Visual Studio project files. Simply double click on the .sln file to launch Visual Studio Pro 2013.

 

 

 

I tested the project and one really nice thing is that the .cs files associated with behaviors in my project are actually linked back to the same files in my Unity project. So after making changes, they are already in my Unity project and I don't have to copy them back.

 

 

 

One thing to note is that this is only for script debugging. If I want to make changes to my layout or the models I've laid out in my Scene I will have to close Visual Studio, return to Unity to make the changes, then rebuild the winout project to work on my scripts again.  It's a small thing and this is still a much easier way to debug touch input than anything I've had to do before.

 

 

 

Debugging

In the past year I've been given a couple of very tough bugs to find and fix. It doesn't surprise me because while I'm really good at designing and building large systems, I'm also really good a finding and fixing the tough bugs. So I thought I would talk a little about debugging and debuggers.

There was a time, when I left college, and wouldn't choose a IDE for a project unless it had a really good debugger. This was even after four years of doing most of my software on systems that didn't have proper debuggers. This includes a bunch of pc titles using Turbo Pascal, Turbo C, Turbo Prolog and then all of my school assignments on Ultrix (the DEC version of SysV). No one ever told me about dbx on unix so I always used printf to find my bugs no matter what platform I was on. So it does seem strange that I required a good debugger once they started to become more readily available. The question is, did I use them? Well, yes and no.
They tended to work really well for simple bugs in logic, but for the tough problems I rarely found them useful and tended to keep using printf and logging. Especially for some of the more complicated servers I created. Debuggers and remote debugging just seemed too complex and wouldn't deal with threading properly to help me find the bugs I was trying to find. Add to that 100 instances of twelve different games running on the same JavaVM and logging was the only option.

I couldn't even imagine using a debugger to find a race condition in a threaded piece of software (most of the bugs I get lately). The AIX 64 bit device driver port that I fixed at the beginning of the year was crashing the system every time it would fail. I couldn't even get a debugger to latch onto the process before the crash.

So what is the trick? For me there is nothing special about the task of debugging something very complicated. I just start putting in printlns where I think the error is and seeing what the data looks like when things start to go haywire. On the device driver it was quite painful, but I found a way to println into shared memory that stayed active after reboot and I could then read the log finding the last few hundred messages. It was my first task on my new job and I spent three months pouring over logs. Family would ask when I got home. How was work? What do you say after you spent the entire day watching a machine reboot, pouring through logs and not making any progress except making the logs bigger for the next reboot? I teach classes in programming and I tend to say that programming is not difficult, it is just tedious.

As tedious as that was I knew that very tiny steps would pay off and they finally did. There were layered problems, but through the print statements I was able to see that two processes made device requests and only one got a response. Once you see that sort of thing in a log it's pretty easy to find the code that is not being properly locked and fix it.

On another problem I did use a debugger (both on windows and unix/dbx) when I just wanted to see a string variable (sql statement) as it was dynamically built. I guess I could have used printfs, but the debugger was readily available and easy enough to create a break point.
Learning Second Life script and Flash for a class I'm currently teaching, it seems the only debugger is printf (trace() in Flash and LLOwnerSay() in Second Life) which suits me just fine.
I guess the real answer is just to be flexible and use the right tool for the right job and when multiple tools will work just use your gut.

Do you use debuggers of printf?