Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+Debug tool uses standard oracle //DBMS_DEBUG// package to control debug sessions. When debugging you have two sessions:
+  * **Debug session** – main session from which you're controlling all debug operations, checking status, reading and setting values for variables etc.
+  * **Target session** – separate session running the code being debugged. This session will usually be executed with a lot of suspensions in order to allow operator to step through statements manually, check and set variable values etc.
+For more details on how this works refer to official Oracle documentation:
+[[http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10577/d_debug.htm#ARPLS009]]
+===== Classes =====
+  * **toDebugTool** (//todebug.cpp//) – class for debug TOra tool. This class checks that only one instance of toDebug is created for one session, creates and destroys all debug objects.
+  * **toDebug** (//todebug.h/cpp//) – main class for debugger.
+  * **toDebugWatch** (//todebug.h/cpp//) – class handling debug watches.
+  * **toDebugOutput** (//todebug.cpp//) – class controlling //dbms_output// of debug session.
+**Note:** these classes are used for debugging part. There are other classes used in Debug Tool to display code being debugged, set breakpoints etc. Some code is used together with Code Editor tool.
+===== Running debugger =====
+{{:knowhow:debugger_process3.png|}}
+When starting (opening) Debug Tool //toDebug::startTarget// creates a new thread //toThread * TargetThread//. All functionality of this thread is in one method - //toDebug::targetTask::run//. Upon startup it creates a new oracle session (target session). All code being debugged is executed in this session. It then goes into a loop waiting for commands from main session (stopping while TargetSemaphore is down). Commands from main session will have to be sent as anonymous blocks which have to be executed (that would be calls of code being debugged).
+After getting a signal from target thread that it has started (after target thread raises ChildSemaphore) main thread attaches this target session to main debug session (using //dbms_debug.attach_session//). Main TOra session will be sending sql to be executed in target session and then listening for results from target session and reacting to them in UI (displaying line being executed, showing/changing values of variables etc.).
+When you choose to “execute”, //toDebug::execute// will check if there is a “runnable” procedure or function under cursor (if package is being debugged). Error message will be displayed if debug tool cannot identify which procedure/function should be debugged. It will then construct an anonymous block running selected procedure or function. This anonymous block (variable called "sql") will be passed on to target session which will execute it. As target session is in debug mode, execution of given anonymous block will stop on each "interesting" event (see //DBMS_DEBUG// description). It also means that from a C++ code perspective target thread will "hang" until debugging given anonymous block is finished.
+Main (debug) session will be periodically calling //DBMS_DEBUG// procedures //CONTINUE//, //GET_RUNTIME_INFO//, //PRINT_BACKTRACE// etc. to resume target (say step to next line in code), get information about code being debugged (f.e. which line in which package/procedure/function is being executed) and depict that in GUI.
+**NOTE:** target session is one and only one, and only one debug session has that target session attached. Trying to get target session information from any other oracle session will fail with "connection problem". Therefore TOra is using one particular //toQuery// instance (which is one physical oracle session) for target session and one particular //toQuery// instance for main debug session.