The stacktrace pane
To get the stacktrace pane click on "view, stacktrace".
The stacktrace pane refreshes itself automatically after each single-step (F5 action), and also if "inspect, refresh all panes and inspectors" is clicked.
The stacktrace pane will be grey if the stack being viewed belongs to a thread which is not single-stepping (that is to say a thread which has F7, F8 or F9 action). In that case, the stacktrace will be the last known state of the stack.
What the stacktrace shows
The stacktrace displays information about "return addresses" which are held on the stack at the current ESP or at higher values of ESP (that is to say deeper into the stack). It therefore displays the functions (procedures) which have been called by the application to reach the current point of execution.
GoBug recognises an address as a "return address" because immediately before that point in the code will be opcodes for a CALL. Take this code:-
401020: MOV EAX,EDX 401022: CALL CALCULATE_ASSETS 401027: MOV [ASSETS],EAX ;keep result of the call in memoryHere GoBug knows that 401027h is a return address because 5 bytes before that place there is a CALL instruction.
The stacktrace ignores anything on the stack at lower values of ESP (higher in the stack). This is because the information there relates only to past execution and is irrelevant to the current stacktrace.
Here is a typical stacktrace of a single-stepping thread in the debug loop:-
The columns display the following information:-
The stacktrace in multi-threaded applications
Each thread has its own stack, so in multi-threaded applications you can switch between the threads and view the stacktrace using the stacktrace threadbuttons.
In this stacktrace, there are three threads, one (698h) is single-stepping (shown by the red reel colour) in the debug loop (shown by the needle), and the others are running (shown bythe colour of their reels). The stacktrace currently showing is for thread handle 6CCh which is the main thread (shown by the asterisk). If you view the stacktrace of a thread which is running you get the stacktrace of the contents of the stack as last known to Windows. Since the stack of a running thread is changing all the time, this will most likely be the stacktrace during a recent call to a Windows API.
Using the stacktrace to debug
The stacktrace output is very interesting whilst single-stepping through your code, but its main purpose is to help you identify the offending area of code if your program is causing an exception.
Sometimes the cause of an exception is easy to find once you know the EIP (instruction place) where the exception is occurring. But often the exception happens in a procedure which is called from many different parts of your program. Without the stacktrace it is very difficult to work out which part of your program called the procedure. The stacktrace will show this. The exception dialog (which comes up when an exception occurs) contains a button to show the stacktrace.
Dumping the stacktrace
Ensure that the stacktrace is visible, and go to the menu item "file, dump". Click on stacktrace in the menu item. Alternatively, right click on the stacktrace and choose "dump the pane". Choose a file name for the dumped file (GoBug will suggest a name). Choose a path for the file to be written (GoBug will remember this for the next time you debug this particular exe). Choose the type of file to make (use ANSI unless you want to make a Unicode file because you are using non-Roman characters in your code symbols). The file which is created on this dump is plain text with carriage returns and line feeds but no tabs. It is usually best to view the dumped file with an editor set to a fixed width font (as opposed to a proportionally spaced font).
Printing the stacktrace
Ensure that the stacktrace is visible and go to the menu item "file, print". Click on stacktrace in the menu item. Alternatively right click on the pane and choose "print the pane". You can change the font used for printing by using the "settings, fonts, when printing" menu item.