Evgeny Shvarov · Jun 13, 2016 1m read

Debug: using locks for breakpoints

Hi, Community!

Want to share with you one debugging approach from the Russian forum.

Suppose I want to debug the application  and I want it to stop the execution on a particular line.

I add in code this line:

l +d,-d

When I want to start debugging in this line I block d in terminal

USER> l +d

And execute the app.

The app stops on this line and lets me connect to it with Studio debugger.

To release lock I do in terminal

USER> l -d

And what are your debugging practices?

1 520
Discussion (8)5
Log in or sign up to continue

I usually add a HANG command when I want to start debugging

Hang 15

And call the system or app which runs the specific class method, routine, csp, etc.

This hang gives me some time to go to studio and attach my studio debug to that process according to the name.

I use Serenji. I can start interactive application debugging direct from the Terminal prompt. For a CSP or Zen based web app I can launch my pages in the browser and immediately start stepping through code, or running to soft breakpoints (no changes needed in my source). I can attach to background processes. I can set conditional breaks (e.g. break when variable ABC is set to value 123) or delayed breaks (e.g. stop the tenth time I get to this point). And with the Ensemble edition I can replay sessions command-by-command in a uniquely powerful way.

Disclosure: I created this tool in 1998 and continue to maintain and support it, so you should probably look to others for a more objective opinion of its value. Or try it free for 30 days.

You can just use studio.  Add your class/csp/routine to project, set breakpoints and Debug Target, save project and start debugging by Debug->Go 

Yes. But what if Debug Target is not a Class method or Routine?

In that case you can use locks or hang as Fabio suggested to catch the line and the moment and attach to the process with Studio.

Daimor on github gave a very useful set of classes (I believe v2015 onwards) that allowed you to log anything and everything to a class

you can pass in event types such as NONE,FATAL,ERROR,WARN, INFO,STAT,DEBUG,RAW and then it will handle just about anything,  objects, strings, lists etc and then just do sql's for the actual messages

Small correction though: the referred github sources are fork, and have been created not by Dmitry Maslennikov (@daimor) but by Eduard Lebedyuk (@eduard93)