Code execution viewer
This Fuse day session is a follow up on a post on the subject of using sequence diagram for visualizing executing code flow.
The benefits of such a tool are:
1. Compare code execution before and after code refactor.
2. Help with understanding execution of unfamiliar code.
3. Relate between code executed in seperate frames. anyone who debugged flex applications is familiar with this pain.
The ultimate goal is to end up with visualization for code execution similar to this (taken from enterprise architect):
In an attempt to create such a tool, we explored the following options:
Analyze flash debugger traces.
1. Analyze flash debugger traces
By modifying mm.cfg we get lots of info which includes lots of noise which is hard to filter.
We used the following flags:
TraceOutputBuffered = 1
AS3Trace = 1
In addition, the information is not clear enough with regards to the actual line of code executed.
2. Using fdb.exe
We got to this option by examining the source code of flashdevelop.
FlashDevelop is an open source c# application with a debugger executing fdb in a shell (JVM executes fdb.exe), then read and write to the standard input/output in order to communicate with it.
Integrating code execution view as a view in flashDevelop may be a good idea, however, at this stage we didn’t want to bother with delving into flashdevelop code.
The advantage of working with fdb is that it provides only relevant debugging information, and allow examine the call stack.
Communicating with fdb
We set up in two paths of communicating with fdb:
Air application interacting with fdb via stdin/out.
Use fdb as a library. Interaction is made by traditional java function calls and return values.
1. Air application
Starting with Air 2.0, we used this code sample as the basis of the application. Unfortunately, we came across the same compilation issues (compile errors in the NativeProcess etc.) like the author. Moving to Burito, with Air 2.5, solved the issue.
2. Use fdb as library
Taking the Java source of fdb.jar (Flex SDK 4.0) we’ve entered changes that will execute the needed logic – run a swf in debug mode, and gather the step-into results. This could be used combined with a Swing interface to initiate the debug session and display the flow.
The code attached runs the debugger, showing the flow in console. Command line accepts 2 parameters – the swf path/name and the name of the function we want to start showing the flow from.
using fdb for getting code execution data
In order to get the required data needed to visualize code execution, we used fdb “step” command, which returns data describing the current code line.
Allowing a single step is straight forward, and the challenge is offering a “Resume and record” mode, which should behave like flash builder's “Resume” command (F8 shortcut), with recording abilities.
The resume command should execute till it meets a breakpoint, or until the application becomes idle.
In order to achieve this, we forced fdb to continuously “step into” the code, visualizing the execution as it goes along.
The challenges we faced with the “Resume and record” mode are:
How to avoid stepping into Flex libraries (or allowing the user to decide whether he wants to)
How to identify that the application is idle. Continously calling “step” on fdb resulted with endless debugging.
Avoiding stepping into Flex libraries may not be possible, but we can at least not display them to the user by filtering them.
Identify that the application is idle turned out to be quite problematic, and eventually we used a specific string pattern (“Execution halted, FocusManager”) to identify that our debugged code block is finished. This is a hack which should be solved.
We ended up with an Air application which uses fdb to automatically launch a test app, set breakpoints on it, and record its code execution, visualizing it in a very basic, but clear sequence diagram.
The code is attached.