Command-line debugger

The fdb command-line debugger is located in the flex_install_dir/bin directory. To start fdb, open a command prompt, change to that directory, and enter fdb.

For a description of available commands, use the following command:

(fdb) help

For an overview of the fdb debugger, use the following command:

(fdb) tutorial

To debug a Flex application, you first generate a debug SWF file. Debug SWF files are similar to other application SWF files except that they contain debugging-specific information that the debugger and the debugger version of Flash Player use during debugging sessions. Debug SWF files are larger than non-debug SWF files, so generate them only when you are going to debug with them.

To generate the debug SWF file using the mxmlc command-line compiler, you set the debug option to true, either on the command line or in the flex-config.xml file. The following example sets the debug option to true on the command line:

mxmlc -debug=true myApp.mxml

Flash Builder generates debug SWF files by default in the project’s /bin-debug directory. To generate a non-debug SWF file in Flash Builder, you use the Export Release Build feature. This generates a non-debug SWF file in the project’s /bin-release directory. You can also manually set the debug compiler option to false in the Additional Compiler Arguments field of the project’s properties.

For more information, see Invoking the debugger compiler.

You can use fdb in any gdb-compatible debugging environment. For example, you can use M‑x gdb inside Emacs and specify fdb.exe as the gdb command.

The command-line debugger supports debugging only at the ActionScript level and does not support the Flash timeline concept. The debugger also does not support adding breakpoints inside script snippets in MXML tags. You can set breakpoints on event handlers defined for MXML tags.

Flash Player may interact with a server. The debugger does not assist in debugging the server-side portion of the application, nor does it offer support for inspecting any of the IP transactions that take place from Flash Player to the server, and vice versa.

You can open commands within the fdb debugger by using the fewest number of nonambiguous keystrokes. For example, to use the print command, you can type p, because no other command begins with that letter.

When you debug an application in a web browser, fdb opens the player in the default browser. The default browser is the browser that opens when you open a web-specific file without specifying an application. You must also have the debugger version of Flash Player installed with this browser. If you do not have the debugger version of Flash Player, Flash displays an error indicating that your Flash Player does not support all fdb commands.

Your default browser might not be the first browser that you installed on your computer. For example, if you installed another web browser after installing Microsoft Internet Explorer, Internet Explorer might not be your default browser.

Each application can have any number of ActionScript files. Some of the files that fdb steps into are external class files, and some are generated by the Flex compilers.

In general, Flex generates a single file that contains ActionScript statements used in <fx:Script> blocks in the root MXML file, and an additional file for each ActionScript class that the application uses. Flex generates many source files so that you can navigate the application from within the debugger.

To view a list of files that are used by the application you are debugging, use the info files command. For more information, see Getting status.

The generated ActionScript class files are sometimes referred to as compilation units. For more information about compilation units, see About incremental compilation.

By default, you compile applications against the signed framework RSLs. The signed framework RSLs are optimized, which means that they do not include debugging information. Flash Builder automatically uses unoptimized debug RSLs when you launch the debugger. If you compile on the command line, however, and use the command line debugger, you must either disable RSLs or specify non-optimized RSLs to use. Otherwise, you will not be able to set break points or take advantage of other debugging functionality.

For more information, see Example of using the framework RSLs on the command line

You can start a debugging session with the stand-alone debugger version of Flash Player. You do this by compiling the application into a SWF file, and then invoking the SWF file with the fdb command-line debugger. The fdb debugger opens the debugger version of the stand-alone Flash Player.

The debugger version of the stand-alone Flash Player runs as an independent application. It does not run within a web browser or other shell. The debugger version of the stand-alone Flash Player does not support any server requests, such as web services and dynamic SWF loading, so not all applications can be properly debugged inside the debugger version of the stand-alone Flash Player.

You can start a debugging session in a browser. This requires that you pre-compile the SWF file and are able to request it from a web server.

The fdb debugger provides several commands for stepping through the debugged application’s files. The following table summarizes those commands:

continue

file [file]

finish

next [N]

quit

run [file]

step [N]

When you start a session, fdb stops execution before Flex renders the application on the screen. Use the continue command to get to the application’s starting screen.

The following example shows a sample application after it starts:

(fdb) continue 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] ComboBase: y = undefined text_mc.bl = undefined 
[trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For 
m2._FormItem3._RadioButton1 data = undefined label = 2005 
[trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For 
m2._FormItem3._RadioButton2 data = undefined label = 2004 
[trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For 
m2._FormItem3._RadioButton3 data = undefined label = 2005 
[trace] RadioButtonGroup.addInstance: instance = _level0._VBox0._Accordion0._For 
m2._FormItem3._RadioButton4 data = undefined label = 2006 
[trace] ComboBase: y = 0 text_mc.bl = 12 
[trace] ComboBase: y = 0 text_mc.bl = 12 
[trace] ComboBase: y = 0 text_mc.bl = 12 
[trace] ComboBase: y = 0 text_mc.bl = 14

During the debugging session, you interact with the application in the debugger version of Flash Player. For example, if you select an item from the drop-down list, the debugger continues to output information to the command window:

[trace] SSL : ConfigureScrolling 
[trace] SSP : 5 51 true 47 
[trace] ComboBase: y = 0 text_mc.bl = 14 
[trace] layoutChildren : bRowHeightChanged 
[trace] >>SSL:layoutChildren 
[trace] deltaRows 5 
[trace] rowCount 5 
[trace] <<SSL:layoutChildren 
[trace] >>SSL:draw 
[trace] bScrollChanged 
[trace] SSL : ConfigureScrolling 
[trace] SSP : 5 51 false 46 
[trace] SSL Drawing Rows in UpdateControl 5 
[trace] <<SSL:draw

You can store commonly used commands in a source file, and then load that file by using the source command. For more information, see Accessing commands from a file.

Setting breakpoints is a critical aspect of debugging any application. You can set breakpoints on any ActionScript code in your Flex application. You can set breakpoints on statements in any external ActionScript file, on ActionScript statements in an <fx:Script> tag, or on MXML tags that have event handler properties. In the following MXML code, click is an event handler property:

<s:Button click="ws.getWeather.send();"/>

Breakpoints are maintained from session to session. However, when you change the target file or quit fdb, breakpoints are lost.

The following table summarizes the commands for manipulating breakpoints with the ActionScript debugger:

break [args]

clear [args]

commands [breakpoint]

condition bp_num [expression]

(fdb) break UIEvent:dispatch 
Breakpoint 18 at 0x16cb3: file UIEventDispatcher.as, line 190(fdb)  
condition 18 (eventObj.type == 'initialize')

delete [args]

disable breakpoints [bp_num]

enable breakpoints [bp_num]

The following example sets a breakpoint on the myFunc() method, which is triggered when the user clicks a button:

(fdb) break myFunc 
Breakpoint 1 at 0x401ef: file file1.mxml, line 5 
(fdb) continue 
Breakpoint 1, myFunc() at file1.mxml:5 
    5ta1.text = "Clicked"; 
(fdb)

To see all breakpoints and their numbers, use the info breakpoints command. This will also tell you if a breakpoint is unresolved.

You can use the commands command to periodically print out values of objects and variables whenever fdb encounters a particular breakpoint. The following example prints out the value of ta1.text (referred to as $1), executes the where command, and then continues when it encounters the button’s click handler breakpoint:

(fdb) commands 1 
Type commands for when breakpoint 1 is hit, one per line. 
End with a line saying just 'end'. 
>print ta1.text 
>where 
>continue 
>end 
(fdb) cont 
Breakpoint 1, myFunc() at file1.mxml:5 
    5ta1.text = "Clicked"; 
$1 = "" 
#0 [MovieClip 1].myFunc(event=undefined) at file1.mxml:5 
#1 [MovieClip 1].handler(event=[Object 18127]) at file1.mxml:15

Breakpoints are not specific to a single SWF file. If you set a breakpoint in a file that is common to multiple SWF files, fdb applies the breakpoint to all SWF files.

For example, suppose you have four SWF files loaded and each of those SWF files contains the same version of an ActionScript file, view.as. To set a breakpoint in the init() function of the view.as file, you need to set only a single breakpoint in one of the view.as files. When fdb encounters any of the init() functions, it triggers the break.

(fdb) watch variable_name

You can use the source command to read fdb commands from a file and execute them. This lets you write commands such as breakpoints once and use them repeatedly when debugging the same application in different sessions or across different applications.

The source command has the following syntax:

(fdb) source file

The value of file can be a filename for a file in the current working directory or an absolute path to a remote file. To determine the current working directory, use the pwd command.

The following examples read in the mycommands.txt file from different locations:

(fdb) source mycommands.txt 
(fdb) source mydir\mycommands.txt 
(fdb) source c:\mydir\mycommands.txt

print [variable_name | object_name[.] | property]

(fdb) print myButton. 

(fdb) print myButton.label

(fdb) what variable

(fdb) display [expression]

(fdb) display myButton.color

(fdb) undisplay [list_num]

(fdb) disable display [display_num]

You can use the set command to assign the value of a variable or a configuration variable. The set command has the following syntax:

set [expression]

Depending on the variable type, you use different syntax for the expression. The following example sets the variable i to the number 3:

(fdb) set i = 3

The following example sets the variable employee.name to the string Reiner:

(fdb) set employee.name = "Reiner"

The following example sets the convenience variable $myVar to the number 20:

(fdb) set $myVar = 20

You use the set command to set the values of fdb configuration variables. For more information, see Configuring the command-line debugger.

You use the list command to view lines of code in the ActionScript files. The list command uses the following syntax:

list [- | line_num[,line_num] | [file_name:]line_num | file_name[:line_num] | [file_name:]function_name]

You use the list command to print the lines around the specified function or line of the current file. If you do not specify an argument, list prints 10 lines after or around the previous listing. If you specify a filename, but not a line number, list assumes line 1.

If you specify a single numeric argument, the list command lists 10 lines around that line. If you specify more than one comma-separated numeric argument, the list command displays lines between and including those line numbers.

To set the list location to where the execution is currently stopped, use the home command.

The following example lists code from line 10 to line 15:

(fdb) list 10, 15

If you specify a hyphen (-) in the previous example, the list command displays the 10 lines before a previous 10-line listing.

Specify a line number to list the lines around that line in the current file, as in the following example:

(fdb) list 10

Specify a filename followed by a line number to list the lines around that line in that file, as in the following example:

(fdb) list effects.mxml:10

Specify a function name to list the lines around the beginning of that function, as in the following example:

(fdb) list myFunction

Specify a filename followed by a function name to list the lines around the beginning of that function. This lets you distinguish among like-named static functions, as follows:

(fdb) list effects.mxml:myFunction

You can resolve ambiguous matches by extending the value of the function name or filename, as the following examples show:

Filenames:

(fdb) list UIOb 
Ambiguous matching file names: 
UIComponent.as#66 
UIComponentDescriptor.as#67 
UIComponentExtensions.as#68 
(fdb) list UIComponent.

Function names:

(fdb) list init 
Ambiguous matching function names: 
init 
initFromClipParameters 
(fdb) list init(

(fdb) cf [file_name|file_number]

(fdb) cf MyApp.mxml

(fdb) pwd 
c:/Flex2SDK/bin/

(fdb) directory path

(fdb) directory C:\MySource;C:\MyOtherSource

Use the bt command to display a back trace of all stack frames. The bt command has the following syntax:

(fdb) bt

Use the info command to get general information about the application. The info command has the following syntax:

info [options] [args]

The info command displays general information about the application being debugged. The following table describes the options of the info command:

info files V

info files *.as

handle

stack

swfs

targets

For additional information about these options, use the help command, as the following example shows:

(fdb) help info targets

Use the handle command to specify how fdb reacts to Flash Player exceptions during execution. To view the current settings, use the info command, as the following example shows:

(fdb) info handle

The handle command has the following syntax:

(fdb) handle exception [action]

The fault_type is the category of fault that fdb handles. The action is what fdb does in response to that fault. The possible actions are print, noprint, stop, and nostop. The following table describes these actions:

print

noprint

stop

nostop

(fdb) catch exception_type

(fdb) catch TypeError

(fdb) catch *

Use the help command to get information on particular topics. The help command has the following syntax:

help [topic]

The help command provides a relatively terse description of each command and its usage. The following example opens the help command:

(fdb) help

Type help followed by the command name to get the full help information, as the following example shows:

(fdb) help delete

You use the kill and exit commands to end the current debugging session and exit from the fdb application. The kill and exit commands do not take any arguments. If fdb opened the default browser, you can also terminate the fdb session by closing the browser window.

To stop the current session, use the kill command, as the following example shows:

(fdb) kill

Using the kill command does not quit the fdb application. You can immediately start another session. To exit from fdb, use the exit command, as follows:

(fdb) exit