Swing Debugging – Effective Techniques for Debugging Swing Applications

Deep under the hood, any functional language with heavy roots in lambda calculus is compiled to code, closely following some abstract computation model. For haskell it is STG-machine, for ocaml/caml-light it was CAM-machine. This execution model usually has something like local variables and clear route of execution and source code translates into code for abstract machine by clear, well-defined algorithm. So, breakpoints can be inserted in haskell (for example) code and something like local variables can be determined, when expression with breakpoint is evaluated.

For haskell and other lazy languages, however, the problem is that it does not make much good (except profiling). REPL allows coding expressions with easy, as no side-effects goes away from function body definition, so no real need to debug functions locally and asserts will locate error for sure. The real source of bugs usually is space leak due laziness in wrong place, and completely different tools, inspecting heap structure, are needed (and some are available).

After much debate, many lunches, posts on various forums, and head scratching, a colleague of mine came up with the following:

In Visual Studio, go to Debug->New Breakpoint->Function Breakpoint and enter the fully qualified name of the compiler generated method you wish to break on. For example Foo::Foo will break in Foo's compiler generated default constructor. We can add Foo::Foo(const Foo &) for its copy constructor, Foo::Foo(Foo &&) for its move constructor, etc. Note that you must also include any namespace. Also note that you can add function names that do not exist. Take note of the opaque red dot in the breakpoints window vs empty circle denoting a point that will not get hit.

After the debugger breaks, we can use the callstack window to identify what it broke on and choose to continue or not. If we wish to inspect then we can open the disassembly window and step (F10) to the point the constructor, copy constructor, assignment, etc is complete. We can look for the "ret" instruction to guide us. When it goes one up the call stack, even in the disassembly window, the name of the method is denoted. We can then switch to Locals and view "this" as normal.

This is, of course, specific to Visual Studio. Other debuggers might have something similar.